SEC-748: Support and basic implementation for CAS single sign out protocol

[spring-projects-issues]

["Martino Piccinato":https://jira.spring.io/secure/ViewProfile.jspa?name=martino.piccinato](Migrated from ["SEC-748":https://jira.spring.io/browse/SEC-748?redirect=false]) said:

I've seen in SEC-601 you've added support for new cas single sign out protocol but I guess it's "just" new client dependency. I think it could be interesting to provide real support for this.

I have some code I could clean up and submit including a needed filter for cas logout process requests supporting different logout strategies plus a default ehcache based implementation.

If you are interested I'll try to post it as soon as I can (hope to make for 2.0 final...)

[spring-projects-issues]

["Luke Taylor":https://jira.spring.io/secure/ViewProfile.jspa?name=luke] said:

If you'd like to submit a patch for review, I'm sure Scott will take a look at it.

[spring-projects-issues]

["Martino Piccinato":https://jira.spring.io/secure/ViewProfile.jspa?name=martino.piccinato] said:

The patch I attach includes classes and interfaces to manage CAS Single Sign Out protocol. Some tests are included.

There are two filters: one to manage CAS callback logout requests and another one as a replacement for LogoutFilter.

While it's possible to implement other strategies using different CasLogoutCallbackHandler(s), the default implementation it's based on ticket expiration: the cas logout callback request does not actually logout the user but "expires" the ticket, while the CasLogoutFilter will actually start the logout process.

I'm not 100% satisfied with this implementation because there's no guarantee the user will ever go through the logout process (even though CasLogoutCallbakHandler leaves many possibilities open) but I think it's the most current spring-security API respectful solution one can have.

It seems to me that current spring security APi/implementations offer few space for "external" logout (just think about a user that is forcedly logged out by another user), there's no public service/method/interface that would let me recover an Authentication from a Session or any other storage, there's no "LogoutProcess" class and some LogoutHandler (e.g. SecurityContextLogoutHandler) explicitly refer to current request/session to invalidate it. What I mean is that I could have provided a serviceTicket -> Authentication mapping and use it with the callback filter to go through the LogoutHandler(s) and do a "standard" spring-security logout process but the API and existing LogoutHandler implementations just do not seem to encourage such a thing.

It would be interesting to think about an API that is more flexible in this respect but this is obviously something that goes far beyond what I proposed with this ticket.

P.S.

I hope my opinions above are not taken as negative spring-security critiques, I just love this framework :-)

[spring-projects-issues]

["Luke Taylor":https://jira.spring.io/secure/ViewProfile.jspa?name=luke] said:

I'm not quite clear why we need extra functionality for this in the framework, rather than just following the standard recommended CAS logout pattern. What do you think Scott?

[spring-projects-issues]

["Martino Piccinato":https://jira.spring.io/secure/ViewProfile.jspa?name=martino.piccinato] said:

The standard recommended CAS logout pattern does not use Spring Security Authentication objects (as it does not the standard CAS login pattern :-) ). As Spring Security provide integration for CAS login out of the box I though it would have been nice to provide the same for CAS logout.

Let me know if you are insterested as I think I can provide a far better patch/system than the one I previously submitted, using a ticket <-> session mapping as cas client api now does. The only difficulty in doing this as I said above would be having a standard mechanism to retrieve an Authentication from a HttpSession (static method in AbstractProcessingFilter?) and the possibility to inject the same "LogoutProcess" in different beans.

I think that having these last two things would also ease the possiblity of managing user logouts by external processes (I mean by requests/actions not tied to the session/user being logged out)

[spring-projects-issues]

["Scott Battaglia":https://jira.spring.io/secure/ViewProfile.jspa?name=sbattaglia] said:

Martino,

I'm not sure I understand what you mean by "real" support for CAS Single Sign Out. The HttpSessionListener and the provided CAS Single Sign Out filter are the real support for the single sign out filter.

Is there something additional that this needs?

Can you give a run down from a use case perspective (and not an implementation perspective) on what your code is trying to accomplish that doesn't already happen via the CAS Single Sign Out stuff.

Ideally, we'd like as much stuff to remain in the CAS client as that is what transcends projects.

-Scott

[spring-projects-issues]

["Martino Piccinato":https://jira.spring.io/secure/ViewProfile.jspa?name=martino.piccinato] said:

My simple use case for this is having several LogoutHandler that must be called when a user is logging out (or is being logged out), releasing resources and logging the event. I have to pass an Authentication object in order to do this so what is missing is, basically a tiny integration mapping cas tickets and spring security Authentication objects (thing that is already provided for the login process) and providing out of the box a spring security aware cas single sign out filter.

It seems to me that the use of LogoutHandler is an attempt of Spring Security to model a logout process so this should be the correct way to do that in Spring Security while If I'm not wrong CAS Single Sign Out filter and HttpSessionListener deal directly with the session simply invalidating it (and removing it from the session mapping storage).

In my opinion it just make sense to provide out of the box this small cas single sign out integration to complete Spring Security CAS support and make it more coherent.

[spring-projects-issues]

["Matthew Fleming":https://jira.spring.io/secure/ViewProfile.jspa?name=matthewdfleming] said:

I think the confusion is how to add the logout filter to the XML configuration file. I think Martino thinks the current filter/listener combo isn't real because there aren't any examples of how to set it up with Spring Security on the CAS website. The real issue is that you need to have the logout filter come before the CAS filter in the security.xml or before the filter chain invocation in the web.xml. The way I do it is in the security.xml.

Fine grained config:

Default config:

Then you also need to add the listener to your web.xml. The listener maps the service tickets to the HttpSession.

Hope this helps.

-Matt

[spring-projects-issues]

Scott Battaglia said:

Matt,

Thanks for the configuration (somehow I missed that). I'll add that documentation as well as the specific Spring example (though you can also do it completely by putting stuff in the web.xml also IIRC).

Cheers, Scott

[spring-projects-issues]

Luke Taylor said:

I think the original request was to be able to add extra customization to the logout process, which isn't too easy with the SingleSignOutFilter. One possible way would be to decorate the SessionMappingStorage instance to customize the removal process. Alternatively, perhaps the filter could provide an additional hook. What do you think Scott?

As Scott says, I'd prefer to avoid adding extra functionality into Spring Security which is already provided by the CAS client.

[spring-projects-issues]

Rob Winch said:

Documentation and an example of how to support Single Logout with CAS has been implemented. This bug is still open because it still does not integrate with Spring Security's Authentication object.

[spring-projects-issues]

This issue relates to #1954

[rwinch]

The CAS LogoutHandler not integrates with HttpServletRequest.logout() which Spring Security overrides to invoke the configured Spring Security LogoutHandlers which do provide integration with the Authentication.