Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

about ommitting <role-link>

 
Himai Minh
Ranch Hand
Posts: 1361
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On p. 80 of Frit's notes,

The <role-link> need not be specified when the <role-name> used in the code is the same as the name of the <security-role> to be linked.


I think <role-link> need not be specified when the <role-name> of <security-role-ref> of a bean is the same as the <role-name> of <security-role> in the <assembly-descriptor>.
I used Ivan's example:


It allows "ivan" who is a superusers in sun-ejb-jar.xml to access the method in the bean.
It does not allow "Doe" who is a plain user to access any method in the bean.

However, one more note:

This method always return false for ivan when <role-link> is omitted in the ejb-jar.xml
This method always return true for ivan when <role-link> is not omitted.

I think it must be GlassFish that cannot check what role "ivan" has from isCallerInRole.

 
Himai Minh
Ranch Hand
Posts: 1361
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me answer my own question.
There is a related post here in Enthuware's forum:
http://www.enthuware.com/forum/viewtopic.php?f=4&t=491&start=10


question: a <role-link> in <security-role-ref> is useful only for a programmatic security check (EJBContext.isCallerInRole() method)?
answer: yes, it is correct.


If <role-link> is missing in ejb-jar.xml, the user "ivan" can still access to the method that allows superusers.
But isCallerInRole("superuser") returns false as the role defined for the bean is not linked by the assembler to the operation environment.

One more note about the parameter for isCallInRole(String rolename). This rolename has to be the role defined by the bean provider, but not the role linked by the assembler or provided by the deployer.
For Ivan's example, the deployer create a role called "super-user". The bean provider created a role called "superuser". The assembler links the roles by using "superuser2".
isCallerInRole("superuser") should be used for security check.
 
Himai Minh
Ranch Hand
Posts: 1361
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me answer my own question again, in a better way after reading some explanations in Enthuware.
1. The <role-link> is missing in the <session> element. The application assembler defines a role "superUser" in <security-role> in <assembly-descriptor>. The bean provider defines another role "superUser". But these two roles are not linked, so they are not related.

2. The <security-role> in <assembly-descriptor> defined "superUser" can access the method.
The security role and method permission in the dd overrides the annotations in the bean code.
The "superUser" is mapped to a principal, "ivan" by the deployer.

3. Th target environment, which is GlassFish 3.1.2 , allows "ivan" to access that method as specified by the application assembler and the deployer in their deployment descriptors, but not the bean provider in this case as the bean provider's role is not linked by the application assembler.

4. However, the session bean does not link any role to "superUser" defined by the application assembler. The bean does not know which role "ivan" is in.

5. Therefore, isCallerInRole("superUser") return false as the bean does not link the bean provider's "superUser" to application assembler's "superUser".
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic