• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

run-as related question

 
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the implication of specifying the run-as identity for a bean?

My understanding is as follows :
1. The run-as identity gets passed in the call chain, unless another run-as specified for another bean in the call chain.
2. If the security infrastructure performs principal mapping, the getCallerPrincipal() method returns the principal that is the result of the mapping, not the original caller principal. Is there a 'logical' principal in picture, so that a mapping needs to be performed? I did not read anyone else deal with Principals except the Deployer.

3. Specifying run-as does not change the result of getCallerPrincipal() or isCallerInRole() methods for both the beans involved. Please confirm this for me. If this is true, in what way we can 'check' the presence of the <run-as> identity in the other bean?

Regards,
Leena
 
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me try to clear your doubts with theory first, and then give an example:

1.


The run-as identity gets passed in the call chain, unless another run-as specified for another bean in the call chain.


Correct. If Bean A has specified as a <run-as> as "SuperBean", its original principal belonged to the role "VIPCustomer", and if it calls Beans B and C, then Beans B and C will see the principal as "SuperBean" role. Unless Bean B declares a <run-as> of its own of course.

2.


If the security infrastructure performs principal mapping, the getCallerPrincipal() method returns the principal that is the result of the mapping, not the original caller principal. Is there a 'logical' principal in picture, so that a mapping needs to be performed? I did not read anyone else deal with Principals except the Deployer.


Yes, a logical principal is in the picture, when Bean A specifies its own <run-as>. And yes, the Deployer usually changes the duplicate name provided by the Application-Assembler with the correct role in the operational environment. But this rule need not be strictly adhered to. Bean A can always use another dummy logical role, just because Bean B needs a specific kind of role to operate.

3.


Specifying run-as does not change the result of getCallerPrincipal() or isCallerInRole() methods for both the beans involved. Please confirm this for me. If this is true, in what way we can 'check' the presence of the <run-as> identity in the other bean?


Specifying <run-as> does change the result of getCallerPrincipal() or isCallerInRole() methods for Bean B. Bean B will see the role specified by the run-as of Bean A as its principal. Remember, "Establishing a run-as identity for an enterprise bean does not affect the identities of its callers, which are the identities tested for permission to access the methods of the enterprise bean. The run-as identity establishes the identity the enterprise bean will use when it makes calls".

Hope an example will clear your doubts.

Beans Involved: Bean A, Bean B and Bean C.

Roles in Beans:
Bean A (Request for Leave) :
Chairman
Manager
HR
Bean B (Request for Leave) :
Employee
Bean C (Grant the Actual leave) :
I only base my decisions whether the person who is calling me is NeedApproval or DontNeedApproval.

Lets assume a scenario where a Hard-working employee is trying to request for leave.

Bean A :
Caller Principal : Real employee of the organization (Chairman, Manager or HR)
Logic : Upper rung of the ladder; do not need any approval.
Run-as : DontNeedApproval
Calling Bean : Bean C
Bean B :
Caller Principal : Real employee of the organization (Employees)
Logic : Lower rung of the ladder; do not need any approval.
Run-as : NeedApproval
Calling Bean : Bean C
Bean C :
Caller Principal : NeedApproval or DontNeedApproval
Logic : If the caller is NeedApproval, log the entry to his respective Manager's desk and stop there. Else if the caller is DontNeedApproval, directly approve the leave immediately.
Run-as : NA
Calling Bean : NA
[ March 06, 2005: Message edited by: Agni Vartula ]
 
Leena Diwan
Ranch Hand
Posts: 351
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Agni for taking time to write an example also. It is clear now.

Regards,
Leena
 
reply
    Bookmark Topic Watch Topic
  • New Topic