SSP has support for generating the two "new" SAML subject identifier attributes in saml:SubjectID and saml:PairwiseID. However, it seems that the requirements signalling part of the specification was overlooked. This uses a dedicated EntityAttribute to signal which of the two subject identifiers the remote SP would like, separate from the normal RequestedAttribute mechanism.
core:AttributeLimit allows us to filter attributes based on RequestedAttributes (corresponding to the attributes entry in SSP form metadata). However there is not comparable mechanism to implement the logic described in the urn:oasis:names:tc:SAML:profiles:subject-id:req EntityAttribute.
This could be fixed by extending saml:SubjectID / saml:PairwiseID to respect the urn:oasis:names:tc:SAML:profiles:subject-id:req EntityAttribute if present, and only generate a subject identifier if it matched the request. Tt should probably always generate if no explicit request was present, and may need a boolean to force generation even when not requested?
I guess it could also be fixed by extending core:AttributeLimit to understand the EntityAttribute. This might make more sense to newcomers who expect that module to manage all attributes. But its also somewhat overstepping the core/saml boundary?
Additional context
SAML metadata signalling that it wants a subject identifier includes this:
<md:Extensions>
<mdattr:EntityAttributes>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:profiles:subject-id:req">
<saml:AttributeValue>any</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
</md:Extensions>where the AttributeValue is a controlled vocabulary {none,subject-id,pairwise-id,any} defined in 3.5.1 of the OASIS specification.
SSP has support for generating the two "new" SAML subject identifier attributes in saml:SubjectID and saml:PairwiseID. However, it seems that the requirements signalling part of the specification was overlooked. This uses a dedicated EntityAttribute to signal which of the two subject identifiers the remote SP would like, separate from the normal RequestedAttribute mechanism.
core:AttributeLimit allows us to filter attributes based on RequestedAttributes (corresponding to the
attributesentry in SSP form metadata). However there is not comparable mechanism to implement the logic described in theurn:oasis:names:tc:SAML:profiles:subject-id:reqEntityAttribute.This could be fixed by extending saml:SubjectID / saml:PairwiseID to respect the
urn:oasis:names:tc:SAML:profiles:subject-id:reqEntityAttribute if present, and only generate a subject identifier if it matched the request. Tt should probably always generate if no explicit request was present, and may need a boolean to force generation even when not requested?I guess it could also be fixed by extending core:AttributeLimit to understand the EntityAttribute. This might make more sense to newcomers who expect that module to manage all attributes. But its also somewhat overstepping the core/saml boundary?
Additional context
SAML metadata signalling that it wants a subject identifier includes this:
where the AttributeValue is a controlled vocabulary {none,subject-id,pairwise-id,any} defined in 3.5.1 of the OASIS specification.