Scott, Will the case of the context CAS or cas make a difference how cas will respond to a serviceValidate request?
We have experimented with this and for some reason, when Spring Security issues a serviceValidate request (and the URL of the request seems to be properly formatted by inspecting the logs), cas goes into the login-webflow and eventually winds up responding with the login page. When we go through the process by hand, the same serviceValidate request returns the userid (or a validation error) as expected -- it does not go through the login-webflow at all. Why would CAS treat a serviceRequest as a login request? Where does that decision get made? This is a very frustrating problem! Thanks, Barry ________________________________________ From: Scott Battaglia [[email protected]] Sent: Friday, January 22, 2010 8:41 AM To: [email protected] Subject: Re: [cas-user] Problem with CAS ticket validation / Spring Security I'm not sure if it makes a difference but have you deployed it as CAS or cas ? I see both in the email. Cheers, Scott On Thu, Jan 21, 2010 at 1:20 PM, Barry Silk <[email protected]<mailto:[email protected]>> wrote: I hope someone could please help diagnose this problem. I cannot determine whether the problem is with CAS or Spring Security We are using: -- CAS server 3.3.5 -- CAS client 3.1.10 -- Spring Security 3.0.1 I have attached the Spring Security configuration file plus the log files that illustrate what the problem is. The first step is attempting to access a protected resource in the web-app (APLITS) using the following url: https://ob-2068:9443/APLITS Then the Web-app/Spring Security redirects to CAS to the login page with the following URL: https://ob-2068:8443/CAS/login?service=https%3A%2F%2FOB-2068%3A9443%2FAPLITS%2Fj_spring_cas_security_check The user successfully logs in with username/password and the ticket gets added to the registry: (from log) Added ticket [ST-1-HHnUWSpCMrPOfcfcyq0f-cas] to registry. Then, CAS redirects the browser to: https://OB-2068:9443/APLITS/j_spring_cas_security_check?ticket=ST-1-HHnUWSpCMrPOfcfcyq0f-cas The web-app processes this url and attempts to issue a serviceValidate back to CAS: (from log) Constructing validation url: https://OB-2068:8443/cas/serviceValidate?ticket=ST-1-HHnUWSpCMrPOfcfcyq0f-cas&service=https%3A%2F%2FOB-2068%3A9443%2FAPLITS%2Fj_spring_cas_security_check But, CAS response with the xml for a login page, instead of returning the userid: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en"> <head> <title>CAS – Central Authentication Service</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <style type="text/css" media="screen">@import 'css/cas.css'/**/;</style> <!--[if gte IE 6]><style type="text/css" media="screen">@import 'css/ie_cas.css';</style><![endif]--> <script type="text/javascript" src="js/common_rosters.js"></script> <link rel="icon" href="/CAS/favicon.ico" type="image/x-icon" /> </head> ... </html> That is the problem. However, instead of going to the application directly and going through the steps by manually specifying the URLs, we get the expected result: https://ob-2068:8443/CAS/login?sevice=https://ob-2068:9443/APLITS results in the CAS login page. Enter the userid and password successfully and CAS redirects to: https://ob-2068:9443/APLITS/j_spring_cas_security_check?ticket=ST-3-yEMDMjhbtWoHnYgXce1S-cas Redeeming this ticket manually through the browser: https://OB-2068:8443/CAS/serviceValidate?service=https://OB-2068:9443/APLITS/j_spring_cas_security_check&ticket=ST-3-yEMDMjhbtWoHnYgXce1S-cas Results in CAS returning the authenticated userid as expected? My question is, why doesn't it work with the spring security configuration, which appears to be generating the proper serviceValidate request to CAS?? THANKS for any insight you can provide for this. Barry Silk -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
