Hi Francesco, thank you very much for the detailed and helpful information. Probably 3) would be a good solution to cover my use case. If we implement it, I'll see if I can provide an experience report.
Best regards, Guido > "Francesco Chicchiriccò" <[email protected]> schrieb: >> On 23/01/2013 09:13, Guido Irrelevant wrote: >> [...] >> >> The use case is that I have a number of Web applications (other than the >> Syncope console). Syncope should manage the users that can log in to the Web >> applications and CAS should offer SSO based on the user data in Syncope. >> I.e., the user wants to login to Web Application X which is protected by CAS >> filters. She is redirected to CAS which asks for the credentials if >> necessary. The credentials are validated by CAS against the user data in >> Syncope. After successful login, possibly authorizations could be set in the >> Web applications using the data in Syncope (this could be done using >> attributes sent by CAS with the ticket, or outside of CAS by calling Syncope >> from the Web application). >> >> Is this a valid use case anyway? Are there best practices / existing code >> for this? > > Hi Guido, > by my > experience in the IAM world, and especially in the Identity > Manager (like as Syncope) - Access Manager (like as CAS) integration, I > have found that this concept might involve different use cases, at > different level. > > Disclaimer: I am more familiar with OpenSSO / OpenAM than with CAS. > > > 1) Let Syncope manage Access Manager's user repository via exposed APIs > (if available) > > This case is covered for OpenAM by the connector [1]: basically Syncope > will manage users stored in the Access Manager by treating it as a > plain external resource. > I guess this is applicable for CAS as well, provided that someone > develops a specific connector based on CAS public APIs. > > > 2) Let Syncope manage Access Manager's user repository via underlying store > > Often Access Managers store user data in directory servers or RDBMS: if > you know enough of the data format used, you can just use an existing > connector (LDAP [2] or DB [3]) and apply the same ideas as (1). > > 3) Use Syncope as authentication resource for the Access Manager > > In this case the Access Manager will authenticate users by considering > Syncope an user repository: comparing to cases above, no propagation of > data from Syncope to external is required. > > For CAS, I guess that this would imply writing a Syncope authentication > handler, similar to JDBC [4] or LDAP [5] but empowering Syncope REST > interface. > > > 4) Enable SSO for Syncope admin console > > This is the case covered by Massimiliano's posts. > Basically, you have to review the authentication component in Syncope > core [6] and the Login page of the admin console [7] and put there some > SSO logic (that is, of course, completely depending on the actual > Access Manager). > > By empowering OpenAM features, for example, Massimiliano shows how to > let the > Syncope admin console work as a Windows domain application. > > > Hope this clarifies. > Regards. > > [1] https://github.com/Tirasa/ConnIdOpenAMBundle > [2] https://github.com/Tirasa/ConnIdLDAPBundle > [3] https://github.com/Tirasa/ConnIdDBBundle > [4] https://wiki.jasig.org/display/CASUM/JDBC > [5] https://wiki.jasig.org/display/CASUM/LDAP > [6] > https://svn.apache.org/repos/asf/syncope/branches/1_0_X/core/src/main/java/org/apache/syncope/core/security/SyncopeAuthenticationProvider.java > [7] < a href="https://svn.apache.org/repos/asf/syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/pages/Login.java";>https://svn.apache.org/repos/asf/syncope/branches/1_0_X/console/src/main/java/org/apache/syncope/console/pages/Login.java > > -- > Francesco Chicchiriccò > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~ilgrosso/
