Developing standalone custom registries

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

Before you begin

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

Implementing a standalone custom registry is a software development effort. Implement the methods that are 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. You can configure a standalone custom registry as the selected repository when configuring WebSphere Application Server security on the Global security panel.

In WebSphere Application Server Version 7.0, make sure that your implementation of the standalone custom registry does not depend on any WebSphere Application Server components such as data sources, Enterprise JavaBeans™ (EJB) and Java Naming and Directory Interface (JNDI). You can not have this dependency because security is initialized and enabled prior to most of the other WebSphere Application Server components during startup. If your previous implementation used these components, make a change that eliminates the dependency. For example, if your previous implementation used data sources to connect to a database, instead use the JDBC java.sql.DriverManager interface to connect to the database.

Refer to the Migrating custom user registries for more information on migrating. If your previous implementation uses data sources to connect to a database, change the implementation to use Java database connectivity (JDBC) connections.

Procedure

  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.
    Attention: The sample provided is intended to familiarize you with this feature. Do not use this sample in an actual production environment.
  2. Build your implementation.
    To compile your code, you need the com.ibm.ws.runtime.jar and the com.ibm.ws.security.crypto.jar files in your class path. For example:
    javac -extdirs app_server_root\java\ext:\QIBM\UserData\Java400\ext:
    \QIBM\ProdData\Java400\jdk6\lib\ext:app_server_root\lib   
    -classpath app_server_root\plugins\com.ibm.ws.runtime.jar: 
    app_server_root\com.ibm.ws.security.crypto.jar 
     com\ibm\websphere\security\FileRegistrySample.java 
    The previous lines of code for your class path are one continuous line.
    Important: If you do not have Java SE Development Kit 6 (Classic) installed, use \QOpenSys\QIBM\ProdData\JavaVM\jdk60\32bit\jre\lib\ext or \QOpenSys\QIBM\ProdData\JavaVM\jdk60\64bit\jre\lib\ext instead of \QIBM\ProdData\Java400\jdk6\lib\ext.
  3. Create a classes subdirectory in your profile for custom classes. For more information, see Creating a classes subdirectory in your profile for custom classes.
  4. Copy the class files that are generated in the previous step to the product class path.

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

  5. Follow the steps in Configuring standalone custom registries to configure your implementation using the administrative console. This step is required to implement custom user registries.

Example

Example: Standalone custom registries

Use these links to view registry examples.

A standalone 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 WebSphere Application Server security to various environments where some form of a registry, other than a federated repository, Lightweight Directory Access Protocol (LDAP) registry, or local operating system registry, already exist in the operational environment.

To view a sample standalone custom registry, refer to the following files:

What to do next

If you enable security, make sure that you 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.



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 3:36:59 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-express-iseries&topic=tsectbucs
File name: tsec_tbucs.html