IdP3 Clustering...

[Andrew Morgan]

On Wed, 30 Nov 2016, Marc SAHIN wrote:

> /“I would say you should use client side session storage, not memcache.”/
> Is it by default like that or do I have to configure the client side session 
> storage ?
> If I'm not mistaken, in case of IdP failure, the user will be prompted to 
> sign in again, is there another constraint?
>
> I’ve found some recommendations for storage entity, are you an objection or 
> another suggestion about that for an IdP3 cluster active-active?
>
> Storage Entity 	Recommended Storage 	Scope
> Conversational session 	Memory 	Per Node
> IdP User Session	Client 	Per Client
> Persistent ID 	Common Database 	Cluster
> User Consents 	Common Database 	Cluster
> SAML artifacts 	Common Database 	Cluster
> Message replay cache 	Memory 	Per Node
>
> According to the documentation, I have to configure global.xml to save 
> PersistentID and User consents into the database and idp.properties for SAML 
> artifacts.

Have you considered using the Computed ID configuration for Persistent 
NameIDs?

   https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration

There is no need to use a database backend or shared server-side storage 
for many use cases.  I think the only cases that require server-side 
storage are the CAS protocol and SAML1 artifact resolution.  I would do 
everything I could to avoid using server-side storage because it adds 
complexity and more ways to fail.

 	Andy