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]
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/
