IdPv3 and generating persistent NameID
cantor.2 at osu.edu
Fri May 1 12:04:13 EDT 2015
On 5/1/15, 11:12 AM, "Sara Hopkins" <sara.hopkins at ed.ac.uk> wrote:
>> But as far as what's there, if it's a transient NameID, then nothing
>> told it to use a non-default format. Put the format you want in the
>> SPs metadata and it should switch.
>OK. Is that the only way of overriding it?
No, it's more or less similar to V2, you have metadata from the SP, you have the SP requesting a Format in a NameIDPolicy element in its request, and you have the nameIDFormatPrecedence relying party property.
>I'm looking at this because I'm trying to understand the implications of
>the ComputedIdConnector and StoredIdConnector having been deprecated in
>favour of "an equivalent NameID "generator"".
It's not really relevant to the question of why the IdP will include a particular Format in the assertion Subject. That's basically identical in both versions.
The impact of the deprecation on functionality is what I mentioned to Kaspar, there's no non-deprecated way to send this construct as an *Attribute* value. The main use case for that is SAML 1 (since there's no way to send it in the Subject in SAML 1). I realize there are people using it with SAML 2, but that was never necessary.
The point being that because that's actually a feature difference as opposed to "it works the same but is configured differently", actually removing those deprecated AttributeEncoders will be a longer conversation, not something we do on a whim. But they're still deprecated. By which I mean, their use shouldn't be encouraged in any default material, and any existing use should be looked at as a thing to remediate.
>eduPersonTargetedID/urn:oid:22.214.171.124.4.1.59126.96.36.199.10 is a core UK
It's not meant to be an attribute though except in SAML 1, which ought to be fading out of use anyway.
> it's used by many UK SPs to key to registration
>data; if we aren't supposed to use ComputedIdConnector or
>StoredIdConnector to generate it then I'm not sure what we should do
For use as a NameID, you use the new generators, which work exactly the same way. To support it as an Attribute, you have to use the deprecated feature.
> Can we use a NameID generator to generate it and release it as
>an attribute the way we have been doing, or will we have to look at
>moving to a persistent NameID instead?
>(I know that ComputedIdConnector still works at present; it's working
>fine for me. I'm trying to understand implications for the future)
There's no current proposal to remove it, but deprecating it now is a signal that we want to.
More information about the users