[keycloak-dev] backchannel logout for SAML SP

[Bill Burke]

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>> 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>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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