NameID Format Generation

Mitch Chang mitch at sfu.ca
Wed Jun 1 14:17:10 EDT 2016 

Hi Scott,
While upgrading our Shibboleth IdP v3 from v2 I came across your reply to this thread posted back in Feb. 
We have following denial rules defined in attribute-filter.xml:
    <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">
        <afp:PolicyRequirementRule xsi:type="basic:NOT">
            <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://whatson.sfu.ca/shibboleth" />
        </afp:PolicyRequirementRule>

        <afp:AttributeRule attributeID="transientId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>

    </afp:AttributeFilterPolicy>

Will it continue to work in IdP v3? If not, what are the recommended alternatives?

Thanks.
Mitch

On 2016-02-26, at 2:26 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>> I have found that when using the legacy (v2 style) settings that SPs who once
>> received subject-NameIds didn't get them in v3 if there is no NameId
>> requested in their metadata.
> 
> The triggers for format selection are essentially identical to V2. What you were doing that no longer works is trying to use denial rules to limit the possible choices to exclude transient usage.
> 
> -- Scott
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

Begin forwarded message:

> From: "Charles R. Tompkins" <crt at ufl.edu>
> Subject: RE: NameID Format Generation
> Date: 26 February, 2016 1:19:09 PM PST
> To: "users at shibboleth.net" <users at shibboleth.net>
> Reply-To: Shib Users <users at shibboleth.net>
> 
> I have found that when using the legacy (v2 style) settings that SPs who once received subject-NameIds didn't get them in v3 if there is no NameId requested in their metadata.
> 
> Adding appropriate NameId encoding requests to their metadata fixed it.
> 
> -Charles
> 
> -----Original Message-----
> From: Michael Dahlberg [olgamirth at gmail.com]
> Received: Friday, 26 Feb 2016, 2:24PM
> To: Shib Users [users at shibboleth.net]
> Subject: NameID Format Generation
> 
> 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<http://bucknell.maps.arcgis.com> -->
>    <afp:AttributeFilterPolicy>
>        <afp:PolicyRequirementRule xsi:type="basic:OR">
>            <basic:Rule xsi:type="basic:AttributeRequesterString" value="bucknell.maps.arcgis.com<http://bucknell.maps.arcgis.com>" />
>            <basic:Rule xsi:type="basic:AttributeRequesterString" value="tbucknell.maps.arcgis.com<http://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<http://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<http://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
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160601/e20d4bdb/attachment-0001.html>

More information about the users mailing list