• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question about Security + Transaction

 
Amin Rais
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
There is a sample DD :
<assembly-descriptor>
...
<container-transaction>
<method>
<ejb-name>EmployeeRecord</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
Sure we know that all methods belong to EmployeeRecord Bean has Required as trans-attribute.
But lets declare something like this.
<container-transaction>
<method>
<ejb-name>EmployeeRecord</ejb-name>
<method-name>xxx</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
So only method xxx of EmployeeRecord has trans-attribute Required. Then how about other methods ? which trans-attribute that they have ?
The same question for the Security DD Issue, if I don't have security-role-ref for the other methods, then what role do those methods can be accessed ? (or can be accessed by any role ?)
Thanks for any help.
 
Kathy Sierra
Cowgirl and Author
Rancher
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy -- if you declare a <container-transaction> and you don't use the wildcard (*), then you have specified the transaction attribute for only a single method in the interface. If there are *more* methods that MUST have a transaction attribute, then you MUST explicitly declare them in the DD. So, there is NO 'default' transaction attribute for CMT methods. So, a legal DD would list each method (for which a tx attribute must be specified, which depends on whether it is a session or entity bean) and specify the attribute for each method, unless the wildcard (*) is used.
But for security, things can be different. Here, you list a particular security ROLE 9not role-ref) using a <method-permission> tag:
<method-permission>
<role-name>Employee</role-name>
<method>
<ejb-name>CustomerBean</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getCustomerAddress</method-name>
<method-params />
</method>
<method>
<ejb-name>CustomerBean</ejb-name>
<method-intf>Remote</method-intf>
<method-name>isIdentical</method-name>
<method-params>
<method-param>javax.ejb.EJBObject</method-param>
</method-params>
</method>
</method-permission>
And now ONLY these two methods can be accessed by the role specified.
If you want a method to be accessed without any security checking, you can use the <unchecked /> tag instead of specifiying a security role:
<method-permission>
<unchecked />
<method>
<ejb-name>CustomerBean</ejb-name>
<method-intf>Home</method-intf>
<method-name>getEJBMetaData</method-name>
<method-params />
</method>
<method>
<ejb-name>CustomerBean</ejb-name>
<method-intf>Home</method-intf>
<method-name>remove</method-name>
<method-params>
<method-param>java.lang.Object</method-param>
</method-params>
</method>
</method-permission>
But this is not the same as a security role reference. A security role REFERENCE (as opposed to a security ROLE) is used only when you have explicitly used "isCallerInRole()" somewhere in your bean code.
If you DID use that method, then you have to specify exactly what you used as the argument to isCallerInRole(), so that the app assembler can map between your "made-up" role name (the security role reference) and the REAL security role the application uses (in other words, the security role used in the <method-permission> element.).
So, security role *references* are FAKE, made-up names used by the programmer in bean code, whereas the security *roles* are the real roles listed by the app assembler in the <method-permission> area to define which methods can be called by users who have been assigned to that particular role.
Remember, for transaction attributes, EACH method must be listed (unless the wildcard is used) and given one of the six attributes. For security, a ROLE is specified, and all of the methods that can be accessed by that role are listed within the same <method-permission> element for that role. If a method is not included in one of the method permissions, then it cannot be called by anyone!
Cheers,
Kathy
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic