Subject Identifier

Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client. It MUST NOT exceed 255 ASCII characters in length. The value is a case sensitive string.

Two types of Subject Identifiers, public and pairwise, http://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes

Different RPs may belong to same pairwise group by sharing the sector_identifier_uri - value

Placed always in ID Token and UserInfo response, whether requested or not.

Subject Identifier Generation

Extension provides default resolver and a configuration for it.

oidc-subject.properties 
# The source attribute used in generating the subject
idp.oidc.subject.sourceAttribute = uid

# The digest algorithm used in generating the subject
#idp.oidc.subject.algorithm = SHA

# The encoding used in generating the subject
#idp.oidc.subject.encoding = BASE32

# The salt used in generating the subject
# Do *NOT* share the salt with other people, it's like divulging your private key.
idp.oidc.subject.salt = this_too_should_be_ch4ng3dExercises
attribute-resolver.xml 
    <!-- Subject Identifier is a attribute that must always be resolved.
    There has to be exactly one resolved and filtered attribute that would be encoded as 'sub'.
    This example attribute (the data connector actually ) will generate public or pairwise 'sub' depending on client registration data.  -->

    <AttributeDefinition id="subject" xsi:type="Simple" activationConditionRef="SubjectRequired">
        <InputDataConnector ref="computedSubjectId" attributeNames="subjectId"/>
        <AttributeEncoder xsi:type="oidcext:OIDCString" name="sub" />
    </AttributeDefinition>

    <!--
    Subject Identifier is a attribute that must always be resolved.
    There has to be exactly one resolved and filtered attribute that would be encoded as 'sub'.

    Use activation conditions and filters to ensure the requirement is met if you have need for several different kind of formats for 'sub'.

    <AttributeDefinition id="subject-public" xsi:type="Simple" sourceAttributeID="uid" activationConditionRef="PublicRequired">
        <Dependency ref="uid" />
        <AttributeEncoder xsi:type="oidcext:OIDCString" name="sub" />
    </AttributeDefinition>

    <AttributeDefinition id="subject-pairwise" xsi:type="Simple" activationConditionRef="PairwiseRequired">
        <InputDataConnector ref="computedSubjectId" attributeNames="subjectId"/>
        <AttributeEncoder xsi:type="oidcext:OIDCString" name="sub" />
    </AttributeDefinition>
    -->


   <!-- Data Connector for generating 'sub' claim.
         The connector may be used to generate both public and pairwise subject values -->
    <DataConnector id="computedSubjectId" xsi:type="ComputedId"
            generatedAttributeID="subjectId"
            sourceAttributeID="%{idp.oidc.subject.sourceAttribute}"
            salt="%{idp.oidc.subject.salt}"
            algorithm="%{idp.oidc.subject.algorithm:SHA}"
            encoding="%{idp.oidc.subject.encoding:BASE32}">
            <Dependency ref="%{idp.oidc.subject.sourceAttribute}"/>
    </DataConnector>

 
attribute-filter.xml 
<AttributeFilterPolicy id="OPENID_SCOPE">
    <PolicyRequirementRule xsi:type="oidcext:OIDCScope" value="openid" />
    <AttributeRule attributeID="subject">
        <PermitValueRule xsi:type="ANY" />
    </AttributeRule>
</AttributeFilterPolicy>
Exercise 6.1

Configuring Subject claim

  1. Modify the registration data of the RP to list subject of type pairwise.

    nano /opt/shibboleth-idp/metadata/oidc-client.json

{
  "scope":"openid info profile email address phone",
  "redirect_uris":["https://192.168.0.150:8443/protected/redirect_uri"],
  "client_id":"test_rp",
  "client_secret":"testSecret1234",
  "response_types":["id_token","code"],
  "grant_types":["authorization_code","implicit","refresh_token"],
  "subject_type":"pairwise"
}

  2. Authenticate the user. Verify from landing page or from logs that the value of subject is different from previously used public value.

    Hints, Tips and Result 
    [OIDC_CLAIM_sub] => DQ3YFEXBF65XMAULUJHBAI34IVRR3GT5
  3. Activate the attributes "subject-public" and "subject-pairwise" by modifying the comment markers. Ensure the filtering rules are such that these attributes are not filtered out but the attribute "subject" is filtered out for your RP.

  4. Modify the registration data of the rp to request subject of type public.

    nano /opt/shibboleth-idp/metadata/oidc-client.json

{
  "scope":"openid info profile email address phone",
  "redirect_uris":["https://IP_ADDRESS:8443/protected/redirect_uri"],
  "client_id":"test_rp",
  "client_secret":"testSecret1234",
  "response_types":["id_token","code"],
  "grant_types":["authorization_code","implicit","refresh_token"],
  "subject_type":"public"
}

  5. Authenticate the user. Verify from landing page or from logs that the value of subject is now this plain text value.

    Hints, Tips and Result 
    [OIDC_CLAIM_sub] => teppo
  • No labels