From: "Bill Burke" <bburke(a)redhat.com&gt; To: undertow-dev(a)lists.jboss.org Sent: Friday, 22 January, 2016 11:44:53 AM Subject: Re: [undertow-dev] sessionId changes between requests? Ok, found it. setChangeSessionIdOnLogin() Can I ask why this is done? Security reasons? To change the cookie? If it is to change the cookie, would be really good in the future to decouple the session cookie value from the session id so that plugins, like Keycloak, that are remotely managing and monitoring sessions can still do so without creating a security hole. On 1/21/2016 6:10 PM, Bill Burke wrote: > Does a HttpSession ID change between requests? We are storing the > current HttpSession ID at our IDP after login, then transmitting back to > the app in a background HTTP request, looking up the session and then > invalidating it. This used to work on Wildfly 8 and 9, in 10, looks like > it is not the same http session. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stuart Douglas" <sdouglas(a)redhat.com&gt; Cc: undertow-dev(a)lists.jboss.org Sent: Friday, 22 January, 2016 3:29:29 PM Subject: Re: [undertow-dev] sessionId changes between requests? Maybe a decoupling of cookie from session ID isn't very feasible...I guess I can just turn off the "changeSessionIdOnLogin" switch and change the ID within the authenticator instead. On 1/21/2016 10:28 PM, Stuart Douglas wrote: > This was done for security reasons (see > https://issues.jboss.org/browse/UNDERTOW-579). > > I don't know how practical it would be to de-couple the cookie value from > the session ID. Could you just use a > javax.servlet.http.HttpSessionIdListener to monitor session ID changes? > > Stuart > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: undertow-dev(a)lists.jboss.org >> Sent: Friday, 22 January, 2016 11:44:53 AM >> Subject: Re: [undertow-dev] sessionId changes between requests? >> >> Ok, found it. setChangeSessionIdOnLogin() >> >> Can I ask why this is done? Security reasons? To change the cookie? >> If it is to change the cookie, would be really good in the future to >> decouple the session cookie value from the session id so that plugins, >> like Keycloak, that are remotely managing and monitoring sessions can >> still do so without creating a security hole. >> >> On 1/21/2016 6:10 PM, Bill Burke wrote: >>> Does a HttpSession ID change between requests? We are storing the >>> current HttpSession ID at our IDP after login, then transmitting back to >>> the app in a background HTTP request, looking up the session and then >>> invalidating it. This used to work on Wildfly 8 and 9, in 10, looks like >>> it is not the same http session. >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stuart Douglas" <sdouglas(a)redhat.com&gt; Cc: undertow-dev(a)lists.jboss.org Sent: Saturday, 23 January, 2016 12:50:30 AM Subject: Re: [undertow-dev] sessionId changes between requests? Is this safe for load balancers and sticky sessions? On 1/22/2016 12:14 AM, Stuart Douglas wrote: > Something to be aware of is that in Servlet 3.1 users can also trigger this > change by calling javax.servlet.http.HttpServletRequest.changeSessionId(). > > Not sure if that will also cause issues for you or not. > > 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: Friday, 22 January, 2016 3:29:29 PM >> Subject: Re: [undertow-dev] sessionId changes between requests? >> >> Maybe a decoupling of cookie from session ID isn't very feasible...I >> guess I can just turn off the "changeSessionIdOnLogin" switch and change >> the ID within the authenticator instead. >> >> On 1/21/2016 10:28 PM, Stuart Douglas wrote: >>> This was done for security reasons (see >>> https://issues.jboss.org/browse/UNDERTOW-579). >>> >>> I don't know how practical it would be to de-couple the cookie value from >>> the session ID. Could you just use a >>> javax.servlet.http.HttpSessionIdListener to monitor session ID changes? >>> >>> Stuart >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>> To: undertow-dev(a)lists.jboss.org >>>> Sent: Friday, 22 January, 2016 11:44:53 AM >>>> Subject: Re: [undertow-dev] sessionId changes between requests? >>>> >>>> Ok, found it. setChangeSessionIdOnLogin() >>>> >>>> Can I ask why this is done? Security reasons? To change the cookie? >>>> If it is to change the cookie, would be really good in the future to >>>> decouple the session cookie value from the session id so that plugins, >>>> like Keycloak, that are remotely managing and monitoring sessions can >>>> still do so without creating a security hole. >>>> >>>> On 1/21/2016 6:10 PM, Bill Burke wrote: >>>>> Does a HttpSession ID change between requests? We are storing the >>>>> current HttpSession ID at our IDP after login, then transmitting back >>>>> to >>>>> the app in a background HTTP request, looking up the session and then >>>>> invalidating it. This used to work on Wildfly 8 and 9, in 10, looks >>>>> like >>>>> it is not the same http session. >>>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com