Our clustering solution for IdP v3

[Julian Williams]

On 29/02/16 01:31, Nate Klingenstein wrote:
>> 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
>

Ah well, there you go, I didn't realise that. Looks like we picked up
the wrong end of the stick somewhere along the line. Probably conflated
things with the artifact use.

So it would seem we have been using the random form of transient id with
our v2 IdP (which did originally exist as a 1.x IdP) and there's no
reason to continue with this for 3.x (in fact it turns out that we
*have* been testing v3 with the default decryptable non-random form).
That's going to simplify things a lot for us then and we can treat SAML1
the same as SAML2 and distribute it across the 3 nodes (albeit with
session stickiness to ensure that we don't switch nodes mid conversation).

Many thanks Tom & Nate.