Oook, I may be on the verge of feeling as stupid as I've ever felt in 20+ years of being a professional.
My, yes, I guess assumption was that SSO basically threw a cookie with a token on the client machine and anytime that client machine needed to verify authentication it sent that cookie back to the SSO server and the server returned that the user was authenticated (added principal to session). And that this would happen from any application that was configured to use that service (thus, you only had to authenticate once for x number of configured client applications). I want to make sure: So you're saying that for each application configured to use CAS I am going to have to interactively authenticate the user and that is correct functionality? I think I misunderstood you though, because at that point SSO provides no benefit over a centralized LDAP directory for authentication that I can see off the top. More confused than ever, heh, Gerald ----- Original Message ----- From: "Scott Battaglia" <[email protected]> To: [email protected] Sent: Wednesday, June 24, 2009 8:42:08 PM GMT -06:00 US/Canada Central Subject: Re: [cas-user] SSO Not So SSO The second application will show that because it hasn't authenticated with CAS yet. Client applications don't magically know they're authenticated because another application has authenticated :-) They still need to communicate with the CAS server. That message indicates that no authentication information was found in the application's session. It will then redirect to CAS. On Wed, Jun 24, 2009 at 6:31 PM, Gerald D. Anderson < [email protected] > wrote: Sorry folks, another thought. After I authenticate it knows it's authenticated and everything works just fine, so it would seem I'm getting what I need back from the server. I fully understand that I could be woefully wrong and not understanding anything ; ) Also, I get the feeling that this: 2009-06-25 00:49:42,076 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] no ticket and no assertion found is significant when the 2nd app tries to authenticate. Google tells me that it's something to do with service urls, but from any documentation I've found I THINK they're correct. Gerald P.S. Really sorry, I don't mean to spam, I'll shut up now. ----- Original Message ----- From: "Scott Battaglia" < [email protected] > To: [email protected] Sent: Wednesday, June 24, 2009 8:23:36 PM GMT -06:00 US/Canada Central Subject: Re: [cas-user] SSO Not So SSO I'm not sure I see a question in here. Are you saying your SSO is not working? Try running CAS over SSL and not just HTTP. The cookies won't transmit over HTTP unless you change the CAS configuration, but that's insecure. -Scott On Wed, Jun 24, 2009 at 6:08 PM, Gerald D. Anderson < [email protected] > wrote: Greetings all, So I finally got far enough that I can authenticate my applications with CAS, it all works perfectly. . .well, almost. Here's the lowdown: I have a company that has a Liferay 5.2.2 portal configured to authenticate against a CAS 3.3.2 server. Here's that configuration: ========BEGIN CODE========= Login URL = http://www.mysite.com/cas/login Logout URL = http://www.mysite.com/cas/logout Server Name = http://www.mysite.com Service URL = http://www.mysite.com/portal/c/portal/login Validate URL = https://www.mysite.com:8443/cas/proxyValidate =========END CODE========= This seems to work fine itself and I receive the following when authenticating: ========BEGIN CODE========= 2009-06-25 00:49:08,231 INFO [STDOUT] 2009-06-25 00:49:08,230 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <AuthenticationHandler: org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler successfully authenticated the user which provided the following credentials: [username: bart_simpson]> 2009-06-25 00:49:08,232 INFO [STDOUT] 2009-06-25 00:49:08,232 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-24-oXp1xSrR2ZP4Skfwp9pe-cas] for service [ http://www.mysite.com/portal/c/portal/login ] for user [bart_simpson]> 2009-06-25 00:49:08,454 INFO [STDOUT] 00:49:08,453 ERROR [SerializableSessionAttributeListener:48] edu.yale.its.tp.cas.client.CASReceipt is not serializable and will prevent this session from being replicated =========END CODE========= I also have a JBoss Seam 2.1.2/Icefaces 1.8.1 application that I've written that needs to be integrated into the above portal. I don't really want to portlet-ize the application so I've decided to run it in an IFrame portlet on liferay. My answer to the authentication/authorization issues was just to use the CAS server and SSO the application. Thus, the theory was that when they logged into the portal, and went to the portal page that contained the iframe with the application they'd already be authenticated and life would be good. The good news is that the application can/will authenticate against CAS just fine as an independent entity. Below is what I get: ========BEGIN CODE========= 2009-06-25 01:00:53,585 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] no ticket and no assertion found 2009-06-25 01:00:53,623 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] Constructed service url: http://www.mysite.com/myApp/applicationPage.seam 2009-06-25 01:00:53,623 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] redirecting to " http://www.mysite.com/cas/login?service=http%3A%2F%2Fwww.mysite.com%2FmyApp%2FapplicationPage.seam " 2009-06-25 01:01:02,558 INFO [STDOUT] 2009-06-25 01:01:02,558 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <AuthenticationHandler: org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler successfully authenticated the user which provided the following credentials: [username: bart_simpson]> 2009-06-25 01:01:02,559 INFO [STDOUT] 2009-06-25 01:01:02,559 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-25-BhteqnB7WCgewymVQ0kn-cas] for service [ http://www.mysite.com/myApp/applicationPage.seam ] for user [bart_simpson]> 2009-06-25 01:01:02,634 DEBUG [org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter] Attempting to validate ticket: ST-25-BhteqnB7WCgewymVQ0kn-cas 2009-06-25 01:01:02,634 DEBUG [org.jasig.cas.client.validation.Cas20ServiceTicketValidator] Placing URL parameters in map. 2009-06-25 01:01:02,634 DEBUG [org.jasig.cas.client.validation.Cas20ServiceTicketValidator] Calling template URL attribute map. 2009-06-25 01:01:02,634 DEBUG [org.jasig.cas.client.validation.Cas20ServiceTicketValidator] Loading custom parameters from configuration. 2009-06-25 01:01:02,634 DEBUG [org.jasig.cas.client.validation.Cas20ServiceTicketValidator] Constructing validation url: http://www.mysite.com/cas/serviceValidate?&ticket=ST-25-BhteqnB7WCgewymVQ0kn-cas&service=http%3A%2F%2Fwww.mysite.com%2FmyApp%2FapplicationPage.seam 2009-06-25 01:01:02,634 DEBUG [org.jasig.cas.client.validation.Cas20ServiceTicketValidator] Retrieving response from server. 2009-06-25 01:01:02,637 WARN [org.apache.tomcat.util.http.Parameters] Parameters: Invalid chunk ignored. 2009-06-25 01:01:02,642 DEBUG [org.jasig.cas.client.validation.Cas20ServiceTicketValidator] Server response: <cas:serviceResponse xmlns:cas=' http://www.yale.edu/tp/cas '> <cas:authenticationSuccess> <cas:user>bart_simpson</cas:user> </cas:authenticationSuccess> </cas:serviceResponse> 2009-06-25 01:01:02,646 INFO [org.jasig.cas.client.proxy.ProxyGrantingTicketStorageImpl] No Proxy Ticket found for 2009-06-25 01:01:02,646 DEBUG [org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter] Successfully authenticated user: bart_simpson 2009-06-25 01:01:02,648 DEBUG [org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter] Redirecting after successful ticket validation. =========END CODE========= Remember, that's authenticating the application as itself from scratch, not through the portal. Now, logout, restart the browser, whatever. When I log into the portal and navigate to the page with the iframe it's still redirecting me back to the cas login page with the following logs: ========BEGIN CODE========= 2009-06-25 00:49:42,076 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] no ticket and no assertion found 2009-06-25 00:49:42,076 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] Constructed service url: http://www.mysite.com/myApp/applicationPage.seam 2009-06-25 00:49:42,076 DEBUG [org.jasig.cas.client.authentication.AuthenticationFilter] redirecting to " http://www.mysite.com/cas/login?service=http%3A%2F%2Fwww.mysite.com%2FmyApp%2FapplicationPage.seam " =========END CODE========= Forcing me to log in again thus defeating the entire purpose of the SSO. I'm sure I've got something set up wrong, but can't find it and am looking for any help I can get. I'm a little over my head with this stuff as I have less than a week (6/30) to get all this stuff up and running having never messed with CAS or SSO before. Below is the web.xml for the application: ========BEGIN CODE========= <filter> <filter-name>CAS Authentication Filter</filter-name> <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> <init-param> <param-name>casServerLoginUrl</param-name> <param-value> http://www.mysite.com/cas/login </param-value> </init-param> <init-param> <param-name>service</param-name> <param-value> http://www.mysite.com/myApp/applicationPage.seam </param-value> </init-param> </filter> <filter> <filter-name>CAS Validation Filter</filter-name> <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class> <init-param> <param-name>casServerUrlPrefix</param-name> <param-value> http://www.mysite.com/cas </param-value> </init-param> <init-param> <param-name>service</param-name> <param-value> http://www.mysite.com/myApp/applicationPage.seam </param-value> </init-param> </filter> <filter> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name> <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class> </filter> <filter-mapping> <filter-name>CAS Authentication Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS Validation Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> =========END CODE========= As stated earlier the CAS Server is 3.3.2, Liferay, I believe uses Yale CAS 2.0 and my application is using ja-sig java client 3.1.6. I don't suspect that any of that should be an issue, but there it is in case ; ) Thanks!! Gerald -- 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 -- 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 -- 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
