[jboss-jira] [JBoss JIRA] (WFLY-9170) EJB client from EAP 7.0 is sometimes authenticated as $local even when it is forbidden

[Jan Kalina (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved JBEAP-12525 to WFLY-9170:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-9170  (was: JBEAP-12525)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: EJB
                       Security
                           (was: EJB)
                           (was: Security)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.ER3)
      Affects Testing:   (was: Regression)


> EJB client from EAP 7.0 is sometimes authenticated as $local even when it is forbidden
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-9170
>                 URL: https://issues.jboss.org/browse/WFLY-9170
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> when running EJB client from EAP 7.0 (EJB client 2.1.x) or the 7.1 legacy client (3.0.x), against EAP 7.1.0.ER3 (and newer) server on the same machine (with the same standalone.xml), even when the client has explicitly forbidden LOCAL authentication, he is sometimes (intermittently) authenticated as the user {{$local}}.
> This does not happen when the server is EAP 7.1.0.ER2, or when using EJB client 4.x.
> Impact: the client is intermittently authenticated as a different user than expected, this also makes invocations randomly fail, because the {{$local}} user typically isn't assigned to authorization roles which are typically required for invocations of some methods. Or the other way around, this could actually elevate the user's privileges in some cases.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)