8 Replies Latest reply on Dec 2, 2010 4:41 PM by jeanluc

    PicketLink responds with 400 Bad Request to a samlp:LogoutRequest

    jeanluc

      Any idea about the possible causes? The scenario is an IDP-initiated logout request (send to the SOAP binding url). The IDP is OpenAM.

       

      Does PicketLink require a differently-formatted request?

       

      Thanks again,

      JL

       

       

      POST /myapp/SingleLogoutService.seam HTTP/1.1
      Content-Type: text/xml; charset=utf-8
      SOAPAction: ""
      Content-Length: 890
      Cache-Control: no-cache
      Pragma: no-cache
      User-Agent: Java/1.6.0_20
      Host: my.app.server:8280
      Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
      Connection: keep-alive

       

      <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
          <soap-env:Body>
              <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                                   ID="s26af984e253bf5a65a66643246dd61877d8afeeef"
                                   Version="2.0"
                                   IssueInstant="2010-12-01T21:35:07Z"
                                   Destination="http://my.app.server:8280/myapp/SingleLogoutService.seam"
                                   NotOnOrAfter="2010-12-01T21:45:07Z">
                  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
                      http://my.sso.server:8080/openam
                  </saml:Issuer>
                  <saml:NameID
                          xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                          NameQualifier="http://my.sso.server:8080/openam"
                          Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
                      mbmo
                  </saml:NameID>
                  <samlp:SessionIndex xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
                      s25f360fbe4fba2820db784ab99397044879827701
                  </samlp:SessionIndex>
              </samlp:LogoutRequest>
          </soap-env:Body>
      </soap-env:Envelope>

       

       

       


      HTTP/1.1 400 Bad Request
      Server: Apache-Coyote/1.1
      X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
      Set-Cookie: JSESSIONID=62A6CD4A134994B0C7744927018738FE; Path=/myapp
      Content-Type: text/html;charset=utf-8
      Content-Length: 967
      Date: Wed, 01 Dec 2010 21:35:32 GMT
      Connection: close

       

      The request sent by the client was syntactically incorrect ()         

       

      (For brevity, I removed the HTML decoration from the response body)

        • 1. Re: PicketLink responds with 400 Bad Request to a samlp:LogoutRequest
          jeanluc

          An update. According to http://community.jboss.org/thread/157170?decorator=print&displayFullThread=true, PicketLink doesn't support SOAP for logouts (for the reasons Marcel gave in that posting).

           

          Alas, OpenAM has SOAP hardcoded as the binding to use for IDP-initiated

          com.sun.identity.saml2.profile.IDPSessionListener.initiateIDPSingleLogout()

           

          initiateIDPSingleLogout(sessionIndex, metaAlias, realm, SAML2Constants.SOAP, nameID, idpEntityID,spEntityID,paramsMap);

           

          I don't see any other option than modifying OpenAM...

          • 2. Re: PicketLink responds with 400 Bad Request to a samlp:LogoutRequest
            marcelkolsteren

            Strange! If you look over here External authentication example using OpenSSO you will see, at the end of the article, that OpenSSO can do an IDP-initiated logout that is handled by a PicketLink powered service provider. And OpenAM is the successor of OpenSSO, right? Difficult to imagine that they dropped support for non-SOAP bound IDP-initiated single logout.

            1 of 1 people found this helpful
            • 3. Re: PicketLink responds with 400 Bad Request to a samlp:LogoutRequest
              jeanluc

              Strange, indeed, if OpenSSO had support for the other bindings.  I don't know why they did it, but that's what the source shows.

              • 4. Re: PicketLink responds with 400 Bad Request to a samlp:LogoutRequest
                marcelkolsteren

                They even dropped the idpSingleLogoutInit.jsp?

                • 5. Re: PicketLink responds with 400 Bad Request to a samlp:LogoutRequest
                  jeanluc

                  I'm no longer at work so I can only answer tomorrow.

                   

                  Not sure how idpSingleLogoutInit.jsp would help for what I need. IIRC, that's the IDP-hosted page where the user can logout from all sessions. I'm interested in an automatic IDP-initiated logout. You see, there's a different problem with OpenAM which underlies this.

                   

                  The problem is as follows: consider a web app which uses OpenAM for SSO. A common scenario is for the session to expire due to inactivity. In particular, consider the case when the user does nothing with the app for a while, but leaves it open in the browser. Later he clicks on the app's Logout button. Here's the problem with OpenAM: when it receives a request, it first validates the session id. Well, in this case, because the session expired in OpenAM, the sessionId is not known. OpenAM's apparently illogical behaviour is that, instead of silently accepting this request, it replies with an "invalid sessionid" error to the app. This triggers a runtime exception inside PicketLink which bubbles up through the layers.

                   

                  This is why I'm interested in IDP-initiated logouts. Not because the user would log himself out by going to that page, but because OpenAM would itself initiate the logout of the user when the OpenAM session expires. This will redirect the user to a login page so the window to click on Logout is much reduced.

                   

                  Well, as I found out today, unfortunately OpenAM hardcodes SOAP as the binding to use for IDP-initiated logouts so this makes it more difficult.

                  • 6. Re: PicketLink responds with 400 Bad Request to a samlp:LogoutRequest
                    jeanluc

                    An update: I compared com.sun.identity.saml2.profile.IDPSessionListener.java between OpenSSO and OpenAM and found that only the latter has session synchronization, so the code with the hardcoded SOAP binding is new.

                    • 7. Re: PicketLink responds with 400 Bad Request to a samlp:LogoutRequest
                      marcelkolsteren

                      Now I have a better understanding of what you want to solve with this session synchronization, some things pop up:

                       

                      1. If I understand you correctly, the session synchronization will work like this. The user opens the SP app and logs in through the IDP. After having played around with the SP app for some time, she leaves it in the idle state. Then a timeout occurs in OpenAM. A background process in OpenAM detects the timeout, invalidates the session, and sends a SAML LogoutRequest directly to the SP(s), through a "back channel" (i.e. not involving the browser). The SP logs out the user in the background. So when the user comes back to the application, and presses a key, the application will ask the user to login again. Right?
                      2. It's clear to me now why OpenAM uses the SOAP binding for this. The other bindings (Redirect and POST) are "front channel" bindings, which require controlling the browser of the user. In this case, the IDP initiated timeout should occur when the IDP is not interacting with the user through the browser, so using a front channel is not possible.
                      3. Another way of solving your problem could be to ensure that the session timeout of your SP application is smaller than the timeout of the IDP.
                      • 8. Re: PicketLink responds with 400 Bad Request to a samlp:LogoutRequest
                        jeanluc

                        #1: correct

                        #2: Ah, this explains it. Thank you.

                        #3: I'm working on that. Found out today there's a remote method in OpenAM, isTokenValid, which both checks if a token is valid (which was my question http://community.jboss.org/thread/159449 yesterday) and, as a side effect, extends the session (which was my other question yesterday,

                        http://community.jboss.org/thread/159511).