[keycloak-dev] backchannel logout for SAML SP
Stian Thorgersen
sthorger at redhat.com
Tue Sep 15 09:51:25 EDT 2015
If we make it pluggable do we even need to support non-KC IDPs? End of the
day we're focusing on KC right and users can implement their own for other
IDPs.
On 15 September 2015 at 15:39, Bill Burke <bburke at redhat.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150915/d15287c5/attachment-0001.html
More information about the keycloak-dev
mailing list