Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide 10g (10.1.3.5.0) Part Number E13981-01 |
|
|
View PDF |
Depending on the type of client, you may need to specify security credentials before your client can access an enterprise bean or other JNDI-accessible resource.
Table 22-1 classifies EJB clients by where they are deployed relative to the target enterprise bean they invoke. Where you deploy the client relative to its target enterprise bean determines whether or not you must specify security credentials.
Table 22-1 Client Security Credential Requirements
Client Type | Relationship to Target EJB | Set Credentials? |
---|---|---|
Any client |
Client and target enterprise bean are collocated |
No |
Any client |
Client and target enterprise bean are deployed in the same application |
No |
Any client |
Target enterprise bean deployed in an application that is designated as the client's parentFoot 1 |
No |
Any client |
Client and target enterprise bean are not collocated, not deployed in the same application, and target EJB application is not client's parentFootref 1. |
Yes |
Footnote 1 See the Oracle Containers for J2EE Developer's Guide for more information on how to set the parent of an application.
When you access enterprise beans in a remote container (that is, if the client and target enterprise bean are not collocated, not deployed in the same application, and the target enterprise bean application is not the client's parent), you must pass valid credentials to the remote container. How your client passes its credentials depends on the type of client:
EJB Client: pass credentials within the InitialContext
, which is created to look up the remote enterprise beans (see "Specifying Credentials in the Initial Context").
Standalone Java Client: define credentials in the jndi.properties
file deployed with the EAR file (see "Specifying Credentials in JNDI Properties").
Servlet or JSP Client: pass credentials within the InitialContext
, which is created to look up the remote enterprise beans (see "Specifying Credentials in the Initial Context").
In addition, all clients can specify security properties in the ejb_sec.properties
file (see "Specifying EJB Client Security Properties in the ejb_sec.properties File").
For more information, see the following:
To specify credentials in a jndi.properties
file, do the following:
Create or modify an existing jndi.properties
file.
Configure the appropriate credentials in the jndi.properties
file, as Example 22-6 shows.
For property names, see the field definitions in javax.naming.Context
.
Ensure that the jndi.properties
file is on the client's classpath.
Use the JNDI API in your client to look up the JNDI-accessible resource as Example 22-6 shows.
At run time, JNDI uses ClassLoader
method getResources
to locate all application resource files named jndi.properties
in the classpath. In doing so, it will use the JNDI properties you set in Example 22-6 to access the purchaseOrderBean
.
For more information, see "Setting JNDI Properties With the JNDI Properties File".
To specify credentials in the initial context you use to look up JNDI-accessible resources, do the following:
Create a HashTable
and populate it with the required properties using javax.naming.Context
fields as keys and String
objects as values, as Example 22-7 shows.
Example 22-7 Specifying Credentials in the Initial Context
Hashtable env = new Hashtable(); env.put(Context.SECURITY_PRINCIPAL, "POMGR"); env.put(Context.SECURITY_CREDENTIALS, "welcome"); env.put("java.naming.factory.initial", "oracle.j2ee.server.ApplicationClientInitialContextFactory"); env.put("java.naming.provider.url", "opmn:ormi://opmnhost:6004:oc4j_inst1/ejbsamples");
When you instantiate the initial context, pass the HashTable
into the initial context constructor, as Example 22-8 shows.
For more information, see the following:
Any client, whether running inside a server or not, has EJB security properties controlled by an ejb_sec.properties
file. You use this file to specify general security options as well as options specific to the Common Secure Interoperability Version 2 protocol (CSIv2).
For more information, see "Common Secure Interoperability Protocol" in the Oracle Containers for J2EE Security Guide.