Shibboleth SP - Using NameID with "unspecified" format. [SEC=UNCLASSIFIED]

[BONNY, Michael]

Hi Fred,

You can change the way default behaviour of how ADFS sends the NameID format.
Your SP should be defined in ADFS as a "Relying Party"

You probably need to do this on your ADFS box:

Open the ADFS2.0 MMC
Right Click on the Shib-SP "Relying Party", click Properties

In the "Issuance Transform Rules", select "Add Rule", Use the Template of "Transform an Incoming Claim"

Name the rule "Transform NameID-unspecified to NameID-Persistent"

Change the Incoming Claim type to NameID, Unspecified
Change the Outgoing Claim type to NameID, Persistent (or whatever your SP really wants)



This will create a transformation rule for you which looks like this:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] == "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");



If you let me know a bit more specifically about EXACTLY what your Shib-SP requires, I can probably give you some more exact detail on how to configure ADFS to send the attributes in the right format.

Regards,
Michael


From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Friedrich Clausen
Sent: Monday, 22 July 2013 8:45 PM
To: Shib Users
Subject: Shibboleth SP - Using NameID with "unspecified" format.

Hello All,

We are interoperating with an AD FS implementation and it is sending along a NameID that is not being mapped to an attribute with our standard attribute-map.xml. The following is shown in the shibd.log set to debug (removed timestamps for readability)

Shibboleth.AttributeExtractor.XML [2]: unable to extract attributes, unknown XML object type: samlp:Response
Shibboleth.AttributeExtractor.XML [2]: skipping unmapped NameID with format (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)
Shibboleth.AttributeExtractor.XML [2]: unable to extract attributes, unknown XML object type: {urn:oasis:names:tc:SAML:2.0:assertion}AuthnStatement

It appears, due to the "samlp" message, that the AD FS "IdP" is using SAML 1.1.  The above results in no attributes visible to the application. I then decided, as an experiment, to add the "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" to attribute-map.xml as a simple mapping with no decoder specified -

    <Attribute name="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" id="test-mapping">
    </Attribute>

I reloaded shibd and then the test attribute, "test-mapping", was visible. The logs showed

Shibboleth.AttributeExtractor.XML [2]: unable to extract attributes, unknown XML object type: samlp:Response
Shibboleth.AttributeDecoder.String [2]: decoding SimpleAttribute (test-mapping) from SAML 2 NameID with Format (unspecified)
Shibboleth.AttributeExtractor.XML [2]: unable to extract attributes, unknown XML object type: {urn:oasis:names:tc:SAML:2.0:assertion}AuthnStatement

This solves my problem (getting the user name visible to the app). My question is - is this a recommended approach? Should I, or the AD FS administrators, do something differently?

Many thanks,

Fred.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130722/44a983d9/attachment.html