@RunAs Application

[Treimin Clark]

According to the specs, @RunAs annotation should be used to annotate the bean class. But, I found the example below on EJB 3 In Action:

EJB 3 In Action wrote:

@RunAS("ADMIN")
@RolesAllowed("CSR")
public void cancelBid(Bid bid, Item item) {...}

According to the above example, it uses the @RunAS (oh! S capital ) annotation to annotate a method, not the class. Is this valid?

[Ralph Jaus]

Is this valid?

No, it's an error in EJB 3 in Action.

[Amandeep Singh]

@RunAs can be used on method. Cancel bid will be invoked as a role of Admin.

[Treimin Clark]

Amandeep Singh wrote:@RunAs can be used on method. Cancel bid will be invoked as a role of Admin.

Are you really sure on this? I didn't see this elsewhere than EJB 3 In Action. And the specification says it can be used for the bean class only.

[Ralph Jaus]

Hi Amandeep,

it may be possible that some app servers don't complain when @RunAs is used on method level. But the specification itself is unambiguous here.

@RunAs can be used on method. Cancel bid will be invoked as a role of Admin.

I think there is some missunderstanding on how @RunAs works:

@Stateless 
@RunAs("Admin")
public class ABean implements A{

  @EJB private B b; 

  @RolesAllowed("Guest")
  public void aMethod(){
    b.bMethod(); 
  }
}

@Stateless 
public class BBean implements B{

  @RolesAllowed("Admin")
  public void bMethod(){}

}    

If no @RunAs would have been specified, bMethod would be called by a principal with role "Guest". Due to @RunAs it is called by a principal with role "Admin" and everything works fine.

@RunAs has no effect on the roles used to perform aMethod.

[Treimin Clark]

Ralph Jaus wrote:If no @RunAs would have been specified, bMethod would be called by a principal with role "Guest".

Are you sure that it is "Guest" role?

[Ralph Jaus]

Without @RunAs (or the deployment descriptor equivalent) the underlying principal / role is propagated on calls to other beans (see core spec 17.4.3).

In the scenario above only "Guest" can perform aMethod. So, without @RunAs this role would be propagated to the call of bMetod() on bean b.

[Treimin Clark]

Oh did you mean bMethod() on "b". Thats correct. I missed it.

[Amandeep Singh]

there have been always a confusion between a principal and roles. But i understood from here is,

if you have specified a role of 'Guest', and we are using the annotation @RunAs("Admin"), this means Guest role will be replaced by Admin role for this class, to execute it. for other executions, default Guest role will apply.

Principal is more broader term then roles. If role is not specified, then principal is propagated to role. if principal is not specified, then role is propagated to principal. Otherwise, there will be a mapping from principal to role.

Correct me if i am wrong.

[Treimin Clark]

I think a Principal is a set of roles. Correct me if I'm wrong.

[Ralph Jaus]

I think a Principal is a set of roles.

You can think of a principal simply as a user of the system. The system's principals are independent from ejb's and therefore it's the system administrator's responsibility to define principals (in practise: users and user groups).

In "declarative security" ejb's are secured by roles (using @RolesAllowed).

The link between principals and roles is provided by the deployer: He assigns each principal that uses the bean a corresponding role. This is done in the runtime deployment descriptor (at least for glassfish) and is specific to the app server.

If role is not specified, then principal is propagated to role. if principal is not specified, then role is propagated to principal

Consider the following scenario:

- Client C calls methodA() on bean A, which calls methodB() on bean B (code as above).

- The user logs in on the client as "Amandeep" and there is defined a corresponding principal Amandeep_Principal on app server 1 where A resides. The deployer has assigned Amandeep_Principal the role "Guest".

- Normally, when methodB() is called, Amandeep_Principal would be propagated to app server 2 where B resides. But you can circumvent this propagation using, say, @RunAs("Admin").

For this to work there must be a principal with role "Admin" on app server 1, say Admin_Principal (if there are several principals with role "Admin" glassfish chooses one coincidentally). From the perspective of app server 2, now methodB() is called by principal Admin_Principal.

Of course, Admin_Principal must be defined on app server 2, too, and the assigned role of Admin_Principal on bean B has to be "Admin". Otherwise the call of methodB() will result in an EJBAccessException.