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
--
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
