CODEWITHSUNDEEP
javacookiessingle-sign-oncasjsessionid
IAmYourFaja
IAmYourFaja

Reputation: 56944

CAS SingleSignOutFilter

I followed the CAS Best Practices for building a cas.war (v4.0.0) and deploying it to Tomcat7. When I spin up Tomcat, I am able to access my CAS login page at:

https://localhost:8443/cas/login

I then deploy one of my "client" apps (a Grails web app using Shiro for authentication), which comes online at:

http://localhost:9100/myapp

I go to an authenticated URL for myapp:

http://localhost:9100/myapp/secret

I am successfully redirected to my CAS login page (for now, I'm using the default casLoginView.jsp). I check my browser cookies, and for the CAS site I have a JSESSIONID. I login using the CAS default credentials (username is casuser; password is Melon) and am successfully redirected to http://localhost:9100/myapp/secret. Great success! I check my cookies again and see that I have the same JSESSIONID as well as a new CASTGC cookie.

I now go directly to my CAS logout page:

https://localhost:8443/cas/logout

I see a "Logout successful" message, and check my cookies again. The CASTGC cookie is gone, and I still have a JSESSIONID, however, it's a different JSESSIONID than the first one I got.

I now go back to my authenticated URL:

http://localhost:9100/myapp/secret

I expect to be redirected to the CAS login page: instead I am allowed to view the /secret page and appear to still be authenticated, even after logging out!!!

I believe I need to implement the SingleSignOutFilter by placing it in myapp's web.xml as instructed here.

What I need to know:

Upvotes: 3

Views: 2495

Answers (1)

Petr Bodnár
Petr Bodnár

Reputation: 558

What I need to know:

  • Will configuring SingleSignOutFilter in web.xml complete my implementation for single sign out, or is there more config that I need to do?

Yes, definitely. But for avoiding leaking resources, you should follow the guides and also add a SingleSignOutHttpSessionListener to your web.xml. See the official Java client documentation for a complete setup on the client side. Don't forget to switch the Github page to whichever CAS client version you use. (And beware that it might contain typos.)

  • Once single sign out is implemented, will it have the expected behavior that I describe above? Meaning, if I go to the /logout link, then anytime I try to go to an authenticated URL, it should redirect me back to the /login page?

Sure, that's the point of the Single Log Out mechanism - it destroys all sessions in the corresponding client applications - provided they are able to handle the logout callbacks made from CAS on /logout.

  • How can I tell which protocol (CAS 2.0 or SAML 1.1) I'm using? I should be using whatever default CAS 4.0.0 ships with as I didn't override anything in my project.

If you don't know of configuring SAML for your CAS or client application, then you definitely use the CAS protocol.

  • What is the difference between JSESSIONID and CASTGC? How are they handled/used different by the server?

The CASTGC cookie is the holder of the identifier of your CAS session (sessions, technically tickets, are managed by CAS in its own Map-like structures). This is the secret only you and the CAS server know. The JSESSIONID cookie is used by Java applications to identify your application session, as defined by the Java Servlets specification. Specifically, CAS uses it mainly for keeping track of your current singing-in process.

  • Do I need to configure anything in cas-servlet.xml to get single sign out working? If so, what? If not, what is this file used for?

No, you don't. But you might read e. g. the official Apereo documentation that describes the principles and possible customizations of the SLO functionality on the server side.

Upvotes: 2

Related Questions