|
|
|
|
|
|
This topic includes the following sections:
This document describes the BEA implementation of the Security feature. The information in this document supplements the Sun Microsystems, Inc. evolving Enterprise JavaBeans 1.1 Specification (Public Release, October 18,1999).
Note:
Before proceeding with the remainder of this topic, you should be familiar with the entire content of Sun's specification, particularly Chapter 15, "Security Management."
This topic describes only the integrating security into WLE EJBs. For a complete description of developing an EJB using the WLE product, see Getting Started in the WebLogic Enterprise online documentation.
Note:
An EJB in the WLE domain that issues a callback to a remote J2EE client application cannot propagate the security context of that client application in the callback.
From the perspective of an EJB container, EJBs are nontrusted entities that require authentication. The WLE product uses a JNDI implementation that runs within the EJB container's trusted environment. Using the WLEInitialContextFactory
JNDI factory with security environment properties establishes the security context for the WLE client application. The WLE client application authenticates itself with the WLE domain when establishing the JNDI Initial context.
Table 7-1 lists the development steps required to implement security in a WLE EJB.
Before You Begin
How Authentication Works with WLE EJBs
Development Steps
Table 7-1 Development Steps for Implementing Security in a WLE EJB
Step |
Description |
|---|---|
|
Specify security roles in the Deployment Descriptor of the EJB.
|
|
|
Use the getCallerPrincipal
method to authenticate the WLE EJB.
|
During the assembly and deployment of an EJB package, you define security roles and associate roles with methods in the deployment descriptor. Security roles are mapped to groups of users in the WLE security environment. You can use any of the techniques described in the Security Management chapter of the Enterprise JavaBeans 1.1 Specification to define security roles for the methods of a WLE EJB.
It is possible that two methods with the same name or name/signature appear in both the bean's home and remote interfaces. To handle this case, the optional <method-intf>
element may further restrict the selection to either Home
or Remote
interface methods.
In a mandatory access control environment, any method invocation not specifically authorized is denied. Sometimes a method does not have a defined <method-permission>
element. If the SECURITY
parameter in the RESOURCES
section of the UBBCONFIG
file is set to MANDATORY_ACL
access on a method without an associated <method-permission>
element, access is denied. This is the recommended setting for production environments. For all other settings of the SECURITY
parameter, access to a method without an associated <method-permission>
element is allowed.
There may be methods that should be available to everyone, even in a mandatory access control environment. The WLE system defines a special role name *
which means everyone has access to the method.
You specify security roles for the methods of an EJB in the deployment descriptor of the bean. In the WLE product, there is a one-to-one association between the security roles defined in the deployment descriptor of the EJB and the groups defined with the tpgrpadd
commands. Role names may be referenced in deployment descriptors before the corresponding group exists. A run time, if a bean's deployment descriptor references a role that does not have a corresponding group, the role is ignored.
Role names are restricted to any alphanumeric characters, a dash (-
), an underscore( _
), the at-sign (@
), and a period ( .
). The maximum length of a role name is 30 characters. If the name of a security role does not conform to these limitations, it will not be possible for users to have the defined security role.
Listing 7-1 includes code that defines a security role.
Listing 7-1
Defining a Security Role for a Method in an EJB
... The following sections describe the JNDI environment properties that must be set to enable either Username/Password or certificate-based authentication.
The class com.beasys.jndi.WLEInitialContextFactory
is the JNDI Service Provider Interface (SPI). This initial context provides an entry point into the WLE domain. Set WLEContext.INITIAL_CONTEXT_FACTORY
to com.beasys.jndi.WLEInitialContextFactory
to access the WLE domain.
Listing 7-2 includes code that defines the WLEContext.INITIAL_CONTEXT_FACTORY
property for the WLE environment.
Listing 7-2
WLEContext.INITIAL_CONTEXT_FACTORY Property
Hashtable env = new Hashtable(); Specifies the entry point into the WLE domain. The value should reflect the host and port of the IIOP Listener/Handler of the target WLE domain. Use one of the following URL address formats when specifying the location of the IIOP Listener/Handler:
Step 1: Define security roles for the methods of the WLE EJB.
Step 2: Specify security roles in the Deployment Descriptor of the EJB.
<assembly-descriptor>
<security-role>
<description>
"teller" is a role name
</description>
</security-role>
<method-permission>
<role-name>teller</role-name>
<method>
<ejb-name>Accounting</ejb-name>
<method-name>withdraw</methodname>
</method>
...
</method-permission>
...
</assembly-descriptor>
...Step 3: Define the JNDI environment properties.
WLEContext.INITIAL_CONTEXT_FACTORY Property
/*
*Specify the initial context implementation to use.
*The service provider supplies the factory class.
*/
env.put(WLEContext.INITIAL_CONTEXT_FACTORY,
"com.beasys.jndi.WLEInitialContextFactory");
... WLEContext.PROVIDER_URL Property
Indicates that the IIOP/RMI protocol is to be used to communicate with the WLE domain. This URL address format only supports Username/Password authentication.
Indicates that the SSL protocol is to be used to communicate with the WLE domain. This URL address format supports both Username/password and certificate-based authentication.
The host and port combination in the URL must match the ISL parameter in the WLE application's UBBCONFIG
file. The format of the host and port combination as well as the capitalization must match. If the addresses do not match, communication with the WLE domain fails.
Listing 7-3 includes code that defines the WLEContext.PROVIDER_URL
property for the WLE environment.
Listing 7-3
WLEContext.PROPERTY_URL Property
... env.put(WLEContext.PROVIDER_URL, ... A WLE server application that acts as a client application (referred to as a joint client/server application) must set the WLEContext.PROPERTY_URL
as an empty or null string. The joint client/server application connects to the current application in which it was booted.
Set this property to indicate the type of authentication to be used. The valid values for this property are as follows:
"corbaloc://"myhost:1000"); WLEContext.SECURITY_AUTHENTICATION Property
See Table 7-2 for additional keys that need to be specified to use Username/Password or certificate-based authentication.
Listing 7-4 includes code that defines the WLEContext.SECURITY_AUTHENTICATION
property for the WLE environment.
Listing 7-4
WLEContext.SECURITY_AUTHENTICATION Property
... env.put(WLEContext.SECURITY_AUTHENTICATION, "strong"); ...
Listing 7-5 includes the WLE keys used to define Username/Password authentication.
Listing 7-5
WLE Keys for Username/Password Authentication
... Listing 7-6 includes the WLE keys used to define certificate-based authentication.
Listing 7-6
WLE Keys for Certificate-Based Authentication
... To access a WLE EJB using JNDI, you establish an InitialContext using the following code:
Context ctx = new InitialContext(env); Specifying env
as com.beasys.com.jndi.WLEInitialContextFactory
. After the context is created, the client application has access to bean homes in the WLE domain using WLE as the name service provider.
A WLE EJB is implicitly associated with the security context specified when the WLEContext
object is created. To specify a new security context, the EJB needs to close the current security context and establish a new security context with new security attributes. Use the following code to close the current security context:
ctx.close(); Client applications use the bean's home interface to create or find beans. The beans's home is obtained by using the lookup
method on the InitialContext.
Use the getCallerPrincipal
method on the javax.ejb.EJBContext
associated with a WLE EJB to authenticate the principal. You can also use the isCallerInRole
method to determine the role of the client application invoking methods on the EJB. The default principal is IIOP Client
.
It is possible to deploy the same EJB more than once with different deployment descriptors that set different access control policies. In this case access control is based on the deployment descriptor from which a particular bean is loaded. Security policies are not considered when the WLE system has a choice of how to route a request to any particular bean or container.
Listing 7-7 illustrates using Username/Password authentication in a WLE EJB.
Note:
The code example in Listing 7-7 uses the corbalocs
URL address format so that the SSL protocol is used to protect the integrity of the communications.
Listing 7-7
Username/Password Authentication in a WLE EJB
static public Context getInitialContext() throws Exception { Listing 7-8 illustrates using certificate-based authentication in a WLE EJB.
Listing 7-8
Certificate-based Authentication in a WLE EJB
...
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "corbalocs://"myhost:1000")
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.beasys.jndi.WLEInitialContextFactory");
//Password-Based Authentication
env.put(WLEContext.SECURITY_PRINCIPAL, "milozzi");
env.put(WLEContext.SYSTEM_CREDENTIALS, "mypassword");
env.put(WLEContext.CLIENT_NAME, "writers");
env.put(WLEContext.SECURITY_AUTHENTICATION, "simple");
env.put(WLEContext.SYSTEM_PASSWORD, "password");
...
//Certificate-Based Authentication
env.put(WLEContext.SECURITY_AUTHENTICATION, "strong");
env.put(WLEContext.SYSTEM_PASSWORD, "SSL");
env.put(WLEContext.SECURITY_PRINCIPAL, "milozzi");
env.put(WLEContext.SECURITY_CREDENTIALS, "credentials");
...Step 4: Establish the InitialContext.
Step 5: Use Home to get a WLE EJB.
Step 6: Use the getCallerPrincipal Method to authenticate a WLE EJB.
Limitations and Restrictions
Example of Using Security in a WLE EJB
Hashtable env = new Hashtable ();
env.put(WLEContext.INITIAL_CONTEXT_FACTORY,
"com.beasys.jndi.WLEInitialContextFactory");
env.put(WLEContext.PROVIDER_URL, corbalocs://myhost:7002);
return new InitialContext(env);
//Password-Based Authentication
env.put(WLEContext.SECURITY_AUTHENTICATION, "simple");
env.put(WLEContext.SYSTEM_PASSWORD, "RMI");
env.put(WLEContext.SECURITY_PRINCIPAL, "milozzi);
env.put(WLEContext.CLIENT_NAME, "writers);
env.put(WLEContext.SECURITY_CREDENTIALS, "password");
Hashtable env = new Hashtable ();
env.put(WLEContext.INITIAL_CONTEXT_FACTORY,
"com.beasys.jndi.WLEInitialContextFactory");
env.put(WLEContext.PROVIDER_URL, corbalocs://myhost:7002);
return new InitialContext(env);
//Certificate-Based Authentication
env.put(WLEContext.SECURITY_AUTHENTICATION, "strong");
env.put(WLEContext.SECURITY_PRINCIPAL, "milozzi@bigcompany.com");
env.put(WLEContext.CLIENT_NAME, "writers);
env.put(WLEContext.SYSTEM_PASSWORD, "SSL");
env.put(WLEContext.SECURITY_CREDENTIALS, "credentials");
|
|
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|