[cas-dev] a quick start for CAS3 (Was: esup-casgeneric 2.0.7)

[Velpi]

>> CAS supports multiple AuthenticationHandlers through the usage of the 
>> default AuthenticationManagerImpl (with the option for people to provide 
>> their own AuthenticationManager).
> One thing that can not be done with the actual GH is aliasing, let me 
> explain. Three years ago, a French working group, made up of Fench 
> experts and driven by our Ministry of Education, emitted recommendations 
> on the way identity management should be done in French schools and 
> universities (I was part of the group, named AAS - Authentication, 
> authorization and SSO). One of recommendations was aliasing, i.e. 
> letting users authenticate with an alias they choose (up to the identity 
> provider to insure that both logins and aliases are unique). This is 
> impossible with the actual GH since the main authentication class (the 
> one that calls specific handlers) implements WatchfulPasswordHandler, 
> when TrustHandler was needed. There is a real need for this in our 
> community, so I can not go on with new developments without adding this 
> to my roadmap (except if it is possible already with the CAS3, please 
> confirm).
I think you can do that now already, up to a certain level. Aliasing for 
authentication shouldn't be a problem when using the search&bind LDAP handler.
I'm trying to solve a similar thing for x509 logins right now:
Build a custom CredentialsToPrincipalResolver that does a lookup in the user 
repository to search the right principal for the alias (in the x509 case the 
"alias" is part of the certificate). (this means we can use username/password 
and x509 interchangeable, possibly forcing users with an attribute in the 
repository)


> However, I am not satisfied with AuthenticationManagerImpl, let me 
> explain you why (maybe I am wrong because I did not spend much time on 
> it). I would like to rely on several handlers, and I would like all the 
> handlers to provide the 'aliasing' feature (see above). With the 
> AuthenticationManagerImpl actually provided, the authentication id 
> performed this way:
> stage 1. all the authentication that support the credentials supplied 
> are tried until one succeeds.
> stage 2. all the principal resolvers (that also support the credentials) 
> are tried until one succeeds.
> If this architecture fits with most of the needs, it is clearly not 
> sufficient if we have several handlers, some of them implementing the 
> aliasing feature. In this case, the handler that authenticates is the 
> only one that can resolve the principal. BTW, I think it is the same 
> with metadata populators.
I don't see the problem here since the failed resolvers/handlers will not cause 
any problems, then again I might be missing sth...
However last week it also came to my mind that in some situation it might be 
better to be able to appoint a certain Cred2PrincipResolver to a certain 
authHandler. (or assigning groups to groups or so)

> I do not see how we can use AuthenticationManagerImpl, for instance if 
> authenticating with two LDAP directories, with two possibilities:
> 1. bind with the credentials supplied (may be successful if the netId is 
> a uid)
> 2. search the DN that corresponds to the username (thanks to a filter on 
> an 'alias' LDAP attribute), and then bind with the DN and the passsword 
> supplied (may be successful if the netId is an alias).
> This probably needs further developments, I really need your opinion on 
> this.
If I'm not mistaken, 1&2 are performed automatically by the 
BindLdapAuthenticationHandler (does search&bind). It can also be configured to 
be succesfull if the netid should be equal to another LDAP attribute (I'm sure 
the genericHandler supports this too because we're using that now).


>>   CAS also supports redirect at logout 
>> via the service parameter (I don't recall if this is the same parameter 
>> you used).  
> Good, I will test it.
I seem to have missed that until now. I read about it serveral times, but that 
feature is really well hidden (a boolean in the LogoutController seems to turn 
it on). I suggest to turn it on by default. (we actually implemented a redirect 
in our view because we couldn't find it... until now)
The parameter is exactly the same: "?service=", which is extremely great!


>> We're also heavily utilizing Spring's Internationalization 
>> support (you actually supplied us with one of the properties files ;-)), 
>> though we are open for suggestions to make this even easier.    
> Bundles are ok for me.
>> All of 
>> our HTML is currently stored in JSP pages, which hopefully should make 
>> customization easy.
> Sure.
I'd like to confirm that. But some more guidelines might be a good idea. Usually 
layout people have to make those pages, and they're not always that savvy about 
CAS ;).

>> What additional logging did the Generic Handler provide? (especially in 
>> terms of the French Identity Federation).
>>   
> All the members of the French identity federation must be able to know 
> where users are connected (on which client) when logging in (for 
> traceability). This implies logging date/uid/client tuples each time a 
> user logs in; I recently added this feature to the GH. If it is not 
> already present in CAS3, this is a minor enhancement only.
I had to remove the user IP logging feature(only that one) when I built the GH 
for CAS3 since you don't have access to the request object in an authHandler. 
That logging doesn't really belong to the responsibilities of an authHandler 
anyway...
The date/uid/clientIP(/CAS_service/vended_ticket) information is certainly 
something that would be interesting to be logged (seperately). It can be asked 
to trace back the user (by the police)...


>> Out of the box, CAS provides many of the same handlers the Generic 
>> Handler project provided including database and LDAP plus X.509 support 
>>   
> I only found jars for these handlers. Are the sources also distributed? 
> Or did I just miss them?
CVS
(web: http://developer.ja-sig.org/source/viewrep/jasig/cas3)

>> We do not support a way however for the user to silently upgrade by 
>> using their existing configuration files (which is probably very important).
>>   
> Yes it is. This is obviously a quick start feature, see below.
*Maybe* it's a good idea to split out the authentication configuration to an 
entirely separate configuration file (preferably outside of the CAS webapp), as 
that will make updating a lot easier (most people use the defaults anyway, 
except for authentication of course, I may hope).


>> It seems like it would be a good idea for the CAS team and the Generic 
>> Handlers team to collaborate on additional Authentication Handlers and 
>> quick starts.
(I said this before I think) What made CAS2 popular (for us) is the quickstart 
from ESUP with the GH [so let me explicitly say THANK YOU here from a looot of 
people]. I think CAS3 won't be adopted that fast if there's no really easy way 
to set it up. Then again, it would be great if every deployer knew CAS3 
perfectly before setting it up (but we're not living in that fantasy world).


--Velpi