[keycloak-dev] backchannel logout for SAML SP

[Stian Thorgersen]

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> 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>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150915/0ce4635d/attachment.html