IdP3 Clustering...

[Marc SAHIN]

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

In fact, ComputedID is henceforth depreciated for that reason we use 
PersistentID with StoredID connector which generate random identifiers 
and store them in db.
It's easy to put in place dynamic PersistentID but it has some 
limitations ; it is not to possible to find a user with his 
PersistentID, revoke or  modify the value of the PersistentID...

Marc SAHIN
Administrateur Systèmes
Pôle Système  - DSI - Université Lumière Lyon 2
04 78 77 26 66

On 30/11/2016 18:03, Andrew Morgan wrote:
> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161201/8136ec10/attachment.html>