[keycloak-dev] backchannel logout for SAML SP

[Bill Burke]

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 at redhat.com
> <mailto:bburke at 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 at redhat.com
>         <mailto:bburke at redhat.com>
>         <mailto:bburke at redhat.com <mailto:bburke at 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 at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>         <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at 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