Hi -
I'm working to provide CAS client integration for Sakai in a
sustainable fashion. I've run into some strange discrepancies
regarding CAS and I'm hoping folks on this list will be able to help
me sort through 'best practices'. I appreciate any insight folks can
lend.
First, the documentation for CASifying Sakai ([1] and [2]) and the
documentation on the JA-SIG site [3] depict configuration of 2.1.1
versions of the CAS Java client. However, it is clear from the CAS
wiki that 3.1.x versions are current [4]. Is there a reason that JA-
SIG is still promoting 2.1.1 that I should be aware of, or should I
chalk this up to stale documentation?
Second, Spring Security suggests a model for CAS client integration
which seems a bit foreign. In their reference document SpringSource
depicts configuring a CAS client of their creation [5]. In their
configuration CasAuthenticationProvider is wired up in Spring and must
be supplied with a UserDetailsService whose role appears to be to
provide user attributes from some client-side source. This seems
counter-intuitive and out-of-scope if one is simply aiming to
authenticate a user (clearly the new Saml assertion capabilities of
CAS and the use of Shibboleth make attribute lookup feasible... but
should it really be part of every CAS integration scenario?). Am I
missing something?
Thanks in advance,
Duffy
[1] http://confluence.sakaiproject.org/display/SAKDEV/CASifying+Sakai
[2] http://confluence.sakaiproject.org/display/~steve.swinsburg/
CASifying+Sakai
[3] http://www.jasig.org/cas/client-integration/java-client
[4] http://www.ja-sig.org/wiki/display/CASC/CAS+Client+for+Java+3.1
[5]
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/cas.html#cas-client
------------------------------
Duffy Gillman
Sr. Software Engineer
rSmart
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
