Configuring EJB security on Weblogic

Question

I'm trying to understand how the EJB security works on a WebLogic server.

I have an EJB with following configuration in ejb-jar.xml

<session>
    <ejb-name>BeanA</ejb-name>
         ....
        <security-identity>              
            <run-as>
                <role-name>beanA_users</role-name>
            </run-as>
        </security-identity>
</session>

        <assembly-descriptor>
            <security-role>
                <role-name>beanA_users</role-name>
            </security-role>    
            <container-transaction>    
                <method>
                    <ejb-name>BeanA</ejb-name>
                <method-name>*</method-name>
                </method>
            </container-transaction>
        </assembly-descriptor>

and in weblogic-ejb-jar.xml:

<security-role-assignment>
    <role-name>beanA_users</role-name>
    <principal-name>runas_a</principal-name>
</security-role-assignment>
<run-as-role-assignment>
    <role-name>beanA_users</role-name>
    <run-as-principal-name>runas_a</run-as-principal-name>
</run-as-role-assignment>

I interpret it like this: BeanA runs as beanA_users. "runas_a" is one of beanA_users. Therefore, BeanA runs as runas_a user. Also, all users that are in the beanA_users role are permitted to call all the BeanA methods. In other words, Bean_A is running as runas_a, and only runas_a can call its methods. Is this correct?

However, when I call this EJB from another EJB that has the below configuration I'm able to get through. Shouldn't Bean A configure a permission for the principal assigned to BeanB_users role in the BeanB?

ejb-jar.xml:

<session>    
    <ejb-name>BeanB</ejb-name>
             ... 
        <security-identity>            
            <run-as>
                <role-name>beanB_users</role-name>
            </run-as>
        </security-identity>
</session>

weblogic-ejb-jar.xml:

<run-as-role-assignment>
    <role-name>beanB_users</role-name>
    <run-as-principal-name>runas_b</run-as-principal-name>
</run-as-role-assignment>

Edit:

After reading the ejb-jar.xml schema it looks like the Bean A in this example does not define any permissions in the <assembly-descriptor> element. It only defines the security role. I presume this is why any EJB can call its methods. But why does it define a security role assignment in that case? For instance, if BeanA had the following within the element, would it in that case block BeanB from getting through since the permission does not include the runas_b principal?

<method-permission>
    <role-name>beanA_users</role-name>
        <method>
            <ejb-name>BeanA</ejb-n‌​ame>
                <method-name>*</method-name>
        </method‌​>
</method-permission‌​>

Answer 1

You have the wrong end of the stick here.

When you add:

    <security-identity>              
        <run-as>
            <role-name>beanA_users</role-name>
        </run-as>
    </security-identity>

to a bean definition, this tells WebLogic what role should be applied to any invocations on that bean that it instigates itself, rather than what a user instigates.

i.e. this security identity would be applied to EJB timer methods and the onMessage method of an MDB (and if I recall correctly, some housekeeping operations).

The WebLogic extension with the <run-as-role-assignment>...</run-as-role-assignment> element adds a defined principal to these method calls so that javax.ejb.EJBContext.getCallerPrincipal() returns something other than anonymous during one of these method calls.

In all other cases this security information is normally propagated from the identity of the logged in user of a web application.

Typically a user will be authenticated via their servlet based web application which is wired up to a security domain provided by the application server. The servlet container will then associate incoming HTTP requests with a user principal. That user principal must be associated with one or more "roles" before role based access can be performed (which is done in a vendor dependent way, but often associated with JAAS). If the user has no roles the container will reject any attempt to invoke servlets or downstream EJBs that have been protected by security role declarations in the deployment descriptors or associated @javax.annotation.security.RolesAllowed annotations. The security context established by the servlet container is propagated through the subsequent chain of EJB calls until it either returns successfully or blocked by a security role.

For more information please refer to the "Security" chapters of the Servlet Specification and the EJB Specification.