Re: [keycloak-dev] backchannel logout for SAML SP

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(a)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(a)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