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
