[keycloak-dev] backchannel logout for SAML SP

[Marek Posolda]

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.

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

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.

Marek


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