Using WebLogic Server JNDI for Application Client Security

WebLogic Server implements JNDI security for both authentication and authorization. As you recall from Chapter 6, the JNDI naming tree is replicated across the entire cluster of WebLogic Server instances. This makes it ideal as a security-context tracking mechanism. Virtually every service in WebLogic Server is registered in the JNDI naming tree. ACLs are defined in the WebLogic Server console and stored in the WebLogic Server realm. These ACLs determine what principals (users or groups) are allowed access to given resources.

JNDI authentication and authorization in WebLogic Server security realms works by allowing application clients to do lookups into the JNDI tree to find objects to be accessed. These lookups are permission-based, so those clients that are not permitted to access objects do not receive references to them. The JNDI lookup with the security information is done when the client is attempting to locate an InitialContext, as described in Chapter 6.

WebLogic Server JNDI-Based Authentication

WebLogic Server JNDI-based authentication uses WebLogic Server JNDI as the access point for resources. An application client wanting to access a JMS destination does a lookup into the naming tree in JNDI to gain an initial context for the application. The user provides security information during the initial context lookup. WebLogic Server JNDI security validates that information and provides an initial context with the correct security settings.

Using Password-Based Authentication with the WebLogic Server Realm

Previous chapters discussed resource access using EJB and JMS. For example, Chapter 8's Hello World EJB included the following code as part of the client access to the EJB:

Context ctx = new InitialContext();
      HelloWorldHome home = (HelloWorld)
            PortableRemoteObject.narrow(
ctx.lookup("HelloWorldEJB", HelloWorld.class));

In this code, the first call generates a new Context object using the JNDI initial context. Because no user or environment is specified as a parameter to InitialContext, the current user name is used for security checks. Most real-world Web applications handle all security at the Web application layer. If a user has not logged in to a Web application, the subsequent code relying upon EJB or other resources is executed on security as the “guest” user. If the user has logged in, the subsequent code relying upon EJB and other resources is executed on behalf of that user.

In real-world application client deployments, there is no Web layer for authentication. So, you would need to do a lookup into JNDI securely. To add security to a JNDI lookup, you must change the properties when generating the InitialContext. Pass these parameters as a HashTable object to the constructor for the Context object.

Initial Context Properties

Five properties can be changed when generating an initial context. The following summarizes these properties and their possible values:

• INITIAL_CONTEXT_FACTORY, which provides an entry point into the WebLogic Server environment. The weblogic.jndi.WLInitialContextFactory class provides the JNDI services for WebLogic Server.

• PROVIDER_URL, which specifies the host and post of WebLogic Server. For example: t3://my.weblogic.com.7001.

• SECURITY_AUTHENTICATION, which indicates the types of authentication to be used. The valid values for the property are as follows:

  • None indicates that no authentication is performed.

  • Simple indicates that password authentication is performed.

  • Strong indicates that digital certificate authentication is performed.

• SECURITY_PRINCIPAL, which specifies the identity of the principal used when authenticating the caller to the WebLogic Server realm.

• SECURITY_CREDENTIALS, which specifies the credentials of the principal when authenticating the caller to the WebLogic Server realm.

  • For password authentication enabled via SECURITY_AUTHENTICATION="simple", it specifies a string that is the user's password or an arbitrary object User used by WebLogic Server to verify the credentials of the principal.

  • For certificate authentication enabled via SECURITY_AUTHENTICATION="strong", it specifies the name of the X509 object that contains the digital certificate and private key for the WebLogic Server. Subsequent sections discuss the use of digital certificate–based authentication.

Using Initial Context Properties for Login

The following code generates an initial context that uses properties for the initial context login instead of the guest user:

Hashtable env = new Hashtable();

env.put(Context.INITIAL_CONTEXT_FACTORY,
     "weblogic.jndi.WLInitialContextFactory");
     env.put(WLContext.PROVIDER_URL, "t3://
my.weblogic.com:7001");
     env.put(WLContext.SECURITY_AUTHENTICATION "simple");
     env.put(Context.SECURITY_PRINCIPAL, "myusername");
     env.put(Context.SECURITY_CREDENTIALS, "mypassword");

      ctx = new InitialContext(env);

This replaces the following:

ctx = new InitialContext();

Instead of attempting to log in using the guest user name, the application attempts to log in with a user name and password in the WebLogic Server realm. It gets that initial context from the server deployment located at my.weblogic.com on port 7001.

After using these properties for login, all subsequent actions using the initial context object ctx are accomplished under the user myusername with all the permissions associated with it as configured in the WebLogic Server console.

Example: Secure Application Client Using EJB

In this section, we create a sample stateless session EJB that uses JNDI security and programmatic security. In this EJB, programmatic security is demonstrated as well as declarative security. This EJB is called SecureBean.

To implement declarative security in EJB, use the same techniques as used in securing Web applications. All access is restricted by configuration information in the EJB deployment descriptor. First, create the EJB deployment descriptor, ejb-jar.xml:

<?xml version="1.0"?>

<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enter-
prise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-
jar_2_0.dtd">
<ejb-jar>
  <enterprise-beans>
    <session>
      <ejb-name>SecureEJB</ejb-name>
      <home>chapter12.SecureHome</home>
      <remote>chapter12.Secure</remote>
      <ejb-class>chapter12.SecureBean</ejb-class>
      <session-type>Stateful</session-type>
      <transaction-type>Container</transaction-type>

      <security-role-ref>
        <description>Administrator role</description>
      <role-name>Administrator</role-name>
      </security-role-ref>

    </session>

  </enterprise-beans>

  <assembly-descriptor>

    <security-role>
      <description>
        Administrator role used to demonstrate EJB security.
      </description>
      <role-name>Administrator</role-name>
    </security-role>

    <method-permission>
      <role-name>Administrator</role-name>
      <method>
        <ejb-name>SecureEJB</ejb-name>
      <method-name>onlyAdministrators</method-name>
      </method>
    </method-permission>

  </assembly-descriptor>

</ejb-jar>

Note that this EJB deployment descriptor has a new section not discussed in the previous EJB chapters. It includes an <assembly-descriptor> tag, which has nested inside it a definition of a security role called Administrator. Next, permissions on the EJB method named onlyAdministrators are set for users in the role of Administrator.

weblogic-ejb-jar.xml

As with Web applications, we still need to define a WebLogic Server–specific deployment descriptor that maps the role defined for this EJB to the principal in the WebLogic Server realm (the user or the group). The following weblogic-ejb-jar.xml file defines a principal named Bob, who matches the Administrator role defined for the EJB:

<?xml version="1.0"?>

<!DOCTYPE weblogic-ejb-jar PUBLIC
"-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN"
"http://www.bea.com/servers/wlserver6.0/dtd/weblogic-ejb-
jar.dtd" >

<weblogic-ejb-jar>
  <weblogic-enterprise-bean>
    <ejb-name>SecureEJB</ejb-name>

    <jndi-name>secureHome</jndi-name>
  </weblogic-enterprise-bean>

  <security-role-assignment>
    <role-name>Administrator</role-name>
    <principal-name>Bob</principal-name>
  </security-role-assignment>

</weblogic-ejb-jar>

SecureBean.java

In the EJB implementation, the protected method is defined:

private SessionContext ctx;

public void onlyAdministrators() {

    System.err.println("onlyAdministrators was called by:
"+ctx.getCallerPrincipal());

    if (ctx.isCallerInRole("Administrator")) {
      System.err.println("Only admins are allowed in this
method.");
    } else {
      System.err.println("User: "+ctx.getCallerPrincipal()+
        " was not in the Administrator role.");
      System.err.println("This indicates the security con-
straints"
        + " are not correct in the ejb-jar.xml.");
    }
  }

Note that the EJB includes a set of programmatic security APIs similar to those for Web application security. These APIs refer to the SessionContext instead of the HTTP request object:

• getCallerPrincipal obtains java.security.Principal and returns the Principal object that identifies the caller. This method never returns null.

• Boolean isCallerInRole(java.lang.String roleName)tests whether the caller has a given security role. The role must be one of the security roles that is defined in the deployment descriptor (true if the caller has the specified role).

Notice that there is no method to acquire the user name in programmatic EJB security. It is not required because there is no notion of explicitly defined users as in the Web application model.

In the second part of the SecureBean, a method is added that demonstrates the usefulness of programmatic security. In this case, it is not possible to recognize the owner of an EJB instance in advance: The owner can only be determined dynamically, at runtime. So you develop a method that can only be called by the user, who owns the EJB instance:

public void onlyUser() throws RemoteException {

  Principal caller = ctx.getCallerPrincipal();

  System.err.println("onlyUser was called by: "+ caller);

  if (! caller.getName().equals(userName)) {
    String notAllowedMsg = "User : "+caller.getName() +
      " cannot call the onlyUser method on " +
      userName + "'s Secure bean.";

    System.err.println(notAllowedMsg);

    throw new RemoteException(notAllowedMsg);
  }

Deploying the Secured EJB Client

The Secured EJB Client Example resides in the directory named examplesch12, in the file named SecureBean.jar.

c:eawlserver6.0configmydomainsetEnv.cmd

"java -classpath Secure.jar;%CLASSPATH%chapter12.SecureClient
t3://127.0.0.1:7001".

The last entry is the host name and port number for your WebLogic Server instance. After the client runs, you should see that Bob and Michelle were able to access resources inside of the EJB (see Figure 12-26).