Scott,
I too have a similar requirement of having to send Password to a particular cas client. We are using Cas Server 3.0.7 and Cas Client 2.0.11 along with Acegi, and JDK 1.4.2. Using your suggestion on this thread, I am able to send Password as part of Ticket Response by overriding the CredentialToPrincipalResolver and modifying casServiceValidationSuccess.jsp. On the client side however, based on what I have seen, it seems like the following changes will be needed: 1 - Overriding ServiceTicketValidator to add support for the new field 'password' in validate() method and in Handler inner class 2 - Overriding the TicketResponse 3 - Overriding the CasProxyTicketValidator's validateNow(ProxyTicketValidator pv) 4 - Overriding the CasAuthenticationProvider's authenticateNow method to save the password in custom UserDetails object Am I on the correct path or is there an easy way to achieve the same? I would like to keep the changes to a minimum so that we can move to a newer version of CAS when we switch over to JDK 5. Thanks for your help Rahul ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Battaglia Sent: Monday, October 01, 2007 1:59 PM To: Yale CAS mailing list Subject: Re: Auth handler giving more than Y/N? Troy, You should create a custom CredentialsToPrincipalResolver which returns a complete Principal and attributes such as email address. There is also a AuthenticationMetaDataPopulator for returning information about the actual authentication. -Scott On 9/30/07, Troy Davis <[EMAIL PROTECTED]> wrote: Hi, Is there a clean or recommended way for an authentication handler (custom one extending AbstractUsernamePasswordAuthenticationHandler) to feed data back to the CAS client, beyond accept/reject? Example: user authenticates as "bob" with password "cow". I'd like to return their email address and assorted other data so the calling CAS client can make full use of its local functionality. Other example: return authorization/permissions info beyond just authentication (allow feature1, deny feature2). Anyone know a clean way to do that? As a workaround, is there a way for an AH to get the servlet container and set a cookie that (given correct cookie scope) the caller could honor? Obviously the cookie would be subject to user modification. Troy _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas -- -Scott Battaglia LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
