Usually, it's preferable to set up access control by declaratively defining method permissions in the enterprise bean's deployment descriptor. Such container-managed security makes an enterprise bean more flexible, since it isn't tied to the security roles defined by a particular application. Security holes due to programming errors is also less likely with container-managed security, since the security mechanism is implemented by the container.
Sometimes, though, procedural access control is necessary, for finer-grained or application-specific conditions. Enterprise beans can manage their own security by using method EJBContext.isCallerInRole(). Bean-managed security is useful in cases where finer, procedural access control is needed. Only enterprise bean methods for which the container has a client security context may use isCallerInRole(). (For more on bean-managed security, see http://java.sun.com/j2ee/j2sdkee/te chdocs/guides/ejb/html/Security5.ht ml.)
A security role is a named grouping of information resource access permissions, defined for an application. Associating a principal with a role confers the defined access permissions to that prinicpal as long as the principal is "in" the role. For example, an application may define a security role called guest, which provides read-only access to a small subset of all of the application's resources. Any principal in the guest role would then have read-only access to only those few resources.
An enterprise bean developer defines all security role names used in the enterprise bean code. Each security role name is defined in a deployment descriptor <security-role-ref> element, and is associated (via <role-link) with a security role defined elsewhere in the descriptor.
Security roles are defined with the application deployment descriptor element <role-name>. For example, the following enterprise bean deployment descriptor fragment defines a role name root, which is a reference (or <role-link>) to role super-user.
....
<enterprise-beans>
...
<entity>
<ejb-name>AnEntityBean</ejb-name>
<ejb-class>AnEntityBean.class</ejb- class>
...
<security-role-ref>
<role-name>root</role-name>
<role-link>super-user</role-link>
</security-role-ref>
...
</entity>
</enterprise-beans>
.....


Class MyEntityBean uses the symbolic name "root" to check permissions.
Elsewhere in the deployment descriptor, the security role super-user is defined as:
....
<assembly-descriptor>
<security-role>
<description>This is the security-role for the security role
"root" referenced in the AnEntityBean class</description>
<role-name>super-user</role-name>
</security-role>
</assembly-descri ptor>
....



The descriptor defines a role name and associates it with a role link because different enterprise beans might differ in the name used to refer to the same application-specific cluster of permissions. For example, maybe some other bean needs to access the security-role super-user, but uses the string racine (instead of root) to identify the role. A <security-role-ref> could associate that bean's racine reference to the security role super-user.
A user or principal may belong to multiple roles simultaneously, and enjoys the union set of permissions those roles confer.

Answered by Nz , an ibibo Master, at 2:40 AM on February 01, 2008