Using the custom registry to enable security for V4.0.3 and later releases of WebSphere® Application Server V4.0 AEs (single server edition) to run the Application Server using a non-root user ID
 Technote (FAQ)
 
Problem
If you use V4.0.3 or a later release of V4.0 AEs , you can start WebSphere Application Server only under the root user ID after you enable security with LocalOS. No alternatives are published.
 
Cause
No information is provided for alternatives to running WebSphere Application Server using a root user ID if security is required for WebSphere Application Server AEs.
 
Solution
Use the custom registry to enable security on AEs and start WebSphere Application Server using a non-root user ID.

These procedures are for WebSphere Application Server AEs V4.0 (single server) only, V4.0.3 and later releases.
  1. Stop the server if it is running.
  2. Create the com/ibm/ejs/security/registry/wsregistries.properties file. Cut and paste the following lines in this file:

    LDAP=com.ibm.ejs.security.registry.CustomRegistryImpl
    Windows=com.ibm.ejs.security.registry.CustomRegistryImpl
    Windows_NT=com.ibm.ejs.security.registry.CustomRegistryImpl
    Windows_2000=com.ibm.ejs.security.registry.CustomRegistryImpl
    OS/400=com.ibm.ejs.security.registry.CustomRegistryImpl
    AIX=com.ibm.ejs.security.registry.CustomRegistryImpl
    Solaris=com.ibm.ejs.security.registry.CustomRegistryImpl
    SunOS=com.ibm.ejs.security.registry.CustomRegistryImpl
    NetWare_5.00=com.ibm.ejs.security.registry.CustomRegistryImpl
    NetWare=com.ibm.ejs.security.registry.CustomRegistryImpl
    HP-UX=com.ibm.ejs.security.registry.CustomRegistryImpl
    Linux=com.ibm.ejs.security.registry.CustomRegistryImpl
    Custom=com.ibm.ejs.security.registry.CustomRegistryImpl

    Copy this file to a directory, which is in front of the class path. For a normal WebSphere Application Server installation (that did not have its class path modified)you can use the %WAS_HOME%/classes directory.

    For example:

    $WAS_HOME/classes/com/ibm/ejs/security/registry/wsregistries.properties).
  3. The CustomRegistry setup is not supported in the thinClient (Web console). So, to enable security to use the CustomRegistry setup, modify the server-cfg.xml file , as described in the following examples. All the changes are contained in the <userRegistry ...> .... </userRegistry> stanza.

    The examples provided here are from the WebSphere Application V4.0 Information Center documentation, which uses a file-based registry (FileRegistrySample.java) as the CustomRegistry,
    1. Modify the security server ID and password (this ID is in the CustomRegistry implementation).

      For example:

      <userRegistry xmi:type="security:LocalOSUserRegistry" xmi:id="LocalOSUserRegistry_1" serverId="bob" serverPassword="bob1" name="LOCALOS">

      Note that the password is converted from plain text to an encoded string during server startup.
    2. Add the CustomRegistry implementation file to the properties. The name (key) is CustUserRegImplClass.

      For example:

      <properties xmi:id="UserRegProperty_1" name="CustUserRegImplClass" value="FileRegistrySample"/>

      If the implementation file is com/myCompany/myImpl.class, the value is com.myCompany.myImpl.

      For example:

      <properties xmi:id="UserRegProperty_1" name="CustUserRegImplClass" value="com.myCompany.myImpl"/>
    3. Add additional properties that are needed for the CustomRegistry initialization. All these properties have names (keys) that start with Custom_ . This prefix is used by the WebSphere Application Server internal implementation to separate the custom registry properties from others.

      For example:

      <properties xmi:id="UserRegProperty_2" name="Custom_usersFile" value="c:/temp/users.props"/> <properties xmi:id="UserRegProperty_3" name="Custom_groupsFile" value="c:/temp/groups.props"/>

      When these properties are propagated to the initialize method of the CustomRegistry implementation file (FileRegistrySample in this case), Custom_ is removed.

      For example, the Custom_usersFile property is propagated as usersFile (that is Custom_ removed) to the CustomRegistry Implementation file. So in your Implementation file, look for usersFile and not Custom_usersFile.
  4. Enable security if it is not already enabled. Set enabled to true as shown in the following example:

    <security xmi:id="Security_1" cacheTimeout="30000" enabled="true" activeAuthMechanism="LocalOSAuthentication_1">
  5. Start the server. The custom registry is now in use.

Note that on AE, a custom registry uses the Lightweight Third Party Authentication (LTPA) authentication mechanism. AEs does not support LTPA, so the local OS authentication mechanism (but not user registry) is used.
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Security
Operating system(s): HP-UX
Software version: 4.0.5
Software edition:
Reference #: 1140045
IBM Group: Software Group
Modified date: Jan 15, 2004