[undertow-dev] backchannel logout in cluster

[Bill Burke]

On 9/15/2015 8:49 PM, Stuart Douglas wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Tuesday, 15 September, 2015 11:12:59 PM
>> Subject: Re: [undertow-dev] backchannel logout in cluster
>>
>>
>>
>> On 9/14/2015 6:22 PM, Stuart Douglas wrote:
>>> I don't think there is much Undertow can do here, because this is clustered
>>> it is basically out of Undertow's control.
>>>
>>> For a non clustered version you can just maintain your own map using
>>> session listeners, however like you say for the clustered version if you
>>> want to maintain this sort of map you will need to create an Infinispan
>>> cache to handle the mapping.
>>>
>>> When you mentioned an Undertow SPI what exactly did you have in mind? Some
>>> way to query the session manager based on session attributes?
>>>
>>
>> A Hack I thought of was to create an Http Session that is shared by all
>> requests and machines or clone the existing http session and change the
>> session id to an SSO session id provided by the IdP.  Undertow doesn't
>> have a way to provide your own session id though when creating sessions.
>> (Jetty doesn't either, only Tomcat/JBossWeb allow this).
>
> We don't have a documented way, but if you pass in a SessionConfig implementation that returns a constant value for findSessionId
> to the createSession method then this session id will be used for the new session.
>
> This is obviously a hack though, and I will look at adding a new method that supports this directly.
>
>>
>> Better extensions to Undertow session manager would be:
>> * Ability to associate an alias to an http session. i.e. an SSO session ID.
>> * or the ability to replace the http session id, with a new one.  i.e.
>> after authentication, replace the local http session id, with the SSO
>> session id
>
> I can do this one as well.
>
>> * Additionally, the ability to index http sessions (or session ids) by
>> principal or principal name.
>
> Would you still need this indexing if I give you control over the session ID?
>

Sometimes a logout request just has the principal, it doesn't have to 
have an SSO session id.  Would it be hard to add the ability to index 
the session with any arbitrary string key?  Of course, all this indexing 
is only useful and id replacement is only useful if any node in the 
cluster can lookup and invalidate a session.

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