NameID encoding

[Cantor, Scott]

On 1/15/13 3:04 PM, "Eric Goodman" <Eric.Goodman at ucop.edu> wrote:

>These questions are more conceptual than technical:
> 
>I¹ve got a couple of SPs that require specific NameID values -- that is,
>they need a specific attribute to be passed as the NameID in the subject
>of the assertion rather than in arbitrary attributes. When configuring
>the attribute release policies, I¹m confused by what I¹m expected to use
>as the nameFormat for these NameIDs.

That generally means they don't know what they're doing or they would be
able to tell you.

As a matter of convenience, the I2MI attribute profile makes the obvious
suggestion that putting an arbitrary attribute into a NameID should be
done by encoding the attribute name into the Format attribute. I'm not
aware of most/any vendors that actually make this demand following that
logic, they just make stuff up or ignore it.

> 
>On one hand, which nameFormat should be used seems like a somewhat
>meaningless question; I think I can use any string in the nameFormat, as
>long as the SP and the IdP agree on it.

Yes.

>I see nameFormats listed with differing urn scopes in different docs and
>config files. E.g., ³urn:oasis:names:tc:SAML:N.M:nameid-format:transient²
>has different values for the SAML version (1.0, 1.1, 2.0). Are the SPs
>ignoring
> the SAML version value in the URN?

The values are defined by whoever owns them. There is not more than one of
that particular constant in the spec. The only valid one happens to have
2.0 in the string. The rest are undefined.

> 
>o  
>Even in the saml-core-2.0-os.pdf spec document
>(http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)
>there¹s disagreement: line 460
> lists ³unspecified² scoped as SAML:1.0, but on line 3282, where it¹s
>officially defined, it shows up as SAML:1.1.

Check the errata, I think that's just an error. Generally it should match
whatever version introduced the value, and it never changes.

>o That said, I¹ve never seen a complaint from an SP about an invalid
>nameid format even though I can¹t imagine all the SPs are using the same
>version number in their requests.

Most SPs are broken in lots of ways and are implemented sloppily. But I
can definitely point you to examples of SPs that will complain, not just
mine.

> 
>· The ID I¹m using is unique and persistent (in the literal English
>sense), but is not opaque, so it is not a ³persistent NameID² (in the
>SAML sense). Sounds like I need to create a custom type?

The rules for that type are very specific, yes, and it is more likely that
you should.

>o  If I do use a custom type, should the name include the
>³urn:oasis:names:tcŠ² header ? It seems like I actually need to scope it
>with my own local urn header, since oasis didn¹t define the value, but I
>don¹t see any actual customID
> examples to crib from.

You should not invent names you don't control, no. To answer this
question, think about how you would name a Java package you wrote or
create an entityID.

> 
>o  
>There¹s a comment on the wiki that I can use the default ³Š:unspecified²,
>but it sounds from the context like that¹s discouraged if the SP and IdP
>can handle custom IDs. Is that correct?

I strongly discourage its use, yes.

>Again, none of these are pressing, but since I¹m doing more than one
>nameID config exercise I thought I should follow best practices, assuming
>they exist.

The best practices are the same as attribute naming, since it's the same
use case essentially.

https://wiki.shibboleth.net/confluence/display/SHIB2/AttributeNaming

-- Scott