[cas-dev] [casgeneric-users] Re: PrincipalConverter

[Pascal Aubry]

Scott Battaglia wrote:
> Pascal,
Hello Scott,
>
> One problem I immediately see is that this solution will result in a 
> duplicated effort.  Out of the box, CAS3 provides:
>
> * LegacyPasswordHandlerAdaptorAuthenticationHandler (accepting CAS2 
> PasswordHandler)
> * AcceptsUsersAuthenticationHandler (simply has a map of acceptable 
> username/passwords)
> * FileAuthenticationHandler (reads from a file)
> * RejectUsersAuthenticationHandler (list of names to reject)
> * BindModeSearchDatabaseAuthenticationHandler
> * QueryDatabaseAuthenticationHandler
> * SearchModeSearchDatabaseAuthenticationHandler
> * BindLdapAuthenticationHandler
> * FastBindLdapAuthenticationHandler
> * PrincipalBearingCredentialsAuthenticationHandler (gets user from 
> request.getRemoteUser())
> * X509CredentialsAuthenticationHandler (for X.509 Certificates)
> * HttpBasedCredentialsAuthenticationHandler (for authenticating SSL 
> certificates)
> * TestAuthenticationHandler (for username=password)
>
> You'll notice most of those are based on the GenericHandler project ;-)
Thanks ;-)
>
> CAS 3.0.6 will also most likely include a handler for SPNEGO and 
> RADIUS on top of the above handlers.
Please add the handlers above to the 3.0.6 distribution, as there were 
not in 3.0.5-rc1.
> Note that the majority of these AuthenticationHandlers  (i.e. the ones 
> that accept UsernamePasswordCredentials) can simply use the 
> UsernamePasswordCredentialsToPrincipalResolver in every case EXCEPT 
> the aliasing case.  Because of this, I would recommend keeping the 
> AuthenticationHandler and the CredentialsToPrincipalResolver as two 
> separate interfaces rather than combining them (it allows for easier 
> re-use).  If there needs to be a specific 
> AuthenticationHandler->CredentialsToPrincipalResolver association that 
> can easily be handled in a custom AuthenticationManager.  
Exactly what I thought of: a custom authentication manager that would 
have a list of AuthenticatorResolverAndPopulators. I believe code 
redundancy will be minimized by inheriting actual AuthenticationHandlers 
and pointing to actual resolvers. I may have something to show at the 
end of August; until then you will find attached what could be the 
properties file of the quick start. Guidelines with this file would 
simply be:
1. download and unzip
2. edit build.properties to fit to your configuration
3. run 'ant install', 'ant start' and test.
I also thought of an interactive ant target to write it automatically by 
asking users a few questions.
> If this complicates the configuration (I'm not convinced it will 
> though), Spring provides ways of providing custom (i.e. easier) XML 
> configuration via XMLSchemas.  By keeping the APIs the same we are not 
> forcing people to learn two separate APIs  (i.e. the "CAS" API and the 
> "ESUP-Portail" API) or forking the userbase to provide slightly 
> different configuration options.  The same API would thus allow 
> tighter integration between the two projects as well as more code 
> re-use (and making it easier for pure CAS deployers to leverage some 
> of the ESUP-Portail stuff).
Sure, we have to keep this in mind.
Time to leave for three weeks now ;-)
Cheers,
PA
>
> -Scott
>
> Scott Battaglia
> Application Developer, Architecture & Engineering Team
> Enterprise Systems and Services, Rutgers University
> v: 732.445.0097 | f: 732.445.5493 | scott_battaglia at rutgers.edu
>
>
> Pascal Aubry wrote:
>> Stephen A. Cochran wrote:
>>> On Jun 27, 2006, at 4:11 AM, Velpi wrote:
>>>
>>>  
>>>> That's certainly a solid solution, but it's not configurable at  
>>>> all, am I right?
>>>> It would be great if another principal like yours could actually 
>>>> be  configured
>>>> to replace the default SimplePrincipal (most people don't like to  
>>>> change the
>>>> code to much, certainly because it's usually a (fatal) annoyance  
>>>> when upgrading).
>>>>     
>>>
>>> Not configurable without recompiling and deploying, true. But it's  
>>> not something that I would see changing often.
>>>
>>> I agree about changing code, which is why I didn't just change the  
>>> SimplePrincipal class, I made a new class. I also did the same with  
>>> all of the Auth handlers, mostly just duplicated and renamed to be  
>>> something like x509DartAuthenticationHanlder. This avoids the 
>>> upgrade  problems because I didn't touch the distribution code. 
>>> Thinking back,  the x509 one was really the only default one I had 
>>> to duplicate/ change. Wrote my own User/Pass because of our unusual 
>>> directory system.
>>>
>>> I guess to save duplicating auth handlers and making only a minor  
>>> change a config option on what default Principal class to use would  
>>> solve the problem assuming Java lets you do something like that.  
>>> Honestly what I did was not difficult, considering at the time I  
>>> didn't know anything about the structure of CAS and hadn't worked  
>>> with a Java app since before ant/tomcat/maven etc existed. I also  
>>> don't see the benefit in being able to reconfigure the Principal  
>>> without redeploying, I can't imagine I'd ever use that functionality.
>>>
>>> Steve Cochran
>>> Dartmouth College
>>> _______________________________________________
>>> cas-dev mailing list
>>> cas-dev at tp.its.yale.edu
>>> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>>>   
>> Thank you Scott, Velpi and Stephen for your answers, I think the 
>> problem is clearer to me now.
>>
>> I agree with Velpi when he says that it is important not to have code 
>> to write at all. Even if it is quite simple for us, it is not at all 
>> for most of the people that deploy CAS; just think that they even do 
>> not Java (nor XML sometimes). Moreover I know people who customized 
>> their CAS server but never upraded.
>>
>> IMHO, the goal of the quick start is not to make everything possible 
>> with it; people who want to do fancy things with CAS will use the 
>> original distribution, and adapt it for their needs. The goal of the 
>> quick start is to make it possible for 90% of the CAS deployers to 
>> deploy it in the simplest way, i.e. by using a properties file (yes, 
>> XML beans are much more difficult than properties). In a second step, 
>> let's say that 99% should be able to deploy CAS by simply editing 
>> properties files or beans. At least, the rest (1%) should be able to 
>> write Java code for CAS to fit to their environment, which is 
>> probably everything but standard (I believe your are in this case 
>> Stephen); anyway, people relying on specific configurations are 
>> prepared to this (note: once you have Java code to write, there are 
>> many ways to do it, and the most clever way is obviously the one 
>> proposed by Stephen - not modifying the distribution code).
>>
>> So let's come back to the quick start. What I intend to propose 
>> responds to 99% of the needs of the community I know the best, i.e. 
>> the French education/research community. These needs will be 
>> satisfied by handlers looking like the ones brought by CAS GH v2, a 
>> little extended to be able to resolve credentials after the 
>> authentication (for what I called previously "aliasing"). I already 
>> started writing things based on an authentication manager having a 
>> list of AuthenticatorResolverAndPopulator instances. You will find 
>> attached a configuration file for such handlers, feel free to comment 
>> and criticize. Note : the configuration of a x509 authentication is 
>> missing, also feel free to complete.
>>
>> PA
>> -- 
>> http://perso.univ-rennes1.fr/pascal.aubry
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> cas-dev mailing list
>> cas-dev at tp.its.yale.edu
>> http://tp.its.yale.edu/mailman/listinfo/cas-dev


-- 
http://perso.univ-rennes1.fr/pascal.aubry

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: build-example.properties
Url: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20060712/a87da562/build-example-0001.pl