Develop stand-alone custom registries

This development provides considerable flexibility in adapting WAS security to various environments where some notion of a user registry, other than LDAP or Local OS, already exists in the operational environment.

WAS security supports the use of stand-alone custom registries in addition to the local operating system registry, stand-alone Lightweight Directory Access Protocol (LDAP) registries, and federated repositories for authentication and authorization purposes. A stand-alone custom-implemented registry uses the UserRegistry Java interface as provided by WebSphere Application Server. A stand-alone custom-implemented registry can support virtually any type or notion of an accounts repository from a relational database, flat file, and so on.

Implement a stand-alone custom registry is a software development effort. Implement the methods defined in the com.ibm.websphere.security.UserRegistry interface to make calls to the appropriate registry to obtain user and group information. The interface defines a general set of methods for encapsulating a wide variety of registries. We can configure a stand-alone custom registry as the selected repository when configuring WAS security on the Global security panel.

In WebSphere Application Server v8.5, make sure that your implementation of the stand-alone custom registry does not depend on any WebSphere Application Server components such as data sources, EJB and JNDI. We can not have this dependency because security is initialized and enabled prior to most of the other WebSphere Application Server components during startup. If the previous implementation used these components, make a change that eliminates the dependency. For example, if the previous implementation used data sources to connect to a database, instead use the JDBC java.sql.DriverManager interface to connect to the database.

(zos) Note: The user registry is used in controllers and servants. There is an increased risk of integrity exposure in that configuration if the registry implementation is not secured.

If the previous implementation uses data sources to connect to a database, change the implementation to use Java database connectivity (JDBC) connections.

1. Implement all the methods in the interface except for the CreateCredential method, which is implemented by WebSphere Application Server. FileRegistrySample.java file is provided for reference.

   The sample provided is intended to familiarize you with this feature. Do not use this sample in an actual production environment.

2. Build the implementation.

   (dist)(zos) To compile the code, we need the app_server_root/plugins/com.ibm.ws.runtime.jar and the app_server_root/plugins/com.ibm.ws.security.crypto.jar files in the class path. For example:
   

   app_server_root/java/bin/javac -classpath  app_server_root/plugins/com.ibm.ws.runtime.jar;
   app_server_root/plugins/com.ibm.ws.security.crypto.jar your_implementation_file.java

   
   

   (zos)

   app_server_root\java\bin\javac -classpath  app_server_root\plugins\com.ibm.ws.runtime.jar:
   app_server_root\plugins\com.ibm.ws.security.crypto.jar your_implementation_file.java

   (iseries) To compile the code, we need the com.ibm.ws.runtime.jar and the com.ibm.ws.security.crypto.jar files in our class path. For example:

   javac -extdirs app_server_root/java/ext:/QIBM/UserData/Java400/ext:
   /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/lib/ext:app_server_root/lib    -classpath app_server_root/plugins/com.ibm.ws.runtime.jar:  app_server_root/plugins/com.ibm.ws.security.crypto.jar   com/ibm/websphere/security/FileRegistrySample.java 

   The previous lines of code for the class path are one continuous line.

3. (iseries) Create a classes subdirectory in our profile for custom classes. For more information, see Create a classes subdirectory in the profile for custom classes.

   Create the classes subdirectory for each node in the cell.

4. Copy the class files that are generated in the previous step to the product class path.

   (dist)(zos) The preferred location is the following directory:

   • %install_root%/lib/ext

   • (zos) %install_root%\lib\ext

   directory. Copy these class files to all of the product process class paths.

   (iseries) The preferred location is the app_server_root\classes directory. For more information, see Create a classes subdirectory in the profile for custom classes. Copy the class files to all the product process class paths including the cell, all of the node agents.

5. To configure the implementation using the console, follow the steps in topics about configuring stand-alone custom registries. This step is required to implement custom user registries.

Example

View stand-alone custom registries.

Use these links to view registry examples.

A stand-alone custom registry is a customer-implemented registry that implements the UserRegistry Java interface, as provided by WebSphere Application Server. A custom-implemented registry can support virtually any type or form of an accounts repository from a relational database, flat file, and so on. The custom registry provides considerable flexibility in adapting WAS security to various environments where some form of a registry, other than a federated repository, LDAP registry, or local operating system registry, already exist in the operational environment.

To view a sample stand-alone custom registry, refer to the following files:

• FileRegistrySample.java file

• users.props file

• groups.props file

What to do next

If we enable security, complete the remaining steps:

1. Save and synchronize the configuration and restart all of the servers.

2. Try accessing some J2EE resources to verify that the custom registry implementation is correct.

Subtopics

• (iseries) Create a classes subdirectory in the profile for custom classes
  We can create a classes subdirectory in the profile in which we can place the custom security components.

• Result.java file
  This module is used by user registries in WebSphere Application Server when calling the getUsers and getGroups methods. The user registries use this method to set the list of users and groups and to indicate if more users and groups in the user registry exist than requested.

• UserRegistry.java files
  The following file is a custom property used with a custom user registry.

Related tasks

Develop extensions to the WebSphere security infrastructure

(zos) Use a DB2 database to hold custom user registry data

Configure stand-alone custom registries

UserRegistry.java files

FileRegistrySample.java file

Stand-alone custom registry settings

users.props file

groups.props file