Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: saml-1.0.0
    • Fix Version/s: saml-1.0.0.RC3
    • Component/s: saml
    • Labels:
      None
    • Environment:
      Package: Spring Security SAML v2 - 1.0.0-RC2-SNAPSHOT
      OS: CentOS release 5.4
      Web server: Tomcat 6

      Description

      I set the Spring Security SAML Extension as a 'SP' integrated with my web app. Single sign on works fine.

      When a user selects global log out from my web app, he is logged out both from SP and IDP and does not allow to access protected web pages again. This is right.

      But then a user selects log out from another web app (in the same trust circle). I checked from log that IDP sends samlp:LogoutRequest to SP, and SP sends back saml2p:LogoutResponse with Success to IDP. This user now is certainly logged out from IDP. But it seems this user session is not killed, this user still be able to access protected web pages!!! This is wrong.

        Activity

        Hide
        Vladimir Schäfer added a comment -

        Hi Patch,

        Can you please tell me which binding is used to send the Logout message from IDP to SP? Is it SOAP?

        Vladi

        Show
        Vladimir Schäfer added a comment - Hi Patch, Can you please tell me which binding is used to send the Logout message from IDP to SP? Is it SOAP? Vladi
        Hide
        patch added a comment -

        Hi Vladi,

        IDP uses HTTP-redirect binding.

        Patch

        Show
        patch added a comment - Hi Vladi, IDP uses HTTP-redirect binding. Patch
        Hide
        Bernhard Thalmayr added a comment -

        Not sure about the side effects, but the following workaround works for me

        define a logout handler which destroys HTTP session

        <bean id="logoutSessionHandler"
        class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler">
        <property name="invalidateHttpSession" value="true"/>
        </bean>

        use this bean in the in the SAML logout filter

        <bean id="samlLogoutProcessingFilter" class="org.springframework.security.saml.SAMLLogoutProcessingFilter">
        <constructor-arg ref="successLogoutHandler"/>
        <constructor-arg ref="logoutSessionHandler"/>
        </bean>

        About the root cause of the issue ... could this be related to ThreadLocalSecurityContextHolderStrategy being used by default?

        Show
        Bernhard Thalmayr added a comment - Not sure about the side effects, but the following workaround works for me define a logout handler which destroys HTTP session <bean id="logoutSessionHandler" class="org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler"> <property name="invalidateHttpSession" value="true"/> </bean> use this bean in the in the SAML logout filter <bean id="samlLogoutProcessingFilter" class="org.springframework.security.saml.SAMLLogoutProcessingFilter"> <constructor-arg ref="successLogoutHandler"/> <constructor-arg ref="logoutSessionHandler"/> </bean> About the root cause of the issue ... could this be related to ThreadLocalSecurityContextHolderStrategy being used by default?
        Hide
        Vladimir Schäfer added a comment -

        Bernhard, thank you for the workaround, it is a correct one.

        The real problem was the fact that Spring Security automatically persists changes to the SecurityContext once request.sendRedirect gets called. And that happens once we send LogoutResponse back to server. The problem is that at this point the logout handlers weren't called yet, so the SecurityContext is persisted with the old values. The logout then correctly proceeds, but the changes are never stored.

        Fixed in RC3.

        Show
        Vladimir Schäfer added a comment - Bernhard, thank you for the workaround, it is a correct one. The real problem was the fact that Spring Security automatically persists changes to the SecurityContext once request.sendRedirect gets called. And that happens once we send LogoutResponse back to server. The problem is that at this point the logout handlers weren't called yet, so the SecurityContext is persisted with the old values. The logout then correctly proceeds, but the changes are never stored. Fixed in RC3.

          People

          • Assignee:
            Vladimir Schäfer
            Reporter:
            patch
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: