First of all, thank you for your suggestion.
Second, sorry for my lack of feedback, I've being away from this task in the last
I did as you said, but I've had no success yet.
Setting changeSessionIdOnLogin to false, avoids the first attempt to create a new session,
in CachedAuthenticatedSessionHandler class. But just after that, session will be created,
and of course, with a new session id.
If I also set cacheable to false, when invoking authenticationComplete, so no session will
be created at all. But somehow, the authentication mechanism enters in a loop even with my
AuthenticationMechanism returning AUTHENTICATED.
It seems that I am unable to finish my authentication without an instance of HttpSession
created, is this expected?
What else could I do?
De: Stuart Douglas <sdouglas(a)redhat.com>
Enviado: segunda-feira, 3 de outubro de 2016 18:28:01
Para: Vinicius F. Kopcheski
Assunto: Re: [undertow-dev] Legacy SSO system integration
Can you try setting
false? By default Undertow will generate a new session ID when you
authenticate as a precaution.
On Tue, Oct 4, 2016 at 8:19 AM, Vinicius F. Kopcheski
I'm working to integrate a legacy SSO system with undertow (Wildfly 10), and
this SSO is also used with JBoss 4 and 6.
Its strategy is to share the same JSESSIONID between all the applications
running inside all those servers.
In my custom Authentication Mechanism, I retrieve the session id that will
be used for this session, but just after invoking
SecurityContext#authenticationComplete, a new session is created, which
takes me to have two session cookies. I mean, they both are named
I could find a way to remove this one created by undertow, but I'm not sure
this is the best approach.
What do you suggest me to do is this scenario?
undertow-dev mailing list