[keycloak-dev] backchannel logout for SAML SP
Stian Thorgersen
sthorger at redhat.com
Tue Sep 15 09:04:25 EDT 2015
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
More information about the keycloak-dev
mailing list