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
