not parsing FriendlyName value for Attribute within AttributeStatment

[whatch]

The IDP is returning attribute values in their saml response to our post sso callback, using an attribute key for 'FriendlyName' on the Attribute tag.

<saml2:Attribute FriendlyName="uid"
                             Name="urn:oid:0.9.2342.19200300.100.1.1"
                             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> 
     <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                      xsi:type="xs:string">someuser@domain.com</saml2:AttributeValue> 
</saml2:Attribute>

The plugin doesn't seem to parse this correctly, so profile.uid, in this example, isn't valid, but profile.['urn:oid:0.9.2342.19200300.100.1.1'] works fine. I'm asking if there's a configuration option I'm not seeing that will enable me to use the friendly name value, instead of the urn value?

[markstos]

This is interesting. When compared to a response that this module does part correctly, what exactly is different about this one? Can you confirm that the IdP is returning a response that is valid with the SAML spec, and we are failing to be spec-compliant by not parsing this?

[markstos]

Closing due to lack of follow-up from the OP or anyone else about this.

[whatch]

@markstos , so sorry. I didn't get your reply originally. I don't know if the response formatting is spec compliant, but I can include it here. It's from a shiboleth idp.

Here's the relevant attribute section from the response, from the idp, in xml:

saml2:AttributeStatement
<saml2:Attribute FriendlyName="cn"
Name="urn:oid:2.5.4.3"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string"
>Abby Dabby</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="uid"
Name="urn:oid:0.9.2342.19200300.100.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
saml2:AttributeValueabby@newco.com</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="mail"
Name="urn:oid:0.9.2342.19200300.100.1.3"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
saml2:AttributeValueabby@newco.com</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="sn"
Name="urn:oid:2.5.4.4"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string"
>Dabby</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="givenname"
Name="urn:oid:2.5.4.3"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string"
>Abby</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="guid"
Name="urn:oid:2.5.4.3"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
saml2:AttributeValue85A1F3D4B1D1C32C2384FDA53E3D0B694504896640A841B4F20E55BA05ABA2A0</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>

[whatch]

Here's the json json passport provides from a response from this IDP, which does not use the FriendlyName, and also fails to parse several other attributes:

The saml profile returned: {
"issuer": "https://uat.freescale.com/idp-auth/shibboleth",
"sessionIndex": "_df36f19d3f2aa52d04bb25e0b3ec3a04",
"nameID": "AAdzZWNyZXQxMrq3K/sfJAWCT1gCID6X5s3Gx5/5Noqtd2WVFlBAB37K7BHlRoS2XtS/OLvgz4BxrBPwGNzoB853qCJrvszDzJXZxJPK050MD8etGvtutHdfa7TwMNJA6FCeTvnRJrVustlVD0P/25FEL02srAYQXfATM5MRv5V5gKbXYPmy3Q==",
"nameIDFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:transient",
"nameQualifier": "https://uat.freescale.com/idp-auth/shibboleth",
"spNameQualifier": "https://rapid-iot-staging.atmosphereiot.com/auth/saml",
"urn:oid:2.5.4.3": "85A1F3D4B1D1C32C2384FDA53E3D0B694504896640A841B4F20E55BA05ABA2A0",
"urn:oid:0.9.2342.19200300.100.1.1": "abby@newco.com",
"urn:oid:0.9.2342.19200300.100.1.3": "abby@newco.com",
"urn:oid:2.5.4.4": "Dabby",
"mail": "abby@newco.com",
"email": "abby@newco.com"
}

[markstos]

From reading our source code, docs and tests, the FriendlyName is not something we attempt to parse.

From reading the SAML spec here, the FriendlyName is an optional part of the SAML spec.

What I do personally is keep a mapping in my configuration system of the name I want to use to the name in the SAML being sent, which is sometimes a long OID.

Then when I get back the parsed SAML data, I map the SAML profile field names to the names I want.

I agree it could be an interesting feature to support returning profile fields by their FriendlyName if it's present.

It could also be interesting to allow defining a mapping like that I one I use, to make it easier to get back a data structure with more usable key names.

So I'm leaving this issue open in case someone wants to work on improvements here.

[whatch]

Yes, we do the same with our configuration, and after inspecting their xml a bit more closely, I believe the issue is that they're repeating the "Name" key on multiple attributes, which then results in the plugin to overwrite the key in the profile such that the last one wins. So any previous key is not available to us in the profile. I'd say this is more a bug with this specific IDP, and not a passport-saml issue. Sadly, this does not make life easier at the moment ;-)

[whatch]

As a follow up, the IDP changed the Name value for each of the attributes to be distinct, and the problem is resolved. I think it's still a good idea to consider optionally parsing on the FriendlyName value, as that seems to be very common in general use. I'd like to contribute to this project in general, so I'm going to fork. Is there a formal prioritized ticket list, or just doing this adhoc? I see a lot of open PR's, so just wondering. Thanks, @markstos

[markstos]

@whatch Right now we are focused on issues and PRS labeled "1.0". I'd like to put a new release within about a week:

https://github.com/bergie/passport-saml/issues?q=is%3Aissue+is%3Aopen+label%3A1.0

Since there will be a major version bump, this release is eligible to contain breaking changes.

[markstos]

I'd like to contribute to this project in general, so I'm going to fork. Is there a formal prioritized ticket list, or just doing this adhoc? I see a lot of open PR's, so just wondering.

I try to triage PRs but leave most refinements up to contributor. If they don't follow up, the PRs often linger in case someone else wants to pick them up.

There's also a new v2 branch and an issue about plans for v2. There is no primary developer now, so patches are very much community-driven at this point.