Announcement Announcement Module
No announcement yet.
SingleSignOut with POST Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • SingleSignOut with POST

    I have troubles getting SLO working

    localy, on the SP calling /saml/logout it works fine, user is logged out, but in the other SP he is not. althought a logoutRequest is sent (per POST) to all of the participant SPs.

    I debugged the Filter to see what happens, and i do not understand how it can work.
    1: I configured the IDP to send logoutRequests to "../saml/SingleLogout"
    2: The Request is received by the SAMLLogoutProcessingFilter where the user credentials are obtained using "SecurityContextHolder.getContext().getAuthent icat ion()" which is allways null. therefore the logoutprofile bean sends an error response to the IDP and the user is not logged out!

    Unfortunatelly the IDP (wso2is) does not support HTTP:Redirect for SLO, so I have to stick with POST.

    Anyone has an idea what i am doing wrong? I do not understand why the SecurityContextHolder is of relevance here, becouse the logoutRequest comes from the Idp and does not include any local-session info. In my uderstanding there has to be a table somewhere linking global-session-ids to local-java-session-ids used to determine which session to kill. i could not find this table, the code i have looked on does not do this.

  • #2
    In case your user has logged in to your SP application prior to the SingleLogout, the call to SecurityContextHolder.getContext().getAuthenticati on() should not be null, but should contain user's Authentication object. Can you elaborate further why could the call be null in your case?

    In SAML Extension, user authenticated at SP can have only one "local-session" and that's why there's no need for a mapping table between global-IDP's-sessionIndex and local-SP-session-ID - the local session is stored inside HttpServletSession and SecurityContextHolder.getContext().getAuthenticati on() is loading the Authentication object from there.

    Such table would be needed in order to support SOAP binding (where calls don't have access to the HttpServletSession), but this binding is not supported by Spring SAML Extension for SingleLogout calls.

    It's also advisable to use the latest Spring SAML trunk, as there are SingleLogout improvements on top of what's in RC2. In case your other SPs are also based on Spring SAML, it could explain why the SP-initialized SingleLogout doesn't propagate correctly (there's known issue), either update to trunk or change your logoutSuccessHandler to the following as a workaround:

    <bean id="logoutSessionHandler" class="">
      <property name="invalidateHttpSession" value="true"/>


    • #3
      I had to read the saml specs more carefully to learn how slo with post should work. from that reading, and your reply, is now clear to me that the problem lies with the IDP. wso2is sends logoutRequest messages direcly to the sp-s via HTTP, with no session-information of course (how could they), that's why the securityContext is null.

      I am still waiting for a reply from wso2 about this, but i think their implementation of the protocol is simply wrong. the saml request thought looks good:

      <saml2p:LogoutRequest ID="fnlacpgnpgdblgkpegokhcioenngioliioegafll" IssueInstant="2014-05-22T15:18:39.314Z" NotOnOrAfter="2014-05-22T15:23:39.314Z" Reason="urn:oasis:names:tc:SAML:2.0:logout:user" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0rotocol">
      <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion ">https:/</saml2:Issuer>
      <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion ">DOMAIN.AT/[email protected]</saml2:NameID>
      anyways, for me it seems to be easier to workaround in spring-saml then on the idp side. have you any hints for me how i could build such a lookup table with the session-indexes linked to pricipals? so in the logoutFilter i could simply look the principal up and hand it over to the logoutProfileImpl!