Uploaded image for project: 'Application Server 3 4 5 and 6'
  1. Application Server 3 4 5 and 6
  2. JBAS-8600

An EJB invocation with runas-identity causes that runas-identity to be used for all invocations of that EJB

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 6.0.0.Final
    • JBossAS-5.1.0.GA
    • EJB2
    • None
    • Hide

      Deploy a stateless session EJB E0 with a non run-as descriptor that specifies a <security-identity> element containing <use-caller-identity/>
      This EJB has a method M0 that invoke the getCallerPrincipal method on the SessionContext object and returns it.
      Deploy a stateless session EJB E1 with a non run-as descriptor that specifies a <security-identity> element containing <use-caller-identity/>
      This EJB has a method M1 that invokes M0 on EJB E0.
      Deploy a Servlet S with a run-as descriptor that specifies a <run-as-principal> element containing the principal "U1"
      This Servlet will when invoked, in turn invoke method on M1 on EJB E1.
      There's also a java-client J that is logged in as user U2.

      Step1: J calls M1 on EJB E1, M0 returns U2. This is ok.
      Step2: S is invoked and in turn invokes M1 on EJB E1. M0 returns U1. This is ok too.
      Step3: J calls M1 on EJB E1, M0 returns U1. This is wrong.

      Show
      Deploy a stateless session EJB E0 with a non run-as descriptor that specifies a <security-identity> element containing <use-caller-identity/> This EJB has a method M0 that invoke the getCallerPrincipal method on the SessionContext object and returns it. Deploy a stateless session EJB E1 with a non run-as descriptor that specifies a <security-identity> element containing <use-caller-identity/> This EJB has a method M1 that invokes M0 on EJB E0. Deploy a Servlet S with a run-as descriptor that specifies a <run-as-principal> element containing the principal "U1" This Servlet will when invoked, in turn invoke method on M1 on EJB E1. There's also a java-client J that is logged in as user U2. Step1: J calls M1 on EJB E1, M0 returns U2. This is ok. Step2: S is invoked and in turn invokes M1 on EJB E1. M0 returns U1. This is ok too. Step3: J calls M1 on EJB E1, M0 returns U1. This is wrong.

      If a context associated with a runas-identity invokes a method on a (non-runas deployed) stateless session EJB then subsequent invocations from any authenticated context will be performed as if the EJB was runas-deployed using that identity.

      Only a restart of the application server will help.

      A runas-identity context is usually established within invocations of Servlets or EJBs with runas-deployment. All non-runas deployed EJBs invoked from such a servlet, EJB (or MDB) will be affected.

      This behavior is probably caused by a bug in org.jboss.ejb.plugins.SecurityInterceptor. The following patch solves the problem for us:

      Index: org/jboss/ejb/plugins/SecurityInterceptor.java
      ===================================================================
      — org/jboss/ejb/plugins/SecurityInterceptor.java (revision 109035)
      +++ org/jboss/ejb/plugins/SecurityInterceptor.java (arbetskopia)
      @@ -248,18 +248,19 @@
      throw e;
      }

      + RunAs runAsIdentityToPush = runAsIdentity;
      /**

      • Special case: if <use-caller-identity> configured and
      • the caller is arriving with a run-as, we need to push that run-as
        */
        if (callerRunAsIdentity != null && this.isUseCallerIdentity)
      • this.runAsIdentity = callerRunAsIdentity;
        + runAsIdentityToPush = callerRunAsIdentity;

      /* If a run-as role was specified, push it so that any calls made
      by this bean will have the runAsRole available for declarative
      security checks.
      */

      • SecurityActions.pushRunAsIdentity(runAsIdentity);
        + SecurityActions.pushRunAsIdentity(runAsIdentityToPush);

      try
      {

              mmoyses Marcus Moyses (Inactive)
              magnus.lind Magnus Lind (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: