WebLogic Server supports the Java EE architecture security model for securing Enterprise JavaBeans (EJBs), which includes support for declarative authorization (also referred to in this document as declarative security) and programmatic authorization (also referred to in this document as programmatic security).
The following topics are covered in this section:
Using Programmatic Security With EJBs
Note:
You can use deployment descriptor files, the Administration Console, and JACC to secure EJBs. For information on using the Administration Console to secure EJBs, see Securing Resources Using Roles and Policies for Oracle WebLogic Server. For information on JACC, see Using the Java Authorization Contract for Containers.The Java EE 5 Tutorial states the following in the section titled "Securing Containers":
"In Java EE, the component containers are responsible for providing application security. A container provides two types of security: declarative and programmatic."
"Declarative security expresses an application component's security requirements using deployment descriptors. A deployment descriptor is an XML document with an .xml extension that describes the deployment settings of an application, a module, or a component. Because deployment descriptor information is declarative, it can be changed without the need to modify the source code. At run time, the Java EE server reads the deployment descriptor and acts upon the application, module, or component accordingly."
"Programmatic security is embedded in an application and is used to make security decisions. Programmatic security is useful when declarative security alone is not sufficient to express the security model of an application. The API for programmatic security consists of two methods of the EJBContext interface and two methods of the servlet HttpServletRequest interface. These methods allow components to make business logic decisions based on the security role of the caller or remote user."
For more information, see Chapter 29, "Securing Java EE Applications" in The Java EE 5 Tutorial at the following URL:
http://docs.oracle.com/javaee/5/tutorial/doc/bnbyk.html
As explained in The Java EE 5 Tutorial, declarative security expresses an application component's security requirements using deployment descriptors. A deployment descriptor is an XML document with an .xml extension that describes the deployment settings of an application, a module, or a component. Because deployment descriptor information is declarative, it can be changed without the need to modify the source code. At runtime, the Java EE server reads the deployment descriptor and acts upon the application, module, or component accordingly.
WebLogic Server supports the use of deployment descriptors to implement declarative authorization in EJBs. For more information, see the section ”Securing Enterprise Beans” in Chapter 29, ”Securing Java EE Applications,” in The Java EE 5 Tutorial at the following URL:
As stated in The Java EE 5 Tutorial, programmatic security is embedded in an application and is used to make security decisions. Programmatic security is useful when declarative security alone is not sufficient to express the security model of an application. The API for programmatic security consists of two methods of the EJBContext interface and two methods of the servlet HttpServletRequest interface. These methods allow components to make business logic decisions based on the security role of the caller or remote user.
In general, security management should be enforced by the container in a manner that is transparent to the enterprise beans' business methods. The security API described in this section should be used only in the less frequent situations in which the enterprise bean business methods need to access the security context information.
The javax.ejb.EJBContext
interface provides two methods that allow the bean provider to access security information about the enterprise bean's caller.
java.security.Principal getCallerPrincipal();
The purpose of the getCallerPrincipal method is to allow the enterprise bean methods to obtain the current caller principal's name. The methods might, for example, use the name as a key to information in a database.
boolean isCallerInRole(String roleName);
The purpose of the isCallerInRole(String roleName) method is to test whether the current caller has been assigned to a given security role. Security roles are defined by the bean provider or the application assembler, and are assigned to principals or principals groups that exist in the operational environment by the deployer.
For more information, see the section "Accessing an Enterprise Bean Caller's Security Context" in Chapter 29, ”Securing Java EE Applications,” in The Java EE 5 Tutorial at the following URL:
http://docs.oracle.com/javaee/5/tutorial/doc/bnbyl.html#bnbyn
Programmatic security is used by security-aware applications when declarative security alone is not sufficient to express the security model of the application. When choosing the security model that works best for you, consider who is responsible for managing security in your organization. Developers are most familiar with the application components they build, but they might not necessarily be familiar with the deployment environment in which those components run. In addition, as security policies change, it is more economical to reconfigure security declaratively instead of rebuilding, retesting, and redeploying applications, which may be necessary when making programmatic security updates.
There are three ways to implement declarative security:
Security providers via the Administration Console, as described in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
Java Authorization Contract for Containers (JACC), as described in Using the Java Authorization Contract for Containers.
Deployment descriptors, which are discussed in this section.
Which of these three methods is used is defined by the JACC flags and the security model. (Security models are described in "Options for Securing EJB and Web Application Resources" in Securing Resources Using Roles and Policies for Oracle WebLogic Server)
To implement declarative security in EJBs you can use deployment descriptors (ejb-jar.xml
and weblogic-ejb-jar.xml
) to define the security requirements. Example 6-1 shows examples of how to use the ejb-jar.xml
and weblogic-ejb-jar.xml
deployment descriptors to map security role names to a security realm. The deployment descriptors map the application's logical security requirements to its runtime definitions. And at runtime, the EJB container uses the security definitions to enforce the requirements.
To configure security in the EJB deployment descriptors, perform the following steps (see Example 6-1):
Use a text editor to create ejb-jar.xml
and weblogic-ejb-jar.xml
deployment descriptor files.
In the ejb-jar.xml
file, define the security role name, the EJB name, and the method name (see bold text).
Notes:
The proper syntax for a security role name is as defined for an Nmtoken in the Extensible Markup Language (XML) recommendation available on the Web at:http://www.w3.org/TR/REC-xml#NT-Nmtoken
.
When specifying security role names, observe the following conventions and restrictions:
Do not use blank spaces, commas, hyphens, or any characters in this comma-separated list: \t, < >, #, |, &, ~, ?, ( ), { }.
Security role names are case sensitive.
The suggested convention for security role names is that they be singular.
For more information on configuring security in the ejb-jar.xml file, see the Enterprise JavaBeans Specification, Version 2.0 which is at this location on the Internet: http://java.sun.com/products/ejb/docs.html
.
In the WebLogic-specific EJB deployment descriptor file, weblogic-ejb-jar.xml
, define the security role name and link it to one or more principals (users or groups) in a security realm.
For more information on configuring security in the weblogic-ejb-jar.xml
file, see "weblogic-ejb-jar.xml Deployment Descriptor Reference" in Programming WebLogic Enterprise JavaBeans for Oracle WebLogic Server.
Example 6-1 Using ejb-jar.xml and weblogic-ejb-jar.xml Files to Map Security Role Names to a Security Realm
ejb-jar.xml entries: ... <assembly-descriptor> <security-role> <role-name>manger</role-name> </security-role> <security-role> <role-name>east</role-name> </security-role> <method-permission> <role-name>manager</role-name> <role-name>east</role-name> <method> <ejb-name>accountsPayable</ejb-name> <method-name>getReceipts</method-name> </method> </method-permission> ... </assembly-descriptor> ... weblogic-ejb-jar.xml entries: <security-role-assignment> <role-name>manager</role-name> <principal-name>al</principal-name> <principal-name>george</principal-name> <principal-name>ralph</principal-name> </security-role-assignment> ...
The following topics describe the deployment descriptor elements that are used in the ejb-jar.xml
and weblogic-ejb-jar.xml
files to define security requirements in EJBs:
The following ejb-jar.xml
deployment descriptor elements are used to define security requirements in WebLogic Server:
The method
element is used to denote a method of an enterprise bean's home or component interface, or, in the case of a message-driven bean, the bean's onMessage
method, or a set of methods.
The following table describes the elements you can define within an method
element.
Element | Required/Optional | Description |
---|---|---|
<description> |
Optional |
A text description of the method. |
<ejb-name> |
Required |
Specifies the name of one of the enterprise beans declared in the |
<method-intf> |
Optional |
Allows you to distinguish between a method with the same signature that is multiply defined across both the home and component interfaces of the enterprise bean. |
<method-name> |
Required |
Specifies a name of an enterprise bean method or the asterisk (*) character. The asterisk is used when the element denotes all the methods of an enterprise bean's component and home interfaces. |
<method-params> |
Optional |
Contains a list of the fully-qualified Java type names of the method parameters. |
The method-permission
element specifies that one or more security roles are allowed to invoke one or more enterprise bean methods. The method-permission
element consists of an optional description, a list of security role names or an indicator to state that the method is unchecked for authorization, and a list of method elements.
The security roles used in the method-permission
element must be defined in the security-role
elements of the deployment descriptor, and the methods must be methods defined in the enterprise bean's component and/or home interfaces.
The following table describes the elements you can define within a method-permission
element.
Table 6-2 method-permission Element
Element | Required/Optional | Description |
---|---|---|
<description> |
Optional |
A text description of this security constraint. |
<role-name> or <unchecked> |
Required |
The The The |
<method> |
Required |
Specifies a method of an enterprise bean's home or component interface, or, in the case of a message-driven bean, the bean's |
The role-name element contains the name of a security role. The name must conform to the lexical rules for an NMTOKEN
.
The run-as
element specifies the run-as identity to be used for the execution of the enterprise bean. It contains an optional description, and the name of a security role.
The security-identity
element specifies whether the caller's security identity is to be used for the execution of the methods of the enterprise bean or whether a specific run-as identity is to be used. It contains an optional description and a specification of the security identity to be used.
The following table describes the elements you can define within an security-identity
element.
Table 6-3 security-identity Element
Element | Required/Optional | Description |
---|---|---|
<description> |
Optional |
A text description of the security identity. |
<use-caller-identity> or <run-as> |
Required |
The The The run-as element specifies the run-as identity to be used for the execution of the enterprise bean. It contains an optional description, and the name of a security role. |
The security-identity
element is used within the entity
, message-driven
, and session
elements.
For an example of how to use the security-identity
element, see Example 6-3 and Example 6-8.
The security-role
element contains the definition of a security role. The definition consists of an optional description of the security role, and the security role name.
The security-role-ref
element contains the declaration of a security role reference in the enterprise bean's code. The declaration consists of an optional description, the security role name used in the code, and an optional link to a security role. If the security role is not specified, the Deployer must choose an appropriate security role.
The value of the role-name
element must be the String used as the parameter to the EJBContext.isCallerInRole(String roleName)
method or the HttpServletRequest.isUserInRole(String role)
method.
For an example of how to use the security-role-ref element, see Example 6-2.
Example 6-2 Security-role-ref Element Example
<!DOC<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd"> <ejb-jar> <enterprise-beans> ... <session> <ejb-name>SecuritySLEJB</ejb-name> <home>weblogic.ejb20.security.SecuritySLHome</home> <remote>weblogic.ejb20.security.SecuritySL</remote> <ejb-class>weblogic.ejb20.security.SecuritySLBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> <security-role-ref> <role-name>rolenamedifffromlink</role-name> <role-link>role121SL</role-link> </security-role-ref> <security-role-ref> <role-name>roleForRemotes</role-name> <role-link>roleForRemotes</role-link> </security-role-ref> <security-role-ref> <role-name>roleForLocalAndRemote</role-name> <role-link>roleForLocalAndRemote</role-link> </security-role-ref> </session> ... </enterprise-beans> </ejb-jar>
The unchecked
element specifies that a method is not checked for authorization by the container prior to invocation of the method.
The use-caller-identity
element specifies that the caller's security identity be used as the security identity for the execution of the enterprise bean's methods.
For an example of how to use the use-caller-identity
element, see Example 6-3.
Example 6-3 use-caller-identity Element Example
<ejb-jar> <enterprise-beans> <session> <ejb-name>SecurityEJB</ejb-name> <home>weblogic.ejb20.SecuritySLHome</home> <remote>weblogic.ejb20.SecuritySL</remote> <local-home> weblogic.ejb20.SecurityLocalSLHome </local-home> <local>weblogic.ejb20.SecurityLocalSL</local> <ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> <message-driven> <ejb-name>SecurityEJB</ejb-name> <ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class> <transaction-type>Container</transaction-type> <security-identity> <use-caller-identity/> </security-identity> </message-driven> </enterprise-beans> </ejb-jar>
The following weblogic-ejb-jar.xml
deployment descriptor elements are used to define security requirements in WebLogic Server:
The client-authentication
element specifies whether the EJB supports or requires client authentication.
The following table defines the possible settings.
The client-cert-authentication
element specifies whether the EJB supports or requires client certificate authentication at the transport level.
The following table defines the possible settings.
The confidentiality
element specifies the transport confidentiality requirements for the EJB. Using the confidentiality
element ensures that the data is sent between the client and server in such a way as to prevent other entities from observing the contents.
The following table defines the possible settings.
The externally-defined
element lets you explicitly indicate that you want the security roles defined by the role-name
element in the weblogic-ejb-jar.xml
deployment descriptors to use the mappings specified in the Administration Console. The element gives you the flexibility of not having to specify a specific security role mapping for each security role defined in the deployment descriptors for a particular Web application. Therefore, within the same security realm, deployment descriptors can be used to specify and modify security for some applications while the Administration Console can be used to specify and modify security for others.
Note:
Starting in version 9.0, the default role mapping behavior is to create empty role mappings when none are specified. In version 8.1, EJB required that role mappings be defined in the weblogic-ejb-jar.xml descriptor or deployment would fail. With 9.0, EJB and WebApp behavior are consistent in creating empty role mappings.For information on role mapping behavior and backward compatibility settings, see the section "Understanding the Combined Role Mapping Enabled Setting" in Securing Resources Using Roles and Policies for Oracle WebLogic Server. The role mapping behavior for a server depends on which security deployment model is selected on the Administration Console. For information on security deployment models, see "Options for Securing EJB and Web Application Resources" in Securing Resources Using Roles and Policies for Oracle WebLogic Server.
When specifying security role names, observe the following conventions and restrictions:
The proper syntax for a security role name is as defined for an Nmtoken
in the Extensible Markup Language (XML) recommendation available on the Web at: http://www.w3.org/TR/REC-xml#NT-Nmtoken
.
Do not use blank spaces, commas, hyphens, or any characters in this comma-separated list: \t, < >, #, |, &, ~, ?, ( ), { }.
Security role names are case sensitive.
The suggested convention for security role names is that they be singular.
Example 6-4 and Example 6-5 show by comparison how to use the externally-defined
element in the weblogic-ejb-jar.xml
file. In Example 6-5, the specification of the "manager" externally-defined
element in the weblogic-ejb-jar.xml
means that for security to be correctly configured on the getReceipts
method, the principals for manager
will have to be created in the Administration Console.
Example 6-4 Using the ejb-jar.xml and weblogic-ejb-jar.xml Deployment Descriptors to Map Security Roles in EJBs
ejb-jar.xml entries: ... <assembly-descriptor> <security-role> <role-name>manger</role-name> </security-role> <security-role> <role-name>east</role-name> </security-role> <method-permission> <role-name>manager</role-name> <role-name>east</role-name> <method> <ejb-name>accountsPayable</ejb-name> <method-name>getReceipts</method-name> </method> </method-permission> ... </assembly-descriptor> ... weblogic-ejb-jar.xml entries: <security-role-assignment> <role-name>manager</role-name> <principal-name>joe</principal-name> <principal-name>Bill</principal-name> <principal-name>Mary</principal-name> ... </security-role-assignment> ...
Example 6-5 Using the externally-defined Element in EJB Deployment Descriptors for Role Mapping
ejb-jar.xml entries: ... <assembly-descriptor> <security-role> <role-name>manger</role-name> </security-role> <security-role> <role-name>east</role-name> </security-role> <method-permission> <role-name>manager</role-name> <role-name>east</role-name> <method> <ejb-name>accountsPayable</ejb-name> <method-name>getReceipts</method-name> </method> </method-permission> ... </assembly-descriptor> ... weblogic-ejb-jar.xml entries: <security-role-assignment> <role-name>manager</role-name> <externally-defined/> ... </security-role-assignment> ...
For more information on using the Administration Console to configure security for EJBs, see Securing Resources Using Roles and Policies for Oracle WebLogic Server.
The identity-assertion
element specifies whether the EJB supports identity assertion.
The following table defines the possible settings.
The iiop-security-descriptor
element specifies security configuration parameters at the bean-level. These parameters determine the IIOP security information contained in the interoperable object reference (IOR).
For an example of how to use the iiop-security-descriptor
element, see Example 6-6.
Example 6-6 iiop-security-descriptor Element Example
<weblogic-enterprise-bean> <iiop-security-descriptor> <transport-requirements> <confidentiality>supported</confidentiality> <integrity>supported</integrity> <client-cert-authorization> supported </client-cert-authentication> </transport-requirements> <client-authentication>supported<client-authentication> <identity-assertion>supported</identity-assertion> </iiop-security-descriptor> </weblogic-enterprise-bean>
The integrity
element specifies the transport integrity requirements for the EJB. Using the integrity element ensures that the data is sent between the client and server in such a way that it cannot be changed in transit.
The following table defines the possible settings.
Setting | Definition |
---|---|
none |
Integrity is not supported. |
supported |
Integrity is supported, but not required. |
required |
Integrity is required. |
The principal-name
element specifies the name of the principal in the ProductName security realm that applies to role name specified in the security-role-assignment element. At least one principal
is required in the security-role-assignment
element. You may define more than one principal-name
for each role name.
Note:
If you need to list a significant number of principals, consider specifying groups instead of users. There are performance issues if you specify too many users.The role-name
element identifies an application role name that the EJB provider placed in the companion ejb-jar.xml
file. Subsequent principal-name elements in the stanza map ProductName principals to the specified role-name
.
The run-as-identity-principal
element specifies which security principal name is to be used as the run-as principal for a bean that has specified a security-identity run-as role-name in its ejb-jar deployment descriptor. For an explanation of how of run-as role-names to are mapped to run-as-identity-principals (or run-as-principal-names, see run-as-role-assignment.
Note:
Deprecated: The run-as-identity-principal element is deprecated in the WebLogic Server 8.1. Use the run-as-principal-name element instead.The run-as-identity-principal
element is used within the run-as-role-assignment
element.
For an example of how to use the run-as-identity-principal
element, see Example 6-7.
Example 6-7 run-as-identity-principal Element Example
ebj-jar.xml: <ejb-jar> <enterprise-beans> <session> <ejb-name>Caller2EJB</ejb-name> <home>weblogic.ejb11.security.CallerBeanHome</home> <remote>weblogic.ejb11.security.CallerBeanRemote</remote> <ejb-class>weblogic.ejb11.security.CallerBean</ejb-class> <session-type>Stateful</session-type> <transaction-type>Container</transaction-type> <ejb-ref><ejb-ref-name>Callee2Bean</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <home>weblogic.ejb11.security.CalleeBeanHome</home> <remote>weblogic.ejb11.security.CalleeBeanRemote</remote> </ejb-ref> <security-role-ref> <role-name>users1</role-name> <role-link>users1</role-link> </security-role-ref> <security-identity> <run-as> <role-name>users2</role-name> </run-as> </security-identity> </session> </enterprise-beans> </ejb-jar> woblogic-ejb-jar.xml: <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>Caller2EJB</ejb-name> <reference-descriptor> <ejb-reference-description> <ejb-ref-name>Callee2Bean</ejb-ref-name> <jndi-name>security.Callee2Bean</jndi-name> </ejb-reference-description> </reference-descriptor> <run-as-identity-principal>wsUser3</run-as-identity-principal> </weblogic-enterprise-bean> <security-role-assignment> <role-name>user</role-name> <principal-name>wsUser2</principal-name> <principal-name>wsUser3</principal-name> <principal-name>wsUser4</principal-name> </security-role-assignment> </weblogic-ejb-jar>
The run-as-principal-name
element specifies which security principal name is to be used as the run-as principal for a bean that has specified a security-identity run-as role-name in its ejb-jar deployment descriptor. For an explanation of how the run-as role-names map to run-as-principal-names, see run-as-role-assignment.
The run-as-role-assignment
element is used to map a given security-identity run-as role-name that is specified in the ejb-jar.xml
file to a run-as-principal-name
specified in the weblogic-ejb-jar.xml
file. The value of the run-as-principal-name
element for a given role-name is scoped to all beans in the ejb-jar.xml
file that use the specified role-name as their security-identity. The value of the run-as-principal-name
element specified in weblogic-ejb-jar.xml
file can be overridden at the individual bean level by specifying a run-as-principal-name
element under that bean's weblogic-enterprise-bean
element.
Note:
For a given bean, if there is no run-as-principal-name element specified in either a run-as-role-assignment element or in a bean specific run-as-principal-name element, then the EJB container will choose the first principal-name of a security user in the weblogic-enterprise-bean security-role-assignment element for the role-name and use that principal-name as the run-as-principal-name.For an example of how to use the run-as-role-assignment element, see Example 6-8.
Example 6-8 run-as-role-assignment Element Example
In the ejb-jar.xml file: // Beans "A_EJB_with_runAs_role_X" and "B_EJB_with_runAs_role_X" // specify a security-identity run-as role-name "runAs_role_X". // Bean "C_EJB_with_runAs_role_Y" specifies a security-identity // run-as role-name "runAs_role_Y". <ejb-jar> <enterprise-beans> <session> <ejb-name>SecurityEJB</ejb-name> <home>weblogic.ejb20.SecuritySLHome</home> <remote>weblogic.ejb20.SecuritySL</remote> <local-home> weblogic.ejb20.SecurityLocalSLHome </local-home> <local>weblogic.ejb20.SecurityLocalSL</local> <ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> <message-driven> <ejb-name>SecurityEJB</ejb-name> <ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class> <transaction-type>Container</transaction-type> <security-identity> <run-as> <role-name>runAs_role_X</role-name> </run-as> </security-identity> <security-identity> <run-as> <role-name>runAs_role_Y</role-name> </run-as> </security-identity> </message-driven> </enterprise-beans> </ejb-jar> weblogic-ejb-jar file: <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>A_EJB_with_runAs_role_X</ejb-name> </weblogic-enterprise-bean> <weblogic-enterprise-bean> <ejb-name>B_EJB_with_runAs_role_X</ejb-name> <run-as-principal-name>Joe</run-as-principal-name> </weblogic-enterprise-bean> <weblogic-enterprise-bean> <ejb-name>C_EJB_with_runAs_role_Y</ejb-name> </weblogic-enterprise-bean> <security-role-assignment> <role-name>runAs_role_Y</role-name> <principal-name>Harry</principal-name> <principal-name>John</principal-name> </security-role-assignment> <run-as-role-assignment> <role-name>runAs_role_X</role-name> <run-as-principal-name>Fred</run-as-principal-name> </run-as-role-assignment> </weblogic-ejb-jar>
Each of the three beans shown in Example 6-8 will choose a different principal name to run as.
A_EJB_with_runAs_role_X
This bean's run-as role-name is runAs_role_X
. The jar-scoped <run-as-role-assignment>
mapping will be used to look up the name of the principal to use. The <run-as-role-assignment>
mapping specifies that for <role-name> runAs_role_X
we are to use <run-as-principal-name>
Fred
. Therefore, Fred
is the principal name that will be used.
B_EJB_with_runAs_role_X
This bean's run-as role-name is also runAs_role_X
. This bean will not use the jar scoped <run-as-role-assignment>
to look up the name of the principal to use because that value is overridden by this bean's <weblogic-enterprise-bean> <run-as-principal-name>
value Joe
. Therefore Joe
is the principal name that will be used.
C_EJB_with_runAs_role_Y
This bean's run-as role-name is runAs_role_Y
. There is no explicit mapping of runAs_role_Y
to a run-as principal name, that is, there is no jar scoped <run-as-role-assignment>
for runAs_role_Y
nor is there a bean scoped <run-as-principal-name>
specified in this bean's <weblogic-enterprise-bean>
. To determine the principal name to use, the <security-role-assignment>
for <role-name>
runAs_role_Y
is examined. The first <principal-name>
corresponding to a user that is not a Group is chosen. Therefore, Harry
is the principal name that will be used.
The security-permission
element specifies a security permission that is associated with a Java EE Sandbox.
The security-permission-spec
element specifies a single security permission based on the Security policy file syntax.
For more information, see Sun's implementation of the security permission specification:
http://download.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html#FileSyntax
Note:
Disregard the optional codebase and signedBy clauses.For an example of how to use the security-permission-spec
element, see Example 6-9.
Example 6-9 security-permission-spec Element Example
<weblogic-ejb-jar> <security-permission> <description>Optional explanation goes here</description> <security-permission-spec> <! A single grant statement following the syntax of http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax, without the codebase and signedBy clauses, goes here. For example: --> grant { permission java.net.SocketPermission *, resolve; }; </security-permission-spec> </security-permission> </weblogic-ejb-jar>
In Example 6-9, permission java.net.SocketPermission
is the permission class name, "*" represents the target name, and resolve
(resolve host/IP name service lookups) indicates the action.
The security-role-assignment
element maps application roles in the ejb-jar.xml
file to the names of security principals available in ProductName.
Note:
For information on using the security-role-assignment element in a weblogic-application.xml deployment descriptor for an enterprise application, see "Enterprise Application Deployment Descriptor Elements" in Developing Applications for Oracle WebLogic Server.The transport-requirements
element defines the transport requirements for the EJB.
For an example of how to use the transport-requirements
element, see Example 6-10.
Example 6-10 transport-requirements Element Example
<weblogic-enterprise-bean> <iiop-security-descriptor> <transport-requirements> <confidentiality>supported</confidentiality> <integrity>supported</integrity> <client-cert-authorization> supported </client-cert-authentication> </transport-requirements> </iiop-security-descriptor> <weblogic-enterprise-bean>
To implement programmatic security in EJBs, use the javax.ejb.EJBContext
.getCallerPrincipal()
and the javax.ejb.EJBContext.isCallerInRole()
methods.
Use the getCallerPrincipal()
method to determine the caller of the EJB. The javax.ejb.EJBContext
.getCallerPrincipal()
method returns a WLSUser
Principal
if one exists in the Subject
of the calling user. In the case of multiple WLSUser
Principals
, the method returns the first in the ordering defined by the Subject.getPrincipals().iterator()
method. If there are no WLSUser
Principals
, then the getCallerPrincipal()
method returns the first non-WLSGroup
Principal
. If there are no Principals
or all Principals
are of type WLSGroup
, this method returns weblogic.security.WLSPrincipals.getAnonymousUserPrincipal()
. This behavior is similar to the semantics of weblogic.security.SubjectUtils.getUserPrincipal()
except that SubjectUtils.getUserPrincipal()
returns a null
whereas EJBContext
.getCallerPrincipal()
returns WLSPrincipals.getAnonmyousUserPrincipal()
.
For more information about how to use the getCallerPrincipal()
method, see http://www.oracle.com/technetwork/java/javaee/tech/index.html
.
The isCallerInRole()
method is used to determine if the caller (the current user) has been assigned a security role that is authorized to perform actions on the WebLogic resources in that thread of execution. For example, the method javax.ejb.EJBContext.isCallerInRole("admin")
will return true
if the current user has admin
privileges.
For more information about how to use the isCallerInRole()
method, see http://www.oracle.com/technetwork/java/javaee/tech/index.html
.