In the first case, you add functionality to the realm's authorization service, without affecting the realm's authentication service or the implementation of any of the realm's objects. The second case allows you to replace all or part of the realm's authentication or authorization services with your own implementation. The two techniques can also be combined.

WebLogic security classes

Realm classes

During startup, WebLogic Server initializes the realm it uses for authentication and authorization. The weblogic.security.realmClass property specifies the realm class to use. It defaults to weblogic.security.acl.WLPropertyRealm. WebLogic Server loads the realm class and makes it available through the weblogic.security.acl.Security class. The weblogic.security.acl.Security methods can only be executed in the WebLogic Server's VM.

WebLogic provides three realm interfaces:

weblogic.security.acl.BasicRealm

The BasicRealm interface has methods that load and initialize the realm and retrieve objects (such as Users, Groups, Permissions, and ACLs) from the realm.

weblogic.security.acl.ListableRealm

The ListableRealm interface extends BasicRealm, adding methods to retrieve Enumerations of Users, Groups, ACLs, and Permissions from the realm.

weblogic.security.acl.ManageableRealm

The ManageableRealm interface extends ListableRealm. It adds methods to create new Users, Groups, ACLs, and Permissions; delete Users, Groups, ACLs; and set or unset a Permission for a User or Group on an ACL.

WLPropertyRealm implements the ListableRealm interface and extends weblogic.security.acl.DefaultRealmImpl, a ManageableRealm. When the WebLogic Server starts, it uses the ManageableRealm methods provided by DefaultRealmImpl to create Users, Groups, Permissions, and ACLs as they are read from the weblogic.properties file.

User and Group classes

JDK 1.1 provides classes and interfaces to describe users and groups of users. The

weblogic.security.acl.User

java.security.acl.Group

weblogic.security.acl.User and java.security.acl.Group both extend java.security.Identity, which implements the java.security.Principal interface. Some weblogic.security.acl methods take a Principal argument, which can be satisfied with either a User or Group. For example, you can add a User or a Group to a Group, or you can set a permission for a User or Group.

The Java 1.1 java.security.Identity class represents an entity with a name and a public key. However, weblogic.security.acl.User is implemented with a name and a credential, which could be any Object that can be used for authentication in the realm, such as a password, certificate, or certificate token.

WebLogic Server depends upon the special users "system" and "guest," and the special group "everyone." You must define a password for the "system" user in the weblogic.properties file using the weblogic.password.system property, even if you substitute a custom realm for WLPropertyRealm.

The default WLPropertyRealm creates User "guest" (with password "guest") and Group "everyone" at startup. If you substitute your own realm for authentication, that realm must supply the "guest" User and the "everyone" Group and every User must be a member of the "everyone" Group. The realm must also supply a "system" User (in addition to the "system" User defined in the weblogic.properties file), and that "system" User must also be a member of the "everyone" Group, which ensures that the "system" User also receives permissions granted to "everyone."

Permission class

The weblogic.security.acl.PermissionImpl class implements the java.security.acl.Permission interface. A Permission is some right that can be granted to a user such as "execute," "read," or "lookup" Permission.

A Permission can be positive or negative. The default WLPropertyRealm supports only positive Permissions. Because of this limitation, in the WLPropertyRealm you cannot grant a Permission to a Group and then revoke the Permission from individual Users in that Group. A custom realm, however, could support negative Permissions.

When you use the WLPropertyRealm for authorization, WebLogic Server creates Permissions as it parses weblogic.allow properties in the weblogic.properties file. If you substitute a custom realm for authorization, that realm must create Permissions. For example, the RdbmsRealm creates Permissions from the rows it retrieves from the aclentries database table.

ACL classes

JDK 1.1 supplies the java.security.acl.Acl interface and the java.security.acl.AclEntry interface. WebLogic implements these interfaces with the weblogic.security.acl.AclImpl and weblogic.security.acl.AclEntryImpl classes.

An Acl is a data structure that contains multiple AclEntries. An Acl has a name, which is generally a reference to the resource the Acl protects. Each Acl is created with an owner, a Principal (User or Group), that must be supplied when altering the Acl, for example, adding or removing AclEntries.

An AclEntry contains a Principal (a User or Group) and an array of Permissions. The class provides methods to add and remove Permissions, check for the presence of a Permission, and change a positive Permission to a negative Permission.

Only the owner of an Acl can add an AclEntry to the Acl.

How WebLogic Server authenticates

If a connecting client provides a username and credential, WebLogic Server passes them to the realm for authentication. If the realm cannot authenticate the user, WebLogic Server refuses the request. If the realm successfully authenticates the user, it returns a weblogic.security.acl.User object, which is then associated with thread that created the JNDI context. For more information see Associating a principle with a thread.

If a connecting client does not provide a username and credential on a connection request, WebLogic Server uses the "guest" user for authorization. If the user requests an HTTP servlet protected with an Acl, the web browser prompts the user for a username and credential. If the realm authenticates the user's entry, the authenticated User replaces the "guest" user on the connection.

A Java application can specify a username and credential when establishing the connection. If it does not, then the "guest" user is associated with the connection.

IV. Implementing with the WebLogic ACL API

Using custom permissions

Writing a custom realm

Writing a realm that extends the default WebLogic Realm

Writing a realm using DefaultRealmExtender

The RdbmsRealm example

Using custom permissions

You can design your own ACL names and permissions and access them from your applications. If you use the default WLPropertyRealm realm, just define your ACLs in the weblogic.properties file and then test Permission at runtime using a few methods in the weblogic.security.acl package. If you are using a different realm for authorization, you define your ACLs in the way that is appropriate for that realm. For example, if you use the RdbmsRealm, you add ACLs to the ACLs table in the realm's database.

In an application, you can call Security.checkPermission() to test for a permission in the WebLogic realm. As with all realm operations, the test can only be performed in a class executing in the WebLogic Server. The weblogic.security.acl.Security.hasPermission() and weblogic.security.acl.Security.checkPermission() methods test whether a user has a given permission. The methods are similar, except that the hasPermission() method returns a boolean (true if the user has the permission) and the checkPermission method throws a java.lang.SecurityException if the user does not have the permission.

The examples.security.acl example demonstrates how to create your own permissions and test them in a server-side application. It is a simple example that demonstrates how to protect an RMI object with a custom ACL. (Find out more about WebLogic RMI and remote method invocation in Using WebLogic RMI.) This section describes how the examples.security.acl example uses the WebLogic ACL API. See Package-examples.security.acl for instructions on setting up and running the example.

The weblogic.security.acl example has three classes/interfaces:

Interface Frobable, which extends Remote.

This interface defines one method, frob().

Class FrobImpl, which implements Frobable.

The implementation of the frob() method checks the "aclexample" ACL to determine if the user has "frob" permission. If the permission is found, frob() prints a success message. If the user does not have "frob" permission, the method throws a java.lang.SecurityException.

Class Client.

Client is a standalone Java application that attempts to invoke the frob() method remotely. Although no security code is required in a client application, this example shows how to specify the username and password when connecting to the WebLogic Server.

The example uses a custom ACL, "aclexample" with the permission "frob". Using the default WebLogic realm, you create the ACL by adding the following property to the weblogic.properties file:

  weblogic.allow.frob.aclexample=list

Replace list with a comma-separated list of users or groups, which must also be defined in the weblogic.properties file.

When WebLogic Server starts up, it parses this property and does the following:

• Creates an Acl with the name "aclexample"
• Creates a "frob" Permission
• Creates an AclEntry for each User or Group listed in the property and adds the "frob" Permission to it
• Adds each AclEntry to the "aclexample" Acl

FrobImpl class

The FrobImpl class contains the code that runs in the WebLogic Server and calls into the realm to check the "aclexample" Acl. The class shows two methods for testing a permission. The first method uses a static method in theweblogic.security.acl.Security class:

  Security.checkPermission(Security.getCurrentUser(),
          "aclexample", 
          Security.getRealm().getPermission("frob"), 
          '.');

The weblogic.security.acl.Security class provides access to the WebLogic realm. This is WLPropertyRealm if you have not substituted a custom realm. If you have specified a custom realm with the weblogic.security.realmClass property, the Security class provides access to that realm.

You could also instantiate a realm in the WebLogic Server that does not replace the default realm. In this case, you cannot use the Security class, since it only provides access to the WebLogic realm. The second method for checking permission illustrated by the FrobImpl example gets a realm by name, retrieves an Acl from that realm, and then tests for permission with the acl.checkPermission() method:

  User p = Security.getCurrentUser();
  BasicRealm realm = Realm.getRealm("weblogic");
  Acl acl = realm.getAcl("aclexample");
  if (acl == null || 
     !acl.checkPermission(p, realm.getPermission("frob"))) {
     Security.logAndThrow("Permission \"frob\" denied " +
                  "for user \"" + p + ".\"");
    }

When you check permission in a realm other than the WebLogic realm, you must test a User from that same realm. Since this example uses the WebLogic realm, it retrieves the current user on the thread with Security.getCurrentUser(). Also, it uses the Security.logAndThrow() method, a convenience method that writes a message to the log and throws a java.lang.SecurityException.

Client class

The examples.security.acl.Client class creates a connection to the WebLogic Server and attempts to execute the frob() method. The permission-checking is performed in the server-side code. Client does not have to provide any security-related code other than providing the username and password needed for authentication.

The client program takes three command-line arguments: an URL for the WebLogic Server, a username, and a password. These arguments are placed in the Hashtable used to get a JNDI context from the WebLogic Server. Here is the code that gets a JNDI context, looks up the "frobtarget" RMI object, and then executes the frob() method:

  Context ctx = null;
  try {
    //  Set up a Hashtable and get a JNDI context
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY,
            "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.PROVIDER_URL,         arg[0]);
    env.put(Context.SECURITY_PRINCIPAL,   arg[1]);
    env.put(Context.SECURITY_CREDENTIALS, arg[2]);

    //  RMI lookup on the remote object
    ctx = new InitialContext(env);
    Frobable f = (Frobable) ctx.lookup("frobtarget");
    // Can this user get access to the "frob" method?
    f.frob();
    System.out.println("Frobbed successfully");
  }
  // If not, this client-side code throws an exception
  catch (Throwable t) {
    t.printStackTrace();
    System.out.println("Failed to frob");
  }
  finally {
    try (ctx.close()}
    catch (Exception e) {
      // Deal with any failure
    }
  }

Writing a custom realm

You can create your own security realm, perhaps to take advantage of an existing store of users, such as a directory server on the network. You can substitute your custom realm for the default WebLogic realm by setting the weblogic.security.realmClass property to the name of your realm class in the weblogic.properties file. When the WebLogic Server starts up, it initializes your realm and uses it for all authentication and authorization requests. Your realm then becomes the WebLogic realm.

Alternatively, you could install a custom realm as a startup class so that it is an additional realm available to specific applications that are written to use it. The additional realm has no effect on basic WebLogic Server authentication and authorization, but allows applications to perform authentication and authorization in a separate domain.

To create a custom realm for the WebLogic realm, you can either extend the WLPropertyRealm, or build a new realm by implementing a realm interface and the User, Group, Permission, Acl, and AclEntry interfaces.

A custom realm to replace WLPropertyRealm should implement ManageableRealm, which allows the realm to create and destroy Users, Groups, Permissions and Acls. The realm methods that you implement include all methods from all three realm interfaces, BasicRealm, ListableRealm, and ManageableRealm:

1. Methods to initialize, load, save, and get the name of a realm.
2. A method to get the Principal who controls the realm.
3. Methods to create, get, and delete users in the realm.
4. Methods to create, get, and delete groups in the realm.
5. Methods to create, get, and delete ACLs in the realm.
6. Methods to create, get, and set permissions in the realm.

Your custom realm design should consider these issues:

• The WLPropertyRealm provides some User and Group defaults upon which WebLogic Server depends. WLPropertyRealm creates the "guest" user and the "everyone" group when it initializes. The "guest" user is required, since WebLogic Server uses "guest" for authorization when a client does not provide a username and credential for authentication.

  Within WLPropertyRealm, The "everyone" group automatically contains every user. If you extend WLPropertyRealm and provide your own User and Group implementations, you lose automatic membership in the "everyone" group unless you implement it yourself. The LDAPRealm, for example, does nothing special for the "everyone" group, so using that realm requires that the LDAP server provide an "everyone" group that includes every user. A "system" user must also be created in the LDAP server and added to the "everyone" group because the "system" user obtains some of the rights it needs by virtue of its membership in the "everyone" group.

  The DynamicUserAcl interface extends BasicRealm to provide a method that is used to grant "write" permission to a user who creates a Workspace. WLPropertyRealm implements this interface, as must any realm that replaces the WebLogic realm.

  The DefaultRealmExtender example is designed to provide these default behaviors and to provide a framework to more easily implement a custom realm.

• Authentication and authorization operations are numerous in the WebLogic Server. You should provide a mechanism for caching Users, Groups, and Acls (if your realm provides them) to avoid expensive calls into your external service. If you cache these objects indefinitely, however, you will have to restart the WebLogic Server to reflect changes made in the external store.

  The RdbmsRealm example includes a CacheableRealm to demonstrate how realm objects can be stored in a LRU cache. The LDAPRealm uses Enterprise JavaBeans to store realm objects, taking advantage of the EJB framework in the WebLogic Server.

• Although the weblogic.security.acl class implements negative Permissions, WLPropertyRealm does not use them, and they have not been been tested in the WebLogic Server. Therefore, using negative Permissions in the WebLogic Server is not currently supported.

• Most custom realms retrieve user, group, permission, and ACL objects from an external system such as a database or directory server. Be sure to consider the costs of connecting to that system in your design. If you connect just once, when the realm initializes, the only way to recover a failed connection between the realm and the external system is to restart the WebLogic Server. But establishing a TCP/IP connection for every access to the system could have a drastic effect on performance. A good solution is to connect just once and leave the connection open, but provide code to detect and recover from a failed connection. If the external system can be accessed with a JDBC driver, you can use a JDBC connection pool, which you can configure to detect and refresh stale connections automatically.

• If your realm implements ACLs, be sure to examine all of the ACLs (properties that begin with "weblogic.allow") in the weblogic.properties file and add them to your realm.

Writing a realm that extends the default WebLogic realm

Your realm can extend the default WebLogic realm, and delegate to WLPropertyRealm as appropriate. This is useful if you want to continue to use the weblogic.properties file for some of the realm's source data. For example, you could override methods that retrieve Users, but continue to define Groups and ACLs in the weblogic.properties file.

You then install your realm in the WebLogic Server by adding the following property to the weblogic.properties file:

weblogic.security.realmClass=myRealmClass

myRealmClass

The full package name of your compiled realm class, which must be in the WebLogic Server's CLASSPATH.

The LDAPRealm is an example of a realm that extends WLPropertyRealm. LDAPRealm uses an LDAP server (such as Netscape Directory Server or Microsoft Site Server) for authentication, but depends on the WLPropertyRealm for authorization (ACLs). It overrides WLPropertyRealm methods that look up Users and Groups and authenticate Users. It uses EJBs to cache User and Group objects to avoid redundant calls to the LDAP server.

Writing a realm using DefaultRealmExtender

The DefaultRealmExtender example is a realm implementation that makes it easier to develop custom realms. DefaultRealmExtender delegates to an underlying realm that you provide. If your realm does not provide certain objects the WebLogic Server requires, DefaultRealmExtender provides them.

DefaultRealmExtender:

• Provides the users "guest" and "system" if they are absent from the underlying realm. It creates "guest" with password "guest", and "system" with password "system", although you could change these in the code.

• Provides the group "everyone" if it is absent from the underlying realm.

• Allows getPermission() to create temporary new Permissions, if necessary.

• Provides the following ACLs and Permissions, if they are not provided by the underlying realm:

  weblogic.admin	"shutdown", "lockServer", and "unlockServer" permissions for "system" user.
  managedObject	"read" and "write" permissions for "system" user.
  weblogic.workspace	"read" and "write" permission for "system" user.

• Implements the DynamicUserAcl interface that dynamically creates an ACL on a Workspace with "read" and "write" permissions for the creator of the Workspace.

Before DefaultRealmExtender creates an object, it first requests that object from the underlying realm. Therefore, the underlying realm, which you provide, always has precedence over DefaultRealmExtender.

RdbmsRealm example

Implementing RdbmsRealm

RdbmsUser and RdbmsUserInfo implementations

Group implementation

Permission, ACL, and ACLEntry implementations

ListableRealm methods

The RdbmsRealm example shows how to develop a database-based realm using DefaultRealmExtender. The examples.security.rdbmsrealm package also includes CachingRealm, a realm that implements a LRU cache for Users, Groups, Permissions, and ACLs.

RdbmsRealm

Retrieves Users, Groups, and ACLs from a relational database. Since the database tables are maintained outside of the WebLogic Server, the realm is dynamic. Users, Groups, and ACLs can be altered without restarting WebLogic Server.

CachingRealm

Saves User, Group, Acl, and Permission objects in cache. Both DefaultRealmExtender and RdbmsRealm can retrieve objects from the cache. DefaultRealmExtender delegates to CachingRealm, CachingRealm delegates to RdbmsRealm. RdbmsRealm can call back into CachingRealm.

Here is how the delegation chain is established:

1. The WebLogic realm is set to DefaultRealmExtender by setting a property in the weblogic.properties file:

     weblogic.security.realmClass=\
         examples.security.DefaultRealmExtender

2. In DefaultRealmExtender.java, the String variable delegateClassName is explicitly set to the CachingRealm class:

     delegateClassName =
         "examples.security.rdbmsrealm.CachingRealm";

   DefaultRealmExtender loads the class:

     realm = (ListableRealm) 
       Class.forName(delegateClassName).newInstance();

   Thereafter, DefaultRealmExtender calls methods of the CachingRealm class for all WebLogic realm operations.

3. CachingRealm uses a property, cachedRealmImpl, to find the final realm implementation. The CachingRealm.init() method tries to load the CachingRealm.realm_properties property file. This file can contain the following properties:

   userCacheSize=int

   The number of Users to cache. Default value is 20.

   groupCacheSize=int

   The number of Groups to cache. Default is 10.

   aclCacheSize=int

   The number of ACLs to cache. Default is 20.

   permissionCacheSize=int

   The number of permissions to cache. Default is 0.

   cachedRealmImpl=classname

   The name of the realm implementation to cache. Default is examples.security.rdbmsrealm.RdbmsRealm.

   If it finds a properties file, CachingRealm uses its values to create LRUTables (cache) for Users, Groups, ACLs and Permissions. It creates an instance of the realm specified with the cachedRealmImpl property. Thereafter, it calls RdbmsRealm to load its cache, and it serves requests from DefaultRealmExtender from its cache.

4. CachingRealm and RdbmsRealm both implement the CacheableRealm interface so that RdbmsRealm can look for objects in the cache maintained by CachingRealm before going to the database. The CacheableRealm interface defines setCache() and getCache() methods. Before calling the RdbmsRealm.init() method, CachingRealm calls RdbmsRealm.setCache(), which allows RdbmsRealm to save a handle to the CachingRealm instance.

See the instructions for the RdbmsRealm and DefaultRealmExtender examples for help with setting up the RdbmsRealm example.

Implementing RdbmsRealm

DefaultRealmExtender and CachingRealm are "helper" realms that pass requests through to RdbmsRealm. RdbmsRealm performs the actual work of the realm, so this section focuses on the implementation of RdbmsRealm.

To create a new realm, you implement one of the realm interfaces and any additional classes needed for Users, Groups, ACLs, and Permissions.

RdbmsRealm implements the weblogic.security.acl.ListableRealm interface and the CacheableRealm interface. It also provides an RdbmsUser class and an RdbmsUserInfo class. It uses standard WebLogic implementations for Group, Permission, Acl, and AclEntry. The RdbmsUser and RdbmsUserInfo class extend existing User and UserInfo classes, so the work of implementing the realm is nearly confined to retrieving data from the database with JDBC and creating objects.

RdbmsUser and RdbmsUserInfo implementations

The class examples.security.rdbmsrealm.RdbmsUser extends weblogic.security.acl.User, which extends java.security.Identity. RdbmsUser adds realm and password variables, which are initialized in the constructor:

class RdbmsUser extends User {

  private BasicRealm realm;
  private String password;

  RdbmsUser(String name, String password, BasicRealm r) {
    super(name);
    this.password = password;
    realm = r;
  }

An RdbmsUser is created in the RdbmsRealm from data retrieved from the database by an SQL query. In the RdbmsRealm.newRdbmsUser() method, the username and password are passed directly from the JDBC ResultSet to the RdbmsUser constructor:

  protected User newRdbmsUser(ResultSet rs) throws SQLException {
    return new RdbmsUser(rs.getString(1), rs.getString(2), this);
  }

The RdbmsUser.getCredential() method returns null, to ensure that the user's password is kept private. If the credential were a public key or certificate, or even an encrypted password, this method could return the actual credential.

User authentication occurs when a client application connects to WebLogic Server. If the client is a browser, authentication may be postponed until the user attempts to access a servlet protected with an ACL. To authenticate a User, WebLogic Server creates a UserInfo instance containing the username and password from the client and passes this to the RdbmsRealm.getUser() method. The getUser() method loads a user, by name, from the database into an RdbmsUser. If the password in the UserInfo matches the password in the RdbmsUser, getUser() returns the (now authenticated) RdbmsUser. Otherwise, it returns null. When getUser() returns an authenticated user, WebLogic Server stores it in the client's execution context for use with subsequent authorizations.

RdbmsUserInfo implements the weblogic.security.acl.UserInfo interface. A UserInfo holds the username and credential (password, in this case) that a user provides for authentication. UserInfo is serializable so that it can be constructed on a remote client and passed to the WebLogic Server.

Group implementation

RdbmsRealm uses the weblogic.security.acl.GroupImpl class for groups. The realm methods that pertain to groups are:

• RdbmsRealm.getGroup(String)

  This BasicRealm method retrieves a group from the database by name.

• RdbmsRealm.getGroups()

  This ListableRealm method retrieves an Enumeration of all groups in the realm.

In the database, a group has a row for each group member. A group member can be either a user or another group. Since User and Group are both derived from Principal, Group is represented as a collection of Principals.

The getGroup() method executes a SQL query like this one:

  SELECT GN_GROUP, GM_MEMBER FROM groupmembers
    WHERE GM_GROUP = 'groupname'

The JDBC ResultSet from this query is processed by the newRdbmsGroup() method, which creates a new Group and then processes each row with a getPrincipal() call. The Group.addMember() method then adds the User or Group to the new Group.

Because Group members can be Groups, getGroup() can be called recursively and may trigger concurrent database queries. This circumstance has design implications for the JDBC portion of the RdbmsRealm code. Depending on the DBMS and the JDBC driver, you may need a new JDBC connection for each level of recursion.

Permission, ACL, and ACLEntry implementations

RdbmsRealm uses standard WebLogic implementations of Permission, ACL, and ACLEntry. The "aclentries" database table implements all three objects.

The RdbmsRealm.getAcl() method retrieves an Acl from the database by name. An Acl in the database may comprise many rows, each with Acl name, principal (user or group) name, and permission name columns. getAcl() passes the JDBC ResultSet to the RdbmsRealm.newRdbmsAcl() method to build the Acl. The newRdbmsAcl() method requires the ResultSet to be ordered on Principal. To construct and populate an Acl, it creates the Acl and then steps through the ResultSet, creating a new AclEntry whenever it encounters a new principal, and adding one permission to the current AclEntry for each database row.

WebLogic Server loads an Acl and calls its checkPermission() method to authorize a user's request. Since it uses the weblogic.security.acl.AclImpl class for ACLs, RdbmsRealm does not have to implement any special ACL-processing code.

ListableRealm methods

Implementing the ListableRealm interface is not required for authentication or authorization, but it adds useful administrative functionality to your realm. The WebLogic Console and the T3AdminRealm servlet, for example, use ListableRealm methods to retrieve and display Users, Groups, Permissions, and Acls.

The ListableRealm methods are getUsers(), getGroups(), getPermissions(), and getAcls(). These methods return Enumerations.

RdbmsRealm implements these methods with private classes UserEnumeration, GroupEnumeration, AclEnumeration, and PermissionEnumeration. These classes take a JDBC ResultSet as their argument and implement the Enumeration interface. CachingRealm delegates these methods directly to RdbmsRealm, so these methods go to the database on every call.

DefaultRealmExtender merges the default users and groups it provides with the JDBC ResultSet.

For example, RdbmsRealm.getUsers() creates a new UserEnumeration:

  /**
   * Returns an Enumeration of the users in a 
   * particular realm.
   */
  public Enumeration getUsers() {
    try {
      return new UserEnumeration(
        getUsersStmt.executeQuery(), this);
    }
    catch (SQLException e) {
      e.printStackTrace();
    }
    return null;
  }

The UserEnumeration class implements the hasMoreElements() and nextElement() methods with JDBC ResultSet methods.

Change history

Release 4.0.3

There have been no additional changes as of release 4.0.3.

Release 3.1

Created the access control list, weblogic.admin.acl, with permission change. This ACL controls a new member function of the ManageableRealm.setPermission() method.

Removed the class PrincipalImpl.

Release 3.0.1

Moved functionality that was originally in an internal class into weblogic.security.acl.Security.

Release 3.0

Added support for ACLs.

Release 2.5

Property file changes:

• weblogic.security.certificateCacheSize
  Added. For SSL (WebLogic Secure), limits the number of outstanding tokens cached for exchange for use with applets. For more information, see WebLogic Secure: Using SSL with WebLogic.
• weblogic.security.certificate.authority
  Made optional. For more information, see WebLogic Secure: Using SSL with WebLogic.

Changes:

• Improved error reporting for SSL configuration problems. Exceptions now say which property and property value resulted in an absent or invalid file.
• Made the certificate authority (CA) certificate optional. This corresponds to the property weblogic.security.certificate.authority in the weblogic.properties file, which you may comment out if you do not wish to set it. This is possible because browsers store the whole certificate of the CAs that it trusts. The issuer's name is part of the server certificate, but the public key of the issuer is not. It is still necessary to configure WebLogic Server with a CA certificate file when the CA is not widely recognized.
• Added a "certificate issuer" certificate for VeriSign SecureServer (SecureServerCA.der), which may be used -- if you acquire a certificate from VeriSign -- for the value of the property weblogic.security.certificate.authority. If you are using two-way authentication and wish to limit clients to those with certificates from VeriSign, you may also use this file for the value of the property weblogic.certificate.
• Added support for Privacy Enhanced Mail (PEM) certificates. The file name must end with .pem.

Release 2.4

Introduced support for Secure Socket Layer (SSL) for authenticating and encrypting communications between client and WebLogic. WebLogic's implementation, WebLogic Secure, supports two-way encryption and authentication for client applets and applications operating within WebLogic.