jQuery in Action, 2nd edition*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes @RunAs Application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "@RunAs Application" Watch "@RunAs Application" New topic
Author

@RunAs Application

Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
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:

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
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
Is this valid?
No, it's an error in EJB 3 in Action.


SCJP 5 (98%) - SCBCD 5 (98%)
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
@RunAs can be used on method. Cancel bid will be invoked as a role of Admin.


SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
Treimin Clark
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
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
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
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:

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
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
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
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
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
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
Oh did you mean bMethod() on "b". Thats correct. I missed it.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
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
Ranch Hand

Joined: Nov 12, 2008
Posts: 757
I think a Principal is a set of roles. Correct me if I'm wrong.
Ralph Jaus
Ranch Hand

Joined: Apr 27, 2008
Posts: 342
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: @RunAs Application