[cas-dev] PrincipalConverter

[Pascal Aubry]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20060703/ed3c59d9/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deployerConfigContext-example.xml
Type: text/xml
Size: 16413 bytes
Desc: not available
Url : http://tp.its.yale.edu/pipermail/cas-dev/attachments/20060703/ed3c59d9/deployerConfigContext-example.xml