Re: Making CAS authentication parameterizable

Hi Stephen

Thanks a lot for these very extensive information; I could implement those changes easily. I have one more question though; I had read somewhere that the CAS 2.0 service validation was returning an XML document instead of a simple list of string; did I miss something?

Cheers

Jean-Noel

Stephen A. Cochran wrote:

You don't have to have the CAS server pass the info back, you could  
also have the application look up the necessary fields in your  
directory system (database, LDAP, whatever). I just feel that's added  
complexity which would be nice to handled by the CAS server. Easier  
for app developers to integrate, and less load on the directory server.

I extended the Principal class, simply adding the new fields I wanted  
and adding access methods. Very simple. I think I also had to modify  
the CredentialToPrincipalResolver class. The changes in the  
deployerConfigContext.xml file are all pretty standard, calling the  
correct auth handler and setting the correct CToPResolver is all  
that's needed.

I'm hoping to document the changes I made in a How-To format, but  
won't happen for a few weeks at least. The changes I made are all  
viewable through our subversion repository though:

<https://dev.dartmouth.edu/projects/softdev/webAuth/browser/server/ 
tags/3.0.4-Production/localPlugins/src>

The classes you'd be most interested in are:
	DartmouthPrincipal.java
	DartmouthUsernamePasswordCredentialsToPrincipalResolver.java
	PrincipalBearingCredentialsToDartPrincipalResolver.java
	X509CertificateCredentialsToDartIdentifierPrincipalResolver.java

Also, to return those new fields you have to modify the jsp file that  
generates the XML response:
	casServiceValidationSuccess.jsp: <https://dev.dartmouth.edu/projects/ 
softdev/webAuth/browser/server/tags/3.0.4-Production/webapp/WEB-INF/ 
view/jsp/default/protocol/2.0/casServiceValidationSuccess.jsp>
	
Modification to the clients to extract the new fields from the XML  
are also required. This is the biggest gotcha, it means you can't  
simply use the standard clients out-of-the-box. Also the biggest  
reason why I hope the CAS project standardizes on a way to add  
attributes to the response. It's fairly easy to design the clients to  
pull out any XML fields and create some kind of hash or array  
appropriate to the programming language. We've been slowly adding  
client support here, we currently have an apache module, plsql  
procedure, ruby module, and a java filter. Next on my list is a perl  
module.

Only the apache module is currently in the subversion directory, they  
are all a little rough right now. I'm hoping to clean them up and get  
them in there in a releasable state.

Steve


On Dec 11, 2006, at 6:42 AM, Jean-Noel Colin wrote:

  

Thanks a lot for your response; I fully agree with you, it's more  
an authorization problem. I will look into the way you propose,  
i.e. having the application make the authorization decision. I  
guess I have to write my own Principal and  
CredentialToPrincipalResolver classes, and then update the  
deployerConfigContext.xml file. Is this correct?
    

_______________________________________________
Yale CAS mailing list
cas-c5E7yoNEsvRIM2btvs0Z1A@xxxxxxxxxxxxxxxx
http://tp.its.yale.edu/mailman/listinfo/cas