NameID Format Generation
Michael Dahlberg
olgamirth at gmail.com
Fri Feb 26 14:24:29 EST 2016
I'm currently working on upgrading our IdP from v2 to v3, doing a migration
wherever possible. I currently have an almost completely functioning
Shibboleth v3 implementation. My only sticking point seems to be in
generating a custom NameID format for SAML2 encoding. Generating a SAML1
encoded NameIdentifier using an email address as the SourceID worked
without having to make any modification to the config files brought over
from the upgrade process.
I've been following the documentation in
https://wiki.shibboleth.net/confluence/display/IDP30/CustomNameIDGenerationConfiguration.
The particular identifier that I want to release is the
WindowsDomainQualifiedName and the SourceID is the sAMAccountName (I can
see from the logs that this attribute is being correctly retrieved from our
AD server).
(1) I've modified the attribute-filter.xml file to release the attribute:
<!-- Release the NameID to bucknell.maps.arcgis.com -->
<afp:AttributeFilterPolicy>
<afp:PolicyRequirementRule xsi:type="basic:OR">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="
bucknell.maps.arcgis.com" />
<basic:Rule xsi:type="basic:AttributeRequesterString" value="
tbucknell.maps.arcgis.com" />
</afp:PolicyRequirementRule>
<afp:AttributeRule attributeID="transientId">
<afp:DenyValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
<afp:AttributeRule attributeID="WindowsDomainQualifiedName">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
Also, this Attribute Definition is leftover from the v2 to v3 upgrade
<resolver:AttributeDefinition id="WindowsDomainQualifiedName"
xsi:type="ad:PrincipalName">
<resolver:Dependency ref="staticAttributes" />
<resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"
nameFormat="
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName"
nameQualifier="dc=bucknell,dc=edu" />
<resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:WindowsDomainQualifiedName"
/>
</resolver:AttributeDefinition>
(2) Modified the saml-nameid.xml to generate the format:
<util:list id="shibboleth.SAML2NameIDGenerators">
<ref bean="shibboleth.SAML2TransientGenerator" />
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName"
p:attributeSourceIds="#{ {'sAMAccountName'} }" />
</util:list>
As an aside, why shouldn't the SAML2 encoding format be
p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:WindowsDomainQualifiedName"
Changing it to this does not modify the behavior. Also, the format for
emailAddress also use 1.1 encoding.
(3) and finally triggered this format selection by incorporating this line
into the metadata for the SP:
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
entityID="bucknell.maps.arcgis.com">
<md:SPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:WindowsDomainQualifiedName</NameIDFormat>
The log file shows that it keeps releasing the NameID in the transient
format:
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="https://shib.bucknell.edu/idp/shibboleth"
SPNameQualifier="bucknell.maps.arcgis.com
">AAdzZWNyZXQxJ8SE/evGHKpIbxparIGMSC5TQgqgAm5etE/QmnVQikI0OrTOtUfiytkBIuoWourAnK+0VC7guAshoZDZvgr13mTzBl1AgYAalTfvvejxKC7KAM/SKkKCXYktlz5QVco=</saml2:NameID>
<saml2:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="134.82.79.6"
InResponseTo="_PBTcZueiHJrhfdXa"
NotOnOrAfter="2016-02-26T19:06:46.651Z" Recipient="
https://bucknell.maps.arcgis.com/sharing/rest/oauth2/saml/signin"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
Am I missing any config changes that need to be incorporated? Why does the
transient format continue to be selected despite denying it in the filter
and specifying a different format in the metadata?
Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160226/fbe18c9a/attachment-0001.html>
More information about the users
mailing list