IdP3 Clustering...

[Peter Schober]

* Andrew Morgan <morgan at orst.edu> [2016-11-30 18:03]:
> >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.

Note that you're quoting additional use-cases in your email above,
incl consent.
For example if you're effected by EU data protection law /and/ you
wanted to use consent as the legal basis for attribute release (and
not merely to annoy subjects and appease CIO types) there are certain
requirements (e.g. revocation at any time) you can likely only fulfill
with persisting the consent into an RDBMS (plus providing a UI to do
so even out-of-band, likely).
Also doing this has the clear advantage of being device-independent,
though that argument alone might have less "pull" than legal
requirements.

Whether you need to store persistent NameIDs almost exclusively
depends on your IDM system and local institutional policies. E.g. if
you reassign local userids (even after grace periods) you need to
persist them into a database in order to revoke or re-map previously
generated identifiers to local (possibly changed) userids -- plus have
the processes to do that reliably.

So if you don't have to support SLO and Artifacts, and also don't
think you need to store consent centrally, and have well developed IDM
systems and processes, then congratulations, you should be able to run
your IDP without persisting anything!
-peter