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@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@redhat.com
 <mailto:bburke@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@redhat.com
        <mailto:bburke@redhat.com>
        <mailto:bburke@redhat.com <mailto:bburke@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@redhat.com <mailto:bburke@redhat.com>
                 <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>
                 <mailto:bburke@redhat.com <mailto:bburke@redhat.com>
        <mailto:bburke@redhat.com <mailto:bburke@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@lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
                 <mailto:keycloak-dev@lists.jboss.org
        <mailto:keycloak-dev@lists.jboss.org>>
                 <mailto:keycloak-dev@lists.jboss.org
        <mailto:keycloak-dev@lists.jboss.org>
                 <mailto:keycloak-dev@lists.jboss.org
        <mailto:keycloak-dev@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