Hmm...it actually looks like my problem was a server issue. Pinging my server on the server resolved to the localhost IP and pinging it from another machine resulted in the actual IP address...so apache was then unable to find a https virtual host and thus the error message I was dealing with.
On Mon, Apr 5, 2010 at 9:54 AM, Curtis Garman <[email protected]> wrote: > Marvin, so I tried logging in again. When it failed, I took the ticket and > service information provided in the error and hit the cas url you > indicated...this worked (provided my username)...when I tried to access the > same url again, I got an INVALID_TICKET response (again correct because I > already validated the ticket once and the ticket was invalidated). So from > here I conclude that the serviceValidate url is never being called. I think > I forgot to mention this previously, but the url in my address bar when I > get the exception is > https://<server>/portal/Login?ticket=ST-2-Sho5WQoqGIMJTFUDuZQ5-cas > ...which leads me to believe that the cas client is failing before it gets a > chance to make the serviceValidate callback to CAS. Does this make sense? > > The only places that I'm aware of that need to be updated in the portal > config on a fresh copy of the uportal source is > * > web.xml* > > ... > > <context-param> > <param-name>edu.yale.its.tp.cas.proxyUrl</param-name> > <param-value>*https://**<server>**/cas/proxy*</param-value> > </context-param> > > ... > > <filter> > <filter-name>CAS Validate Filter</filter-name> > > <filter-class>edu.yale.its.tp.cas.client.filter.CASValidateFilter</filter-class> > <init-param> > > <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name> > <param-value>*https://<server>/cas/serviceValidate* > </param-value> > </init-param> > <init-param> > > <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name> > <param-value>*<server>*</param-value> > </init-param> > <init-param> > > <param-name>edu.yale.its.tp.cas.client.filter.proxyCallbackUrl</param-name> > <param-value>*https://<server>/portal/CasProxyServlet* > </param-value> > </init-param> > </filter> > > ... > > *sercurity.properties* > > ... > > logoutRedirect.root=*https://<server>/cas/logout?url=https:// > <server>/portal/Login* > > ... > > org.jasig.portal.channels.CLogin.CasLoginUrl=*https:// > <server>/cas/login?service=https://<server>/portal/Login* > > ... > > > Am I missing something else? Am I correct in assuming that all > communication between cas and uprotal is conducted via http/https and thus > as long those ports are open nothing should be being blocked? > > > On Mon, Apr 5, 2010 at 8:54 AM, Marvin Addison > <[email protected]>wrote: > >> > It makes me think that I forgot to use https somewhere >> >> Yeah, I think that's right. >> >> > I can >> > also hit https://<server>/cas/login and https://<server>/cas/logout and >> they >> > work fine >> >> What happens when you hit https://<server>/cas/serviceValidate? >> That's where it looks like the client is blowing up getting a non-SSL >> response when it expects one. >> >> M >> >> -- >> 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 >> > > > > -- > Curtis Garman > Web Programmer > Heartland Community College > -- Curtis Garman Web Programmer Heartland Community College -- 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
