<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Feb 18, 2016 at 10:29 PM Paul B. Henson <<a href="mailto:henson@cpp.edu">henson@cpp.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As far as the URL you configure into a CAS client, it's just "<a href="https://idp.cpp.edu/idp/profile/cas/login" rel="noreferrer" target="_blank">https://idp.cpp.edu/idp/profile/cas/login</a>" etc, right?<br></blockquote><div><br></div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Second, I'm not clear as to the state of the CAS /logout functionality.</blockquote><div><br></div><div>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:</div><div>1. User is in charge of whether to kill app sessions.</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If a CAS client wants a CAS logout URL, should you point them at /idp/profile/Logout?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I'm not really looking for a full-fledged log out of every application you've accessed</blockquote><div><br></div><div>By default the user is in control of that choice in the IdP.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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</blockquote><div><br></div><div>You will get that immediately upon landing at /idp/profile/Logout.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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-/.</blockquote><div><br></div><div>I'll add a configuration example.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am I configuring the clients to trust the idp?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?</blockquote><div><br></div><div>Yes, which is a requirement of the CAS protocol.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br></blockquote><div><br></div><div>That was the idea when I wrote it, but looking at it now from a support perspective seems like a bad idea.</div><div><br></div><div>M</div><div><br></div></div></div>