In Finnish

Service Provider

With the introduction of the new profile, it is now possible for the SP to request a SAML Subject-ID or Pairwise-ID. The implementation of this is done in the resource register for the SP on the "SP Basic information" tab. This adds an entity attribute to the metadata using the specification extension (Example below, where the service requests pairwise-id)

rr.funet.fi ja metadata
<EntityDescriptor xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://rr.funet.fi/attribute-test">
  <Extensions>
    <mdattr:EntityAttributes>
      <saml:Attribute Name="urn:oasis:names:tc:SAML:profiles:subject-id:req" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml:AttributeValue>pairwise-id</saml:AttributeValue>
      </saml:Attribute>
    </mdattr:EntityAttributes>
  </Extensions> ...

Possible options are:

  • not in use 
  • subject-id
  • pairwise-id
  • none (SP does not ask for either Subject-ID)
  • any (either subject-id or pairwise-id is valid for the service

Shibboleth-SP attribute-map

attribute-map.xml
    <Attribute name="urn:oasis:names:tc:SAML:attribute:subject-id" id="subject-id">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/>
    </Attribute>

    <Attribute name="urn:oasis:names:tc:SAML:attribute:pairwise-id" id="pairwise-id">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/>
    </Attribute>

Identity Provider

The attribute filter supplied with Shibboleth-IdP also has ready-made rules for passing these subject-id attributes. The filter calculates through pairwise-id if pairwise-id or any type is requested as subject-id, subject-id is passed only if it is requested explicitly.

attribute-filter.xml
<!--
    Example rule for honoring Subject ID requirement tag in metadata.
    The example supplies pairwise-id if subject-id isn't explicitly required.
    -->
    <AttributeFilterPolicy id="subject-identifiers">
        <PolicyRequirementRule xsi:type="ANY" />

        <AttributeRule attributeID="samlPairwiseID">
            <PermitValueRule xsi:type="OR">
                <Rule xsi:type="EntityAttributeExactMatch"
                    attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
                    attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                    attributeValue="pairwise-id" />
                <Rule xsi:type="EntityAttributeExactMatch"
                    attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
                    attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                    attributeValue="any" />
            </PermitValueRule>
        </AttributeRule>

        <AttributeRule attributeID="samlSubjectID">
            <PermitValueRule xsi:type="EntityAttributeExactMatch"
                attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req"
                attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
                attributeValue="subject-id" />
        </AttributeRule>
    </AttributeFilterPolicy>

An example of a resolver when computedId is used as pairwise-id and eduPersonPrincipalName is used as subject-id

attribute-resolver.xml
  <AttributeDefinition id="samlSubjectID" xsi:type="Scoped" scope="%{idp.scope}">
    <InputAttributeDefinition ref="eduPersonPrincipalName" />
  </AttributeDefinition>

  <AttributeDefinition id="samlPairwiseID" xsi:type="Scoped" scope="%{idp.scope}">
    <InputDataConnector ref="computedSubjectId" attributeNames="computedId"/>
  </AttributeDefinition>

It is good to note that BASE64 encoding is used by default in Shibboleth-IdP, but the recommendation is to use BASE32 type, in which case lowercase letters are cut off. Not all products perform well with typefaces where the difference between upper and lower case letters is important.



  • No labels