[keycloak-dev] backchannel logout for SAML SP
Bill Burke
bburke at redhat.com
Tue Sep 15 09:39:15 EDT 2015
Yeah, of course it would be pluggable. I don't want to force people to
use a distributed cache. :)
Another idea, if we don't want to ship infinispan with our SAML/OIDC SP
is to provide a list of nodes in the adapter config. When a SSO session
is started, store the information in memory. When logout, query other
machines until you find who stores the SSO sesion->local sessionid mapping.
On 9/15/2015 9:23 AM, Stian Thorgersen wrote:
> Oh, I turned things around - I thought it was the SSO session id that
> was missing, not the http session id. Ignore everything I've said up
> until now ;)
>
> Maybe we could make the SSO Session ID --> HTTP Session ID map pluggable
> then? By default it would use the mechanism Marek implemented, but then
> we can support other means as well?
>
> On 15 September 2015 at 15:14, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
> 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>
> <mailto: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>>
> <mailto: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>>
> <mailto: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
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list