CAS protocol questions

Paul B. Henson henson at cpp.edu
Fri Feb 19 14:49:06 EST 2016


> From: Marvin Addison
> Sent: Friday, February 19, 2016 3:54 AM 
> 
> 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.

Eh, it's complicated. For one thing, management doesn't particularly like change, and they probably won't want to introduce this new functionality as part of this upgrade. It's also fairly bleeding edge, and some of our users are using relatively older browsers due to other application requirements. I just want to be prepared for the likely case that when I start demonstrating the development instance they complain about the logout features and request that I simplify it to match the current functionality.

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

Thanks, much appreciated; I'm pretty sure I would have never figured that out on my own :).

If you're in a documentation updating mood, the description of logout under "Notable limitations" could probably benefit from some of what you wrote in this email too :).

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

The proxy callback URL can be any arbitrary server? I thought it had to be a URL in the namespace of the service? So if the CAS service was https://some.service.com/foobar the proxy callback would have to be https://some.server.com/something? So if you are using the default Java CA list you are just trusting nobody would be able to convince a CA to issue an unauthorized certificate for some.server.com? Not that that hasn't happened, but it's still not ridiculously easy to do?

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

Yeah, it would be hard to tell what was happening if other people's random code was doing random things :). I don't think I'll need to go there though, so I think I'll just delete that comment from my config :).

Thanks much for your help.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768




More information about the users mailing list