mix different NameIDs for different SPs

[Nate Klingenstein]

Jehan,

> I did manage to create a persistent nameID based on mail
>       attribute as required by specific SPs [1]

> but there are other SPs that needs also a persistent nameID, 
>       this time based on eppn !

There should be no reason why you would need to base your persistentId generation on a particular attribute for a particular vendor.  It just needs to be as fixed as possible so the value of the persistentId doesn't change, particularly if you aren't using a database storage mechanism.  In fact, there should be no way for them to even tell what attribute you're basing your persistentId generation on.

This is all assuming that persistentId is being used per specification and not to carry other arbitrary, clear-text attributes, which would be a misuse of persistentId's.

> I can I mix those 2 (and perhaps one day 3 or more ... ) 
>       attribute based persistent NameIDs for differents SPs [2] ?

Technically, yes.  You can create multiple persistentId generators that rely either on custom properties defined by you in saml-nameid.properties or have the properties hardcoded in them with an activation condition based on SP, like you had begun creating.

However, there should never be a reason to be doing this, so I would really have a long talk with pointy teeth with the SP first.  In all likelihood, they're just trying to give you guidance on an attribute that doesn't change regularly(and mail is particularly bad guidance, especially since it can be multivalued, and does change regularly).  Any other conceivable purpose for them wanting a particular source attribute is bad.

Take care,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id