I'm running into a problem implementing SAML backchannel logout. Web server could receive an on-of-band, non-browser HTTP request to logout out a specific user and/or session. I would need a way to lookup a session by Principal and a way to associate and lookup an external key. SAML doesn't really have any way to push client specific session information.

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?

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stuart Douglas" <sdouglas(a)redhat.com&gt; > Cc: undertow-dev(a)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?

Adding Paul. For our in memory session manager it is relatively simple. From a clustering POV though I think that this will end up being a case of Wildfly doing the same book keeping that you would do otherwise, although Paul is the expert. Either way this will be an API change that needs to go into the next version of Undertow (so it will miss WF10, but may make EAP7). Stuart ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stuart Douglas" <sdouglas(a)redhat.com&gt; > Cc: undertow-dev(a)lists.jboss.org > Sent: Wednesday, 16 September, 2015 10:41:41 PM > Subject: Re: [undertow-dev] backchannel logout in cluster > > > > On 9/15/2015 8:49 PM, Stuart Douglas wrote: >> >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: "Stuart Douglas" <sdouglas(a)redhat.com&gt; >>> Cc: undertow-dev(a)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 >