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 &#8211; 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

Reply via email to