I'm running into a problem implementing backchannel logout for our new SAML SP. SAML has no way of transmitting client specific session information that I can tell. So, I need some way of associating an auth-server specific session index and the Principal so that I can look up an Http Session and invalidate it based on one of those parameters. We're gonna have the same exact problems when we implement the OIDC equivalent specifics (these are new BTW). I'm thinking of writing a simple Infinispan cache that associates principals/session-indexes to http session ids and have it reusable between SAML and OIDC adapters.

I agree with you 100% Marek, but what you did for the Keycloak adapter Marek was an proprietary extension to OIDC. There is no standard way to do this in SAML that I know of. We will have the same problem in the new Logout OpenID Connection specification too. We need something that will work with non-Keycloak IDPs. On 9/14/2015 3:16 PM, Marek Posolda wrote: > Is it about maintaining infinispan cache on adapter side? I would rather > avoid this if possible. It's another needed step for setup and IMO > possible source of troubles (especially in cluster environments). > > Isn't it better to start HttpSession on adapter even before SAML > authentication and transmit HttpSessionID to auth-server in SAMLRequest > for login? Then auth-server will receive SAMLRequest and save > HttpSessionID to CLIENT_SESSION_STATE note on ClientSession (similarly > like done for OIDC). Then server knows HttpSessionId and backchannel > logout isn't an issue. > > Marek > > On 14/09/15 17:52, Bill Burke wrote: >> I'm running into a problem implementing backchannel logout for our new >> SAML SP. SAML has no way of transmitting client specific session >> information that I can tell. So, I need some way of associating an >> auth-server specific session index and the Principal so that I can look >> up an Http Session and invalidate it based on one of those parameters. >> >> We're gonna have the same exact problems when we implement the OIDC >> equivalent specifics (these are new BTW). >> >> I'm thinking of writing a simple Infinispan cache that associates >> principals/session-indexes to http session ids and have it reusable >> between SAML and OIDC adapters. >> >> >> >> >

The SAML IdP is not required to send back that id. That ID is just the ID of the request.

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.

On 9/14/2015 3:42 PM, Marek Posolda wrote: > Hmm... I don't know much yet about new Logout OIDC specification :/ > > But for SAML, I am not seeing a problem as long as we start HttpSession > before authentication. We can possibly transmit HttpSessionID in ID > attribute of SAMLRequest, which can be compound of random UUID and > HttpSessionID divided by dot. Something like: > > <samlp:AuthnRequest ID="some-random-uuid.HttpSessionId" ...> > > It is bit cumbersome though, but IMO better than additional state on > adapters? > > Marek > > On 14/09/15 21:28, Bill Burke wrote: >> I agree with you 100% Marek, but what you did for the Keycloak adapter >> Marek was an proprietary extension to OIDC. There is no standard way >> to do this in SAML that I know of. We will have the same problem in >> the new Logout OpenID Connection specification too. >> >> We need something that will work with non-Keycloak IDPs. >> >> >> >> On 9/14/2015 3:16 PM, Marek Posolda wrote: >>> Is it about maintaining infinispan cache on adapter side? I would >>> rather >>> avoid this if possible. It's another needed step for setup and IMO >>> possible source of troubles (especially in cluster environments). >>> >>> Isn't it better to start HttpSession on adapter even before SAML >>> authentication and transmit HttpSessionID to auth-server in >>> SAMLRequest >>> for login? Then auth-server will receive SAMLRequest and save >>> HttpSessionID to CLIENT_SESSION_STATE note on ClientSession (similarly >>> like done for OIDC). Then server knows HttpSessionId and backchannel >>> logout isn't an issue. >>> >>> Marek >>> >>> On 14/09/15 17:52, Bill Burke wrote: >>>> I'm running into a problem implementing backchannel logout for our >>>> new >>>> SAML SP. SAML has no way of transmitting client specific session >>>> information that I can tell. So, I need some way of associating an >>>> auth-server specific session index and the Principal so that I can >>>> look >>>> up an Http Session and invalidate it based on one of those >>>> parameters. >>>> >>>> We're gonna have the same exact problems when we implement the OIDC >>>> equivalent specifics (these are new BTW). >>>> >>>> I'm thinking of writing a simple Infinispan cache that associates >>>> principals/session-indexes to http session ids and have it reusable >>>> between SAML and OIDC adapters. >>>> >>>> >>>> >>>> >>> >> >