Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

not parsing FriendlyName value for Attribute within AttributeStatment #282

Open
whatch opened this issue May 17, 2018 · 9 comments
Open

Comments

@whatch
Copy link

whatch commented May 17, 2018

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">[email protected]</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
Copy link
Contributor

markstos commented Aug 3, 2018

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
Copy link
Contributor

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

@whatch
Copy link
Author

whatch commented Oct 3, 2018

@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:AttributeValue[email protected]</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:AttributeValue[email protected]</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
Copy link
Author

whatch commented Oct 4, 2018

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": "[email protected]",
"urn:oid:0.9.2342.19200300.100.1.3": "[email protected]",
"urn:oid:2.5.4.4": "Dabby",
"mail": "[email protected]",
"email": "[email protected]"
}

@markstos
Copy link
Contributor

markstos commented Oct 4, 2018

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
Copy link
Author

whatch commented Oct 4, 2018

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
Copy link
Author

whatch commented Oct 5, 2018

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
Copy link
Contributor

markstos commented Oct 5, 2018

@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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants