Making urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified a supportable identifier format
Alain O'Dea
alain.odea at gmail.com
Thu Jun 11 21:39:30 EDT 2015
On 11 June 2015 at 23:01, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 6/11/15, 9:09 PM, "users on behalf of Alain O'Dea" <
> users-bounces at shibboleth.net on behalf of alain.odea at gmail.com> wrote:
>
> >If I hack the format I get NameID values I can't use. I need the email
> address on the SP. I don't want to do anything that will compromise my
> SP's support for other IdPs.
>
> SPs should use Attributes not NameIDs. You don't want to bother with
> NameIDs, they're limiting and brittle. The only NameID types that should
> ever be used are transient and persistent. The former is only used to
> support extended use cases like logout, otherwise you just omit it.
>
> >I have the following in conf/attribute-resolver-ldap.xml:
>
> Assuming this is V3, that's not the suggested way to handle NameID
> generation anymore, but regardless, your issue here is that you have the
> wrong constant. The unspecified constant should be as you have in your
> resolver, but the value the SP's metadata has is incorrect, it's got "2.0"
> in the constant string instead of 1.1.
>
> And in any case, using the real constant in the SP's metadata will do
> nothing. The IdP will ignore it because you told it you didn't care what
> the format is (that's what "unspecified" means).
>
> -- Scott
I like this solution Scott. Thank you.
I am now using urn:oasis:names:tc:SAML:2.0:nameid-format:transient and
releasing the mail attribute in conf/attribute-filter.xml:
<afp:AttributeFilterPolicy>
<afp:PolicyRequirementRule
xsi:type="basic:AttributeRequesterString" value="
http://localhost:8080/consume.jsp" />
<afp:AttributeRule attributeID="mail">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
Then I retrieve its value under the standard SAML2 attritbute name of
"urn:oid:0.9.2342.19200300.100.1.3" in my SP. Works very cleanly.
Next step for me now is migrating to OpenSAML for my SP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150611/5ff1e7ac/attachment.html>
More information about the users
mailing list