Rhino 3.1 :: Rhino Administration and Deployment Guide :: Adding Security Permissions to SLEE Components

SBB, profile specification, resource adaptor and library components can be granted additional security permissions over and above the default set of security permissions granted by the SLEE — by using the security-permissions element in their respective deployment descriptor.

Each security-permissions element contains the following sub-elements:

description — an optional informational element
security-permission-spec — an element that identifies the security permission policies used by component jar file classes. (For the security-permission-spec element syntax definition, please see the J2SE security documentation).

If the codeBase argument:

is not specified for a grant entry — the SLEE assumes the codebase to be the component jar file, and grants security permissions to all classes loaded from the component jar file (that is, to all SLEE components defined in the component jar file). The SLEE does not, however, grant the security permissions to classes loaded from any other dependent component jar required by the components defined in the deployment descriptor.
is specified for a grant entry — the SLEE assumes the specified path is relative to the root directory of the component jar within the deployable unit jar (but its use is otherwise undefined by the SLEE specification).

Below are a sample component jar deployment descriptor with added security permissions, and a table of security requirements that apply to methods invoked on classes loaded from different types of component jars with added permissions.

Sample component jar deployment descriptor with added security permissions

Below is an example of a resource adaptor component jar with added security permissions:

<resource-adaptor-jar>
<resource-adaptor>
<description> ... </description>
<resource-adaptor-name> Foo JCC </resource-adaptor-name>
<resource-adaptor-vendor> com.foo </resource-adaptor-vendor>
<resource-adaptor-version> 10/10/20 </resource-adaptor-version>
...
</resource-adaptor>

<security-permissions>
<description>
Allow the resource adaptor to modify thread groups and connect to remotehost on port 1234
</description>
<security-permission-spec>
grant {
permission java.lang.RuntimePermission "modifyThreadGroup";
permission java.net.SocketPermission "remotehost:1234", "connect";
};
</security-permission-spec>
</security-permissions>
</resource-adaptor-jar>

Security requirements for methods invoked on classes loaded from component jars

The following table describes the security requirements that apply to methods invoked on classes loaded from different types of component jars:

Component jar type Security requirements

Component jar type	Security requirements
SBB	Event-handler and initial event-selector methods run with the default set of security permissions granted by the SLEE, plus any additional security permissions specified in the SBB’s component jar deployment descriptor. The `isolate-security-permissions` attribute of the `sbb-local-interface` element in the SBB’s deployment descriptor controls whether or not security permissions of other protection domains in the call stack are propagated to the SBB when a business method on the SBB Local interface is invoked: If `False` — then the method in the SBB abstract class invoked as a result of a business method invoked on the SBB Local interface runs with an access control context that includes the protection domain(s) of the SBB as well as the protection domains of any other classes in the call stack as prescribed by the Java security model, such as the SBB that invoked the SBB Local interface method. If `True` — the SLEE automatically wraps the method invoked on the SBB abstract class in response to the SBB Local interface method invocation in an `AccessController.doPrivileged` block in order to isolate the security permissions of the invoked SBB. That is, the security permissions of other protection domains in the call stack do not affect the invoked SBB. All methods defined in the `javax.slee.Sbb` interface can be invoked on an SBB object from an unpredictable call path. If any of these methods need to execute privileged code requiring security permissions over and above the standard set of permissions granted by the SLEE, the additional security permissions must be declared in the SBB component jar’s deployment descriptor and the relevant methods must wrap the privileged code in an `AccessController.doPrivileged` block to ensure that potentially more restrictive security permissions of other protection domains in the call stack do not prohibit the privileged code from being executed.
Profile spec	All management methods invoked on the Profile Management interface run with the default set of security permissions granted by the SLEE, plus any additional security permissions specified in the Profile Specification’s component jar deployment descriptor. The `isolate-security-permissions` attribute of the profile-local-interface element in the Profile Specification’s deployment descriptor controls whether or not security permissions of other protection domains in the call stack are propagated to the Profile when a business method on the Profile Local interface is invoked. If `False` — the method in the Profile abstract class invoked as a result of a business method invoked on the Profile Local interface runs with an access control context that includes the protection domain(s) of the Profile Specification as well as the protection domains of any other classes in the call stack as prescribed by the Java security model, such as the SLEE Component that invoked the Profile Local interface method. If `True` — the SLEE automatically wraps the method invoked on the Profile abstract class in response to the Profile Local interface method invocation in an `AccessController.doPrivileged` block in order to isolate the security permissions of the invoked Profile, i.e. the security permissions of other protection domains in the call stack do not affect the invoked Profile. The `setProfileContext`, `unsetProfileContext`, `profilePostCreate`, `profileActivate`, `profilePassivate`, `profileLoad`, `profileStore`, and `profileRemove` methods defined in the `javax.slee.profile.Profile` interface can be invoked on a Profile object from an unpredictable call path. If any of these methods need to execute privileged code requiring security permissions over and above the standard set of permissions granted by the SLEE, the additional security permissions must be declared in the Profile Specification component jar’s deployment descriptor and the relevant methods must wrap the privileged code in an `AccessController.doPrivileged` block to ensure that potentially more restrictive security permissions of other protection domains in the call stack do not prohibit the privileged code from being executed. The `profileInitialize` and `profileVerify` methods defined in the `javax.slee.profile.Profile` interface are invoked as a result of management operations and therefore run with the default set of security permissions granted by the SLEE, plus any additional security permissions specified in the Profile Specification’s component jar deployment descriptor.
Resource adaptor	All methods invoked by the SLEE on the `javax.slee.resource.ResourceAdaptor` and `javax.slee.resource.Marshaler` interfaces run with the default set of security permissions granted by the SLEE, plus any additional security permissions specified in the Resource Adaptor’s component jar deployment descriptor. All methods that may be invoked by other SLEE Components such as SBBs run with the set of security permissions that is the intersection of the permissions of all protection domains traversed by the current execution thread (up until any `AccessController.doPrivileged` invocation in the call stack). If any of these methods need to execute privileged code requiring security permissions over and above the standard set of permissions granted by the SLEE, the additional security permissions must be declared in the Resource Adaptor component jar’s deployment descriptor and the relevant methods must wrap the privileged code in an `AccessController.doPrivileged` block to ensure that potentially more restrictive security permissions of other protection domains in the call stack do not prohibit the privileged code from being executed.
Library	All methods run with the set of permissions that is the intersection of the permissions of all protection domains traversed by the current execution thread (up until any `AccessController.doPrivileged` invocation in the call stack). If a library component method needs to execute privileged code requiring security permissions over and above the standard set of permissions granted by the SLEE, the additional security permissions must be declared in the library component jar’s deployment descriptor and the method must wrap the privileged code in an `AccessController.doPrivileged` block to ensure that potentially more restrictive security permissions of other protection domains in the call stack do not prohibit the privileged code from being executed.

SBB

Event-handler and initial event-selector methods run with the default set of security permissions granted by the SLEE, plus any additional security permissions specified in the SBB’s component jar deployment descriptor.
The isolate-security-permissions attribute of the sbb-local-interface element in the SBB’s deployment descriptor controls whether or not security permissions of other protection domains in the call stack are propagated to the SBB when a business method on the SBB Local interface is invoked:
- If False — then the method in the SBB abstract class invoked as a result of a business method invoked on the SBB Local interface runs with an access control context that includes the protection domain(s) of the SBB as well as the protection domains of any other classes in the call stack as prescribed by the Java security model, such as the SBB that invoked the SBB Local interface method.
- If True — the SLEE automatically wraps the method invoked on the SBB abstract class in response to the SBB Local interface method invocation in an AccessController.doPrivileged block in order to isolate the security permissions of the invoked SBB. That is, the security permissions of other protection domains in the call stack do not affect the invoked SBB.
All methods defined in the javax.slee.Sbb interface can be invoked on an SBB object from an unpredictable call path. If any of these methods need to execute privileged code requiring security permissions over and above the standard set of permissions granted by the SLEE, the additional security permissions must be declared in the SBB component jar’s deployment descriptor and the relevant methods must wrap the privileged code in an AccessController.doPrivileged block to ensure that potentially more restrictive security permissions of other protection domains in the call stack do not prohibit the privileged code from being executed.

Profile spec

All management methods invoked on the Profile Management interface run with the default set of security permissions granted by the SLEE, plus any additional security permissions specified in the Profile Specification’s component jar deployment descriptor.
The isolate-security-permissions attribute of the profile-local-interface element in the Profile Specification’s deployment descriptor controls whether or not security permissions of other protection domains in the call stack are propagated to the Profile when a business method on the Profile Local interface is invoked.
- If False — the method in the Profile abstract class invoked as a result of a business method invoked on the Profile Local interface runs with an access control context that includes the protection domain(s) of the Profile Specification as well as the protection domains of any other classes in the call stack as prescribed by the Java security model, such as the SLEE Component that invoked the Profile Local interface method.
- If True — the SLEE automatically wraps the method invoked on the Profile abstract class in response to the Profile Local interface method invocation in an AccessController.doPrivileged block in order to isolate the security permissions of the invoked Profile, i.e. the security permissions of other protection domains in the call stack do not affect the invoked Profile.
The setProfileContext, unsetProfileContext, profilePostCreate, profileActivate, profilePassivate, profileLoad, profileStore, and profileRemove methods defined in the javax.slee.profile.Profile interface can be invoked on a Profile object from an unpredictable call path. If any of these methods need to execute privileged code requiring security permissions over and above the standard set of permissions granted by the SLEE, the additional security permissions must be declared in the Profile Specification component jar’s deployment descriptor and the relevant methods must wrap the privileged code in an AccessController.doPrivileged block to ensure that potentially more restrictive security permissions of other protection domains in the call stack do not prohibit the privileged code from being executed.
The profileInitialize and profileVerify methods defined in the javax.slee.profile.Profile interface are invoked as a result of management operations and therefore run with the default set of security permissions granted by the SLEE, plus any additional security permissions specified in the Profile Specification’s component jar deployment descriptor.

Resource adaptor

All methods invoked by the SLEE on the javax.slee.resource.ResourceAdaptor and javax.slee.resource.Marshaler interfaces run with the default set of security permissions granted by the SLEE, plus any additional security permissions specified in the Resource Adaptor’s component jar deployment descriptor.
All methods that may be invoked by other SLEE Components such as SBBs run with the set of security permissions that is the intersection of the permissions of all protection domains traversed by the current execution thread (up until any AccessController.doPrivileged invocation in the call stack). If any of these methods need to execute privileged code requiring security permissions over and above the standard set of permissions granted by the SLEE, the additional security permissions must be declared in the Resource Adaptor component jar’s deployment descriptor and the relevant methods must wrap the privileged code in an AccessController.doPrivileged block to ensure that potentially more restrictive security permissions of other protection domains in the call stack do not prohibit the privileged code from being executed.

Library

All methods run with the set of permissions that is the intersection of the permissions of all protection domains traversed by the current execution thread (up until any AccessController.doPrivileged invocation in the call stack). If a library component method needs to execute privileged code requiring security permissions over and above the standard set of permissions granted by the SLEE, the additional security permissions must be declared in the library component jar’s deployment descriptor and the method must wrap the privileged code in an AccessController.doPrivileged block to ensure that potentially more restrictive security permissions of other protection domains in the call stack do not prohibit the privileged code from being executed.

Previous page Next page