IdPv3 and generating persistent NameID
sara.hopkins at ed.ac.uk
Fri May 1 11:12:49 EDT 2015
On 30/04/2015 21:07, Cantor, Scott wrote:
> If you're sending a persistentID, you want to use a source attribute
> that has no encoders attached to it so that it doesn't leak. I'll be
> changing the defaults to reflect that better. It's not ideal, but
> we'll see how it goes.
I understand; I read another thread about that. I deliberately left the
encoders there for testing purposes to help me verify easily that the
source attribute was being released.
> 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?
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"".
eduPersonTargetedID/urn:oid:22.214.171.124.4.1.59126.96.36.199.10 is a core UK
federation attribute, 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
instead. 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)
UK Access Management Federation for Education and Research
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the users