IdP3 Clustering...

[Marc SAHIN]

/“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.
However, is it enough to configure JPAStorageService to save all three 
of them in db ?
Does the database replication has to be master-master ?

Is there any limitation for in using SELinux for IdP3 ?

Thanks

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

On 29/11/2016 18:05, Cantor, Scott wrote:
>> After reading the official document and the article below, apparently, it's
>> possible to provide IdP3 clustering with that combination :
> Well, yes.
>
>> Any suggestions/guidance would be really appreciated.
> I don't know what you want, you're not asking a specific question. If you're asking what you should do, I would say you should use client side session storage, not memcache.
>
> -- Scott
>

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