Hi everybody,
I was asked by one of our customers to investigate if https://osgeo-org.atlassian.net/browse/GEOS-6189 is still current and if we can apply the patch that’s attached to the JIRA ticket.
Basically, they are experiencing some issues with single sign out.
I will try to explain what I have understood so far about the proposed patches.
First patch:
In GeoServerCasAuthenticationFilter there is some code to handle single sign out:
if (isLogoutRequest(httpReq)) {
if (singleSignOut) { // do we participate
LOGGER.info(“Single Sign Out received from CAS server → starting log out”);
handler.process(httpReq, httpRes);
LogoutFilterChain logOutChain = (LogoutFilterChain)
getSecurityManager().getSecurityConfig().getFilterChain().getRequestChainByName(“webLogout”);
logOutChain.doLogout(getSecurityManager(), httpReq, httpRes,getName());
} else
LOGGER.info(“Single Sign Out received from CAS server → ignoring”);
return;
}
The handler.process(…) call is handling the CAS related logout, but it seems that doing that before calling the GeoServer logout chaing is the cause of issues, so we suggest to move the code this way:
if (isLogoutRequest(httpReq)) {
if (singleSignOut) { // do we participate
LOGGER.info(“Single Sign Out received from CAS server → starting log out”);
LogoutFilterChain logOutChain = (LogoutFilterChain)
getSecurityManager().getSecurityConfig().getFilterChain().getRequestChainByName(“webLogout”);
logOutChain.doLogout(getSecurityManager(), httpReq, httpRes,getName());
handler.process(httpReq, httpRes);
} else
LOGGER.info(“Single Sign Out received from CAS server → ignoring”);
return;
}
This makes sense to me and I did some tests to see if it breaks the logout scenario, with no issues.
Second patch:
Another piece of code is registering the CAS token when available so that it can be used during the single logut procedure.
if (SecurityContextHolder.getContext().getAuthentication()!=null) {
HttpSession session = httpReq.getSession(false);
if (session !=null &&
session.getAttribute(GeoServerCasConstants.CAS_ASSERTION_KEY)!=null && singleSignOut) {
handler.process(httpReq, httpRes);
if (LOGGER.isLoggable(Level.INFO))
LOGGER.info("Record HTTP Session “+session.getId()+ " for CAS single sign out”);
}
}
The patch proposes to remove this piece of code, but in my opinion this is not correct, since then the single sign out procedure would not be able to find the token when needed.
My idea would be to apply only the first patch, and I will prepare a pull request for that. Is there any CAS expert out there that can give me advices on this?
Thanks
Mauro
···
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
