IdP3 Clustering...

[Marc SAHIN]

> /In fact, ComputedID is henceforth depreciated for that reason we use 
> PersistentID with StoredID connector which generate random identifiers 
> and store them in db. /
> //
//

/"Computing them hasn't been deprecated in any real way for a very long 
time. It's the only practical way to do them, a database is not a 
practical approach for the vast majority of deployers."/

Sorry about it and thank you for providing this information.
I've shared the information received from our Federation last year 
that's why we had to change our configuration to use Stored ID in IdP2.
I've just checked from their site the Compted ID is still announced like 
obsolete and it is strongly advised not to use it.
However, for IdP3,  both of them are proposed and StoredID is recommended.

I think, there was a confusion about it.
I'll report them.

Another point : delegate the authentication IdP3 to CAS
Our principal SSO solution is CAS (v3.5.2)
Would it be a good idea to integrate an external CAS server with IdP3 ?
What do you think about this approach ?

Visibly, it's possible with Unicon projet :
https://github.com/Unicon/shib-cas-authn3

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

On 01/12/2016 17:15, Cantor, Scott wrote:
>> In fact, ComputedID is henceforth depreciated for that reason we use
>> PersistentID with StoredID connector which generate random identifiers and
>> store them in db.
> Computing them hasn't been deprecated in any real way for a very long time. It's the only practical way to do them, a database is not a practical approach for the vast majority of deployers.
>
>> 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...
> The former is possible with audit logging. The latter isn't possible, but if it ever came up, building a mechanism based on a sparse override file to force changes to the hashes would be well within any mildly competent Java developer's capability.
>
> -- Scott
>
>

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