Gerald, This is the standard ³the SSL certificate of the service you are trying to request is not trusted² error message. I would recommend searching the CAS mail list archives for more information as this has been answered many times:
http://www.nabble.com/CAS-Users-f15449.html A- On 6/25/09 11:15 AM, "Gerald D. Anderson" <[email protected]> wrote: > I'm getting closer, but pulling the following error: > > 2009-06-25 15:05:28,909 ERROR > [org.jasig.cas.client.validation.Cas20ServiceTicketValidator] > javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > > > When I log into the portal, everything is fine. When I go to the page with > the application embedded, I see the above. I have and have double checked > that I have the certificate in the java cacerts and in jboss' keystore file. > I'll keep plugging away, but if anybody can shed some light I'd appreciate it > (again) > > Gerald > > ----- Original Message ----- > From: "Gerald D. Anderson" <[email protected]> > To: [email protected] > Sent: Thursday, June 25, 2009 4:30:29 AM GMT -06:00 US/Canada Central > Subject: Re: [cas-user] SSO Not So SSO > > Got it, working on it now. I do want to throw in just for face purposes that > this is a development environment, there's no way I'd go production without > SSL (it's a SaaS subscription based app, so credit card transactions, etc), > but didn't understand that it was a deal breaker for the process. > > Thanks again all, I'll report back my soon to be success ; ) > > Gerald > > ----- Original Message ----- > From: "Scott Battaglia" <[email protected]> > To: [email protected] > Sent: Thursday, June 25, 2009 7:18:00 AM GMT -06:00 US/Canada Central > Subject: Re: [cas-user] SSO Not So SSO > > You might want to look into how it works: > http://www.jasig.org/cas/cas1-architecture > http://www.jasig.org/cas/cas2-architecture > > Essentially if you purely rely on cookies (like the solutions you're familiar > with) there are some severe restrictions on the services that can work with > your SSO. We (and others) get around them by keeping the SSO cookie ONLY with > the SSO server. Your application redirects to the SSO server and if an SSO > session exists, your browser is sent back to the application with an opaque > ticket that it can validate. If no SSO session exists, it will prompt the > user for authentication. > > However, these cookies rely on SECURE transmissions which is why if you have > SSL turned off, you won't get SSO. > > > On Thu, Jun 25, 2009 at 4:31 AM, Gerald D. Anderson <[email protected]> wrote: >> 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 <http://www.mysite.com/myApp/applicationPage.seam%0A2009-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%2FmyAp >>>> p%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-BhteqnB7WCgewymVQ0k >>>> n-cas&service=http%3A%2F%2Fwww.mysite.com%2FmyApp%2FapplicationPage.seam >>>> 2009-06-25 >>>> <http://www.mysite.com/cas/serviceValidate?&ticket=ST-25-BhteqnB7WCgewymVQ0 >>>> kn-cas&service=http%3A%2F%2Fwww.mysite.com%2FmyApp%2FapplicationPage.seam%0 >>>> A2009-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%2FmyAp >>>> p%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</fil >>>> ter-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.Cas20ProxyReceivingTicketVali >>>> dationFilter</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</fi >>>> lter-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 -- Andrew Feller, Analyst LSU University Information Services 200 Frey Computing Services Center Baton Rouge, LA 70803 Office: 225.578.3737 Fax: 225.578.6400 -- 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
