Our clustering solution for IdP v3

[Nate Klingenstein]

> No, I don't think that's true. Even back in the good old SAML1 days,
> the Shibboleth transient name ID included an embedded user identifier,
> which was all nicely encrypted into the name ID so that the Attribute
> Authority could determine the user by simply decrypting the name ID
> that it had encrypted in the first place.

Elaborating briefly for the identity historians that will undoubtedly someday actually care — hello, identity historian from the future — the default values really were completely random for Shibboleth IdP 1.x and 2.x.  The encryption was an optional feature that started in 1.x and got added to 2.3 as an implementation later, actually.

https://wiki.shibboleth.net/confluence/display/SHIB/LoadBalancedIdP
https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverCryptoTransientIDAttributeDefinition

I believe 3.x has always defaulted to this strategy.  I can’t think of a real use case where I would prefer the pure random UUID’s, though I’m sure there is one somewhere.

https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration#NameIDGenerationConfiguration-TransientIdentifierGeneration