<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><i>"Have you considered using the Computed ID configuration for
Persistent NameIDs? "</i></p>
In fact, ComputedID is henceforth depreciated for that reason we use
PersistentID with StoredID connector which generate random
identifiers and store them in db.<br>
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...<br>
<pre class="moz-signature" cols="72">Marc SAHIN
Administrateur Systèmes
Pôle Système - DSI - Université Lumière Lyon 2
04 78 77 26 66
</pre>
<div class="moz-cite-prefix">On 30/11/2016 18:03, Andrew Morgan
wrote:<br>
</div>
<blockquote
cite="mid:alpine.DEB.2.02.1611300858100.29057@shell.onid.oregonstate.edu"
type="cite">On Wed, 30 Nov 2016, Marc SAHIN wrote:
<br>
<br>
<blockquote type="cite">/“I would say you should use client side
session storage, not memcache.”/
<br>
Is it by default like that or do I have to configure the client
side session storage ?
<br>
If I'm not mistaken, in case of IdP failure, the user will be
prompted to sign in again, is there another constraint?
<br>
<br>
I’ve found some recommendations for storage entity, are you an
objection or another suggestion about that for an IdP3 cluster
active-active?
<br>
<br>
Storage Entity Recommended Storage Scope
<br>
Conversational session Memory Per Node
<br>
IdP User Session Client Per Client
<br>
Persistent ID Common Database Cluster
<br>
User Consents Common Database Cluster
<br>
SAML artifacts Common Database Cluster
<br>
Message replay cache Memory Per Node
<br>
<br>
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.
<br>
</blockquote>
<br>
Have you considered using the Computed ID configuration for
Persistent NameIDs?
<br>
<br>
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration">https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration</a><br>
<br>
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.
<br>
<br>
Andy<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>