IdP3 CAS gateway issues.

[O'Dowd, Josh]

One of our primary use cases using the gateway option is a personal portal landing page, my.umt.edu.  It paints one way for anonymous users, or is customized for authenticated employees or students, respectively.  For session users, the CAS server responds with a ticket, and then the client requests ticket validation which gets a response containing the usual attribute release.

If the IdP simply redirects to the service for both session and non-session scenarios, I am confused why the gateway option would be present at all.

For our purposes, the CAS gateway option is the CAS client’s solution to what I understand the ‘passive authentication’ option to be for the Shibboleth NativeSP.

I have discussed the options for re-developing our existing CAS gateway endpoints to use the NativeSP with passive authentication but they are resistant, I think because they have gotten a little carried away with the PHP-CAS clients using the gateway option.  That’s not a knock on them, but just to explain their current angst.

Anything you can do to help us figure out an IdP solution is going to work, as we are now fully dedicated to Shibboleth IdP for SSO.

Thanks.
-Josh

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Marvin Addison
Sent: Thursday, February 4, 2016 5:58 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: IdP3 CAS gateway issues.

For whatever reason, our CAS clients that are making requests with the gateway=true option for anonymous access, which work well with our CAS server, are not working with the IdP.
There are two situations to consider in gateway mode:

1. You have a valid IdP session
2. You do NOT have a valid IdP session

The CAS protocol [1] says a ticket MAY be returned in the first case; conversely, the ticket MUST NOT be returned in the second.

My recollection is that I intended to _never_ grant a service ticket when a client requests gateway mode. That's likely different from what Jasig CAS does, but it's clearly allowed by the protocol spec.
The IdP is redirecting back to the service without painting a login view as expected, but the redirect does not have any parameters included, namely the ticket, if I already have a session on the IdP.
I'm open to changing the behavior, but I'd need to understand your use case better.

M

[1] https://github.com/Jasig/cas/blob/4.1.x/cas-server-documentation/protocol/CAS-Protocol-Specification.md (the 2.0 spec is MIA on the Web, but the relevant parts are unchanged in 3.0)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160205/d5ce5c7c/attachment-0001.html>