[jboss-jira] [JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user

[Paul Ferraro (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146746#comment-13146746 ] 

Paul Ferraro commented on WFLY-5932:
------------------------------------

This seems to be an issue with Undertow's SingleSignOnAuthenticationMechanism, and not to do with clustering.  The SingleSignOnAuthenticationMechanism only registers its SessionListener during calls to authenticate() - however, in the scenario described by the reproducer, it is the CachedAuthenticationMechanism that performs the authentication, not the SingleSignOnAuthenticationMechanism, thus the session listener is never registered (nor is the security notification listener, for that matter), thus session invalidation does not trigger removal of the SSO.  Reassigning to [~swd847]

> Invalidating a session of an SSO on a different node than where the session was created does not logout the user
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-5932
>                 URL: https://issues.jboss.org/browse/WFLY-5932
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR5
>            Reporter: Richard Janík
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
> * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
> Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
> * Access A1, authenticate, invalidate session on A1, access A1
> * Access A1, authenticate, access A2, invalidate session on A1, access A1
> Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)