[keycloak-dev] backchannel logout for SAML SP

[Bill Burke]

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.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com