[keycloak-dev] backchannel logout for SAML SP

[Stian Thorgersen]

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