Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-15998

Session context returns wrong caller principal

XMLWordPrintable

    • Hide

      The attached project allows to reproduce this strange behavior.

      Make sure your standalone.xml configuration has the following mapping in the ejb3 subsystem:

      <application-security-domains>
    <application-security-domain name="other" security-domain="ApplicationDomain"/>
</application-security-domains>

      And that the http-remoting-connector in the remoting subsystem uses the application-sasl-authentication factory:

      <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm" sasl-authentication-factory="application-sasl-authentication"/>

      Start WildFly as standalone server:

      $ {jbossHomeName}/bin/standalone.sh

      Add the following two application users with guest role:

      $ {jbossHomeName}/bin/add-user.sh -a -u 'alice' -p 'alicePwd1!' -g 'guest'
$ {jbossHomeName}/bin/add-user.sh -a -u 'bob' -p 'bobPwd1!' -g 'guest'

      Build and deploy the package:

      $ mvn clean package wildfly:deploy

      Start the client with Alice's credentials in one terminal:

      $ mvn exec:java -Dexec.mainClass="ejb_security_wrong_principal.RemoteClient" -Dexec.args="alice alicePwd1!"

      Start the client with Bob's credentials in another terminal:

      $ mvn exec:java -Dexec.mainClass="ejb_security_wrong_principal.RemoteClient" -Dexec.args="bob bobPwd1!"

      Wait until one of the two processes stops by returning the wrong caller principal:

      Successfully called secured bean, caller principal bob
Successfully called secured bean, caller principal bob
Successfully called secured bean, caller principal bob
Successfully called secured bean, caller principal bob
Successfully called secured bean, caller principal alice
Hey, I am bob, not alice!
      Show
      The attached project allows to reproduce this strange behavior. Make sure your standalone.xml configuration has the following mapping in the ejb3 subsystem: <application-security-domains>     <application-security-domain name= "other" security-domain= "ApplicationDomain" /> </application-security-domains> And that the http-remoting-connector in the remoting subsystem uses the application-sasl-authentication factory: <http-connector name= "http-remoting-connector" connector-ref= "default" security-realm= "ApplicationRealm" sasl-authentication-factory= "application-sasl-authentication" /> Start WildFly as standalone server: $ {jbossHomeName}/bin/standalone.sh Add the following two application users with guest role: $ {jbossHomeName}/bin/add-user.sh -a -u 'alice' -p 'alicePwd1!' -g 'guest' $ {jbossHomeName}/bin/add-user.sh -a -u 'bob' -p 'bobPwd1!' -g 'guest' Build and deploy the package: $ mvn clean package wildfly:deploy Start the client with Alice's credentials in one terminal: $ mvn exec:java -Dexec.mainClass= "ejb_security_wrong_principal.RemoteClient" -Dexec.args= "alice alicePwd1!" Start the client with Bob's credentials in another terminal: $ mvn exec:java -Dexec.mainClass= "ejb_security_wrong_principal.RemoteClient" -Dexec.args= "bob bobPwd1!" Wait until one of the two processes stops by returning the wrong caller principal: Successfully called secured bean, caller principal bob Successfully called secured bean, caller principal bob Successfully called secured bean, caller principal bob Successfully called secured bean, caller principal bob Successfully called secured bean, caller principal alice Hey, I am bob, not alice!

      In a highly concurrent system, we noticed that the name of the caller principal retrieved from the session context of a stateless session bean is somewhat random. Sometimes we receive the correct principal of the client, sometimes anonymous and sometimes the principal of a totally independent, concurrent client.

      This strange behavior started when switching from Legacy Security to Elytron Security. With Legacy Security (WildFly 24.0.1.Final or older), the caller principal from the session context always matched the one provided by the client for authentication.

      To reproduce this strange behavior, we put together a simple project consisting of the following two stateless session beans:

      @Stateless
@Remote(SecuredEJBRemote.class)
@RolesAllowed({"guest"})
@RunAs("system")
@SecurityDomain("other")
public class SecuredEJB implements SecuredEJBRemote {
    @Resource
    private SessionContext ctx;
    @EJB
    private AnotherSecuredEJBLocal anotherEjb;
    public String getCallerPrincipal() {
        anotherEjb.ping();
        Principal principal = ctx.getCallerPrincipal();
        return principal.toString();
    }
}

      @Stateless
@RolesAllowed({"system"})
@SecurityDomain("other")
public class AnotherSecuredEJB implements AnotherSecuredEJBLocal {
    public String ping() {
        return "pong";
    }
}

      When a client calls the function getCallerPrincipal() on the SecuredEJB, first the function ping() gets called on AnotherSecuredEJB and then getCallerPrincipal() returns the name of the principal retrieved from the session context. As stated above, the caller principal does not always match the user name provided by the client for authentication.

        1. ejb-security-wrong-principal.zip
          7 kB

              fjuma1@redhat.com Farah Juma
              oliverbieri Oliver Bieri (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: