Use multiple realms


  1. Overview
  2. Configuration
  3. Sample configuration
  4. Aspects when using Member Manager in a cluster

 

Overview

Realms allow one to aggregate users from multiple LDAP trees and expose them as a coherent user population to WebSphere Portal. For example, you can combine principals from one or more LDAP trees.

A realm must be mapped to a virtual portal to allow the realm's defined user population to login to the virtual portal.

To enable realms, execute the tasks...

When combining multiple LDAP trees, ensure that the distinguished names and the logon attributes (i.e. uid) are unique over all trees.

Realms cannot be used if you you run the task enable-security-ldap, or if you register a custom user registry as the authentication mechanism.

 

Configuration

The Member Manager configuration files are located in...

$WP_ROOT/wmm/

The Member Manager configuration files within a clustered environment are moved to...

$WAS_ROOT/config/wmm

...via a config task that uploads and replicates to all cluster nodes.

wmm.xml Basic configuration for Member Manager as well as the definition of the different user repositories. The user repositories reference different files for their attribute mappings
wmmur.xml Realm definition including the suffixes for user and group creation and the realm mappings to the different user repositories defined in wmm.xml.
wmmAttributes.xml Attributes (for example uid or cn) that Member Manager supports.
wmmLDAPServerAttributes.xml Attributes that map the LDAP attributes to the Member Manager attributes defined in wmmAttributes.xml. Multiple files can exist because each user repository requires its own attribute mapping.
wmmWASAdmin.xml Userid and password of the user that WAS uses during startup for the servers if Member Manager is not available.

When using the multiple realm feature, only adjust the wmmAttributes.xml file to add or remove attributes from the default. Refer to the following sections for more information about these files:

 

wmm.xml

Adjust the global settings and the properties for the different user repositories in the wmm.xml file.

 

Global settings

Set the horizontalPartitioning="true" property and copy the following lines to the <repositories>...</repositories> section:

 <federationRepository name="wmmDBFederation"
     UUID="DB1"
     supportTransactions="true"
     adapterClassName="com.ibm.ws.wmm.db.DataBaseFederationAdapter"
     dataSourceName="jdbc/wmmDS"
     databaseType="DB2"
     dataAccessManagerClassName="com.ibm.ws.wmm.db.dao.db2.WMMDB2Dao"/>

Use the following table to make adjustments depending on the type of database you are using:

databaseType dataAccessManagerClassName
db2 com.ibm.ws.wmm.db.dao.db2.WMMDB2Dao
oracle com.ibm.ws.wmm.db.dao.oracle.WMMOracleDao
cloudscape com.ibm.ws.wmm.db.dao.cloudscape.WMMCloudscapeDao
sqlserver com.ibm.ws.wmm.db.dao.sqlserver.WMMSQLServerDao
informix com.ibm.ws.wmm.db.dao.informix.WMMInformixDao

For dataSourceName, use jdbc/WmmDsName, where the property WmmDsName is specified in...

$WP_ROOT/config/wpconfig.properties

 

Repository settings:

The tag <repositories>...</repositories> contains the following three different repositories; see the associated links for sample code settings:

 

wmmLDAPServerAttributes.xml

The wmmLDAPServerAttributes.xml file defines all the Member Manager attribute definitions and the LDAP attribute mappings. The following is a list of general rules to define attributes in the XML file:

  • The corresponding wmmAttributesMap.dtd file is located in the same directory. Always follow the DTD defined format.

  • Use the following XML tagging order:

    • <repositoryAttributes> is the root tag and all other <attributeMap> tags must be defined within it.

    • <attributeMap> and <compositeAttributeMap> must be defined directly under <repositoryAttributes>. The stand-alone attributes must first be defined using <attributeMap> and then composite attributes must be defined using <compositeAttributeMap>

    • To define composite attributes, define <componentAttributeMap> or <componentCompositeAttributeMap> using <compositeAttributeMap>.

      Again, define non-composite component attributes using <componentAttributeMap> before defining <componentCompositeAttributeMap> within a composite attribute. Within <componentCompositeAttributeMap>, you can use <componentAttributeMap> and <componentCompositeAttributeMap> again to define more parameters. This process can be repeated as necessary.

    The attribute definitions in the wmmLDAPServerAttributes.xml file must be consistent with entries in the wmmAttributes.xml file.

  • The following attribute definitions can be set within the attribute map:

    Parameter Name Description
    wmmAttributeName (Required) The attribute name used in Member Manager.

    This parameter should be consistent with the name in wmmAttributes.xml

    pluginAttributeName (Required) The attribute name used in the profile repository.
    applicableMemberTypes (Required) The member types that the attribute is applicable to. Use a semicolon (;) as the separator. The valid member types are: Person;Group;Organization;OrganizationalUnit. The order is not forced.
    requiredMemberTypes The member types that the attribute is mandatory for. Use a semicolon (;) as the separator. The valid member types are: Person;Group;Organization;OrganizationalUnit.
    multiValued (Required) Set to true if the attribute is multi-value; otherwise, set to false.
    readOnly Set to true if the attribute is read only; otherwise set to false.
    dataType (Required) The data type of the attribute. The valid types are: String, Integer, Timestamp, Object, ByteArray, Long, Double, MemberIdentifier.
    classname If the attribute dataType is Object, define the java class name for the dataType. For example, classname="java.lang.Boolean".
    valueLength An integer to indicate the maximum length of the String attribute.
    defaultValue The default value of the attribute.
    defaultAttribute The default attribute to use when this attribute value is not set.
    description The description of the attribute.
    pluginDataType The data type of the plugin attribute in the profile repository.

    This field is required if the pluginDataType is different from the dataType.

 

wmmur.xml

Type the following lines between the <realms>...</realms> tag to add additional realms:

 <realm id="portal" delimiter="@" default="true">
  <node wmmnode="dc=test,dc=com"/>
  <node wmmnode="cn=users,dc=test,dc=com" defaultParent="Person" />
  <node wmmnode="cn=groups,dc=test,dc=com" defaultParent="Group" />
 </realm>

You can add as many wmmNodes as required. Place wmmNodes under the membership hierarchy scope of the nodes defined in the wmm.xml file for each repository. If you plan to set this realm for a Virtual Portal, add the following entries; This is not required for the default realm if it is not mapped to a Virtual Portal:

add one node with the property defaultParent="Person" defined; the specified node is used as parent distinguished name when creating users. You also must add one node with the property defaultParent="Group" defined; the specified node is used as parent distinguished name when creating groups. Sample: When you create a user in WebSphere Portal while being in a Virtual Portal that is mapped to the realm portal defined above, a user with name myuser will get the distinguished name <rdn-attribute>=myuser,cn=users,dc=test,dc=com.

The following table lists xml tags, parameter names, and descriptions for Realms:

XML Tag Parameter Name Description
Realm id The unique name of the realm.
delimiter A separator between the user ID and realm ID. "\" is the special character handler. If the user ID or realm ID contains special characters, put a backslash in front of the special character.

Do not give a realm that contains other realm delimiters inside.

For example, userId=user1@ca.ibm.com; delimiter=@; realm=ibmclub; When passing UserId to WMMUR, the string should look like: user1\@ca.ibm.com@ibmclub.

default If true, this realm is a default realm.

Define only one realm as the default realm in the whole WMMUR configuration.

Node wmmnode The Member Manager node value. In wmm.xml, each repository has a nodeMaps definition. Here, wmmnode should match the Member Manager member node.

For example, in wmm.xml, one of the <nodeMap> has the following value:

 <nodeMap node="dc=setgetweb,dc=com"
  pluginNode="dc=setgetweb,dc=com"/>

In wmmur.xml, the <node> could be:

 <node wmmnode=" dc=setgetweb,dc=com"/>

The cases are sensitive. The wmmNode case in wmmur.xml should match the node case in wmm.xml.

defaultParent (Optional) Set this wmmNode to be the default parent DN for specified member type. The member type can be Person for users or Group for groups.

Important Note: The realm that is flagged as the default realm must contain all wmmNodes that are defined in the other realms.

 

wmmWASAdmin.xml

The following table lists xml tags, parameter names, and descriptions for wmmWASAdmins:

XML Tag Parameter Name Description
admin logonID The ID used for logon.
logonPassword The encrypted user password.

Although clear text passwords are accepted, it is highly recommended that you encrypt the password. Use the encryption tool that Member Manager provides.

uniqueUserID The distinguished user name.

 

Sample Configuration

The following are sample configurations:

When combining multiple LDAP trees, ensure that the distinguished names and the logon attributes (i.e. uid) are unique over all trees.

  • Using a Member Manager database user registry

    wmm.xml: wp_root\wmm\wmm_DB.xml

    wmmLDAPServerAttributes.xml: wp_root\wmm\wmmDBAttributes.xml

    wmmur.xml: <?xml version="1.0" encoding="UTF-8"?>

     <wmmur>
      <realms>
       <realm id="portal" delimiter="@" default="true">
        <node wmmnode="0=Default Organization"/>
       </realm>
      </realms>
     </wmmur>
    

  • Using a single LDAP with a single Member Manager node

    wmm.xml: There are different sample files for all LDAPs supported by WebSphere Portal in the wp_root\wmm\ directory. The following table shows all supported files:

    File Name Description
    wmm_LDAP.xml Sample configuration for a generic LDAP
    wmm_LDAP_LA.xml Additional configuration required for LookAside database
    wmm_LDAP_LA_AD.xml Sample file for LDAP (Active Directory Server 2000, SSL) plus LookAside configuration
    wmm_LDAP_LA_DM.xml Sample file for LDAP (Domino Directory Server V6) plus LookAside configuration
    wmm_LDAP_LA_IDS.xml Sample file for LDAP (IBM Tivoli Directory Server 5.1, SSL) plus LookAside configuration
    wmm_LDAP_LA_NDS.xml Sample file for LDAP (Novell eDirectory, SSL) plus LookAside configuration
    wmm_LDAP_LA_SO.xml Sample file for LDAP (Sun ONE) plus LookAside configuration

    wmmLDAPServerAttributes.xml: Check the files referenced by the wmm_LDAP_LA_* files in the wp_root\wmm\ directory.

    wmmur.xml:

     <?xml version="1.0" encoding="UTF-8"?>
      <wmmur>
       <realms>
        <realm id="portal" delimiter="@" default="true">
         <node wmmnode="dc=test,dc=com"/>
         <node wmmnode="cn=users,dc=test,dc=com" defaultParent="Person" />
         <node wmmnode="cn=groups,dc=test,dc=com" defaultParent="Group" />
        </realm>
       </realms>
      </wmmur>
    

  • Using a single LDAP with multiple Member Manager nodes

    wmm.xml: There are different sample files for all LDAPs supported by WebSphere Portal in the wp_root\wmm\ directory. The following table shows all supported files:

    File Name Description
    wmm_LDAP.xml Sample configuration for a generic LDAP
    wmm_LDAP_LA.xml Additional configuration required for LookAside database
    wmm_LDAP_LA_AD.xml Sample file for LDAP (Active Directory 2000, SSL) plus LookAside configuration
    wmm_LDAP_LA_DM.xml Sample file for LDAP (Domino Directory Server V6) plus LookAside configuration
    wmm_LDAP_LA_IDS.xml Sample file for LDAP (IBM Tivoli Directory Server 5.1, SSL) plus LookAside configuration
    wmm_LDAP_LA_NDS.xml Sample file for LDAP (Novell eDirectory Server, SSL) plus LookAside configuration
    wmm_LDAP_LA_SO.xml Sample file for LDAP (Sun ONE) plus LookAside configuration

    wmmLDAPServerAttributes.xml: Check the files referenced by the wmm_LDAP_LA_* files in the wp_root\wmm\ directory.

    wmmur.xml:

     <?xml version="1.0" encoding="UTF-8"?>
      <wmmur>
       <realms>
        <realm id="portal" delimiter="@" default="true">
         <node wmmnode="dc=raleigh,dc=ibm,dc=com"/>
         <node wmmnode="dc=sanjose,dc=ibm,dc=com"/>
         <node wmmnode="cn=users,dc=raleigh,dc=ibm,dc=com" defaultParent="Person" />
         <node wmmnode="cn=groups,dc=raleigh,dc=ibm,dc=com" defaultParent="Group" />
        </realm>
        <realm id="suffix2" delimiter="@" default="false">
         <node wmmnode="dc=sanjose,dc=ibm,dc=com"/>
         <node wmmnode="cn=users,dc=sanjose,dc=ibm,dc=com" defaultParent="Person" />
         <node wmmnode="cn=groups,dc=sanjose,dc=ibm,dc=com" defaultParent="Group" />
        </realm>
       </realms>
      </wmmur>
    

 

Aspects when using Member Manager in a cluster

In a clustered environment, Member Manager files are not located at wps_root/wmm. They are moved to...

$WAS_ROOT/config/wmm

When the security configuration task runs, it uploads the files to the deployment manager and replicates them to all cluster nodes.

To manually edit the Member Manager files for a WebSphere Portal node that has been federated, check the files out of the deployment manager configuration repository before you can make any changes. For information on checking files out or in, refer to Managing the cluster.

On the Network Deployment machine and any nodes in the cell that do not contain WebSphere Portal, the authentication works by default against the wmmWASAdmin.xml file. The same holds true for the node agent that runs on each server. When stopping a node agent, use a user ID specified in the the wmmWASAdmin.xml file.

Refer to the wmmWASAdmin.xml section for more information.

You can configure the authentication against an LDAP server by using the WAS administrative console. In the administrative console, navigate to...

Security | User Registries | Custom | Custom Properties

...and adapt the following parameters to enable LDAP:

Name Value

(Example/Default)

Description
wasUserRegistry Type (Optional) wmmLDAP WAS user's profile is on LDAP

Then add the following properties depending on the type of LDAP you are using:

Name Valid Value (Example) Description
ldapURL (Required) ldap://localhost:389 (for single LDAP)

or

ldap://ldap1.setgetweb.com:389

ldap://ldap2.setgetweb.com:389 (for multiple LDAPs)

LDAP server URL. It can be a single LDAP URL or multiple LDAP URLs.

Use a space to separate multiple URLs.

ldapType (Optional) 0 = IBM Directory Server
1 = Secure Way
2 = Sun ONE
3 = Domino
4 = Active Directory
5 = Novell eDirectory
LDAP server. If not specified, 0 defaults as the ldapType.
baseDN (Required) <DN> The base distinguished name of wmmLDAP, which indicates the starting point for LDAP searches.

The following property is required for all LDAP servers. The DN is case sensitive. The baseDN case should match the <nodeMap> node case set in wmmur.xml

ldapBaseDN (Optional) <ldapDN> If you are in the wmm.xml configurationb file, the pluginNode in nodeMap for this LDAP server is different from the wmmNode; put the pluginNode value as ldapBaseDN.

For example:

baseDN="o=default organization" and in wmm.xml, <nodeMap node="0=default organization" pluginNode="dc=setgetweb,dc=com"/>

Here ldapBaseDN="dc=setgetweb,dc=com"

The DN is case sensitive. The ldapBaseDN case should match the pluginNode case set in wmm.xml.

bindDN (Optional) <LDAP bind Id> The distinguished name for the appserver to use to bind to the directory server. If not specified, this property will be anonymous.
bindPassword (Optional) <password> The password used when binding the appserver to the directory server.

Although clear text passwords are accepted, it is highly recommended that you encrypt the password. Use the encryption tool that Member Manager provides.

userIdMap (Optional) Novell eDirectory: person:cn A Member Manager person RDN filter.

This property should match the "Person" rdnAttrTypes value for Member Manager <supportedMemberTypes>

If you are in Member Manager, the Member Manager attribute is mapped to a different name in LDAP; add the LDAP attribute name to the end and separate it with ":".

For example, in the wmmLDAPAttributes.xml file, uid is mapped to the email attribute. userIdMap=inetOrgPerson:uid:email.

If not specified, the default value will be used.

ldapUserIdMap (Optional) <LDAP user RDN attribute name> The user LDAP RDN. This parameter is only required when the value is different than the userIdMap value. It should match "Person" rdnAttrTypes value for wmmLap <supportedLdapEntryTypes>.
groupIdMap *:cn An LDAP filter that maps the short name of a group to an LDAP entry.

If not specified, the default value will be used.

userFilter (Optional) Novell eDirectory: (&(cn=%v)(objectclass=Person)) An LDAP filter clause for searching the registry for users.

If not specified, the default value will be used.

groupFilter (Optional) Novell eDirectory: (&(cn=%v)(objectclass=groupOfNames)) An LDAP filter clause for searching the registry for groups.

If not specified, the default value will be used.

sslConfig (Optional) true or false Secure Sockets Layer configuration to use for the LDAP connection. If not set, assume SSL is not enabled.

 

Recommendations

Adding the super admin to other realms:

When you separate the realms completely for the different Virtual Portals, the administrator of the default VP can not log into the other VPs anymore. Add the users to the other realms to change this. Make the following adjustments to the wmmur.xml file:

Add <node wmmnode="<DN of the super admin"/> to the wmmNodes you want the super admin to log in (where the super admin is not already part of another wmmNode).

 

Limitations

Uniqueness of logon-ids and DNs:

The DN of a principal must be unique over all wmmNodes defined in wmmur.xml.

The attributes that are defined as logon attributes must be unique for the wmmNodes defined in a realm or the logon will fail. The logon with the DN of the user is in this case still possible.

 

See also

  1. Configure a database user registry
  2. Configure for LDAP without realm support
  3. Configure for LDAP with realm support

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.