CAS protocol questions

[Marvin Addison]

On Thu, Feb 18, 2016 at 10:29 PM Paul B. Henson <henson at cpp.edu> wrote:

> As far as the URL you configure into a CAS client, it's just "
> https://idp.cpp.edu/idp/profile/cas/login" etc, right?
>

Correct. We just went through a huge transition here and a common pitfall
was configuring the component that redirects to CAS, but not the one that
does the ticket validation. Many clients break those out, so make sure you
configure the other one to /idp/profile/cas/serviceValidate (or
samlValidate if you use SAML).

Second, I'm not clear as to the state of the CAS /logout functionality.


It does what the Jasig CAS server did: end the session and (optionally)
send logout messages to all services accessed during the SSO session. Two
notable differences:
1. User is in charge of whether to kill app sessions.
2. Logout messages are sent from the browser via iframes to address the
back-channel problems imposed by load balancers. Now the messages have a
decent chance of working for HA services.


> If a CAS client wants a CAS logout URL, should you point them at
> /idp/profile/Logout?


You can point them at either that endpoint or the CAS-protocol-specific
one, /idp/profile/cas/logout, which is an alias of the former. I would
recommend the IdP logout for consistency.


> I'm not really looking for a full-fledged log out of every application
> you've accessed


By default the user is in control of that choice in the IdP.


> I really only want the basic functionality the CAS logout itself used to
> provide, destroying the CAS/idp login session itself and preventing any
> future application logins


You will get that immediately upon landing at /idp/profile/Logout.


> I don't really want to show a user a screen listing their established
> application sessions and giving them the option to try and destroy them, I
> just want to show them a "Logout successful" type of screen like you get
> when you go to /cas/logout on an actual CAS server. Is there any way to do
> that?
>

Simply customize logout.vm. That said I don't get not giving the user a
choice. The only argument in my mind is they don't understand the choice,
but the best solution there is awareness and education.

Third, step four of the quickstart says to "Configure SSL/TLS trust
> (optional; only required for CAS proxy support)" but then it's never
> mentioned again in the rest of the document 8-/.


I'll add a configuration example.


> Am I configuring the clients to trust the idp?


No, you're configuring the HTTP machinery of the IdP to trust your clients
since proxy callbacks originate at the IdP and terminate at clients.


> Other than using commercially signed certificates whose root CA's were in
> the default Java keystore, I don't recall having to do anything special on
> our CAS servers for proxy support.
>

There has never been any good documentation to my knowledge about the
security model for proxy validation, but the proposition is that proxying
is a substantial increase in privileges and ought to require additional
security controls. If you trust everything that presents a valid commercial
cert, there's hardly any additional security from that. I'll stick my neck
out and say zero security. That's what you get using the default Java
truststore.

The configuration machinery for proxy trust in the IdP forces deployers to
think about the trust model. If you have a local CA that issues your server
certs, trusting that one CA certificate is sufficient. If you don't, then
the only viable alternative is listing the end-entity certificates of the
hosts you intend to permit to proxy. Of course that presents a maintenance
burden, but it's really the only viable alternative that provides any real
security.

Fourth, if a CAS client is configured in cas-protocol.xml but has no
> attribute release policy matching it, does it get the username when it
> authenticates?


Yes, which is a requirement of the CAS protocol.


> Finally, the section at the bottom of the cas-protocol.xml file labeled
> "Advanced CAS configuration", is that referring to writing your own actual
> Java code to replace the code that comes with the idp?
>

That was the idea when I wrote it, but looking at it now from a support
perspective seems like a bad idea.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160219/11e30790/attachment.html>