no.  The session id sent with the logout request is the SSO session id.  The client does not transmit its session id to the IdP.

On 9/15/2015 9:04 AM, Stian Thorgersen wrote:

Isn't the http session id part of the standard backchannel log out?

On 15 September 2015 at 14:58, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com>> wrote:

    We can do anything we want on the server side, the problem is that
    our client adapters, SAML and OIDC, should be able to work with
    non-Keycloak IdPs.

    On 9/15/2015 7:25 AM, Stian Thorgersen wrote:

        Could we store the mapping on the Keycloak side? client-id + http
        session id --> KC session id?

        On 14 September 2015 at 22:41, Bill Burke <bburke@redhat.com
        <mailto:bburke@redhat.com>

        <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:



             On 9/14/2015 4:20 PM, Marek Posolda wrote:
             > On 14/09/15 21:46, Bill Burke wrote:
             >> The SAML IdP is not required to send back that id.  That
        ID is just
             >> the ID of the request.
             > The SAML IdP doesn't need to send anything back. I meant that
             > HttpSessionID will be send in the ID of SAMLRequest from
        SAML SP to
             > auth-server . I don't know if there is any better
        attribute/element of
             > AuthnRequest, which can be used to transmit such "custom"
        data.
             >

             SAML logout requests to the SP client contain the principal
        name and/or
             possibly one *or more* SSO IDs (session indexes).  New OIDC
        spec will
             work similarly.

             >>
             >> A hack I'm thinking of is to create an HttpSession that
        is shared by
             >> everybody and store this SSO id/username -> to ->
        HttpSession id map
             >> there.
             > That's good, we can avoid dependency on infinispan.

             Ugh, unfortunately, you can't provide our own session id
        with Undertow's
             or Jetty's sessionmanager interface. :(  So no way to hack
        this except
             for Tomcat and JbossWeb.

             > But still, we will
             > need the stuff like periodic cleaner thread, which will
        remove expired
             > items from this HttpSession map. And this solution
        requires HttpSession
             > replication if I understand correctly?
             >

             Replication would be required, but all these servlet
        containers contain
             session lifecycle listener SPIs, so there is no need for
        reaper threads.
                But, can't do it anyways...

             > As of now, we don't require HttpSession replication for
        OIDC. Qe support
             > the deployments when the application is deployed on more
        "cluster" nodes
             > behind loadbalancer, but application cluster nodes don't
        communicate
             > with each other. In other words, there is no
        "distributable" in web.xml
             > . For this case, we have CLIENT_SESSION_HOST note, so the
        OIDC
             > backchannel request is sent to same cluster node from
        which was
             > code-to-token request sent earlier.
             >

             Again, not something we can implement in a
        standard/portable way.

             --
             Bill Burke
             JBoss, a division of Red Hat
        http://bill.burkecentral.com
             _______________________________________________
             keycloak-dev mailing list
        keycloak-dev@lists.jboss.org
        <mailto:keycloak-dev@lists.jboss.org>

        <mailto:keycloak-dev@lists.jboss.org
        <mailto:keycloak-dev@lists.jboss.org>>
        https://lists.jboss.org/mailman/listinfo/keycloak-dev



    --
    Bill Burke
    JBoss, a division of Red Hat
    http://bill.burkecentral.com

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com