Use multiple realms and user registries

 

+
Search Tips   |   Advanced Search

 

1. Overview
2. Preparation
3. Configuration
4. Sample Configuration
5. Aspects when using Member Manager in a cluster
6. Enabling LDAP server as Localmode
7. Recommendations
8. Limitations

 

Overview

A realm allows one to group users from one or more LDAP trees of one user registry and expose them as a coherent user population to WebSphere Portal.

Using multiple realms is also known as horizontal partitioning.

For a user population of a realm to access a virtual portal, associate the realm with the Virtual Portal. A virtual portal can only be accessed by associated realm members. For example, wpsadmin cannot log in to a virtual portal unless he is a member of the associated realm.

Multiple virtual portals can share the same user population by specifying the same realm relationship.

Users can be members of more than one realm.

 

Multiple LDAP support in 6.0

• Requires WMMUR

• WMM can dispatch calls to multiple user registries

• Realms can point to a (subset of a) specific user registry or to (subsets of) multiple user registries

• User IDs need to be unique across all registries

• Requires a Federation DB for WMM

 

Preparation

To use realms, the WAS user registry provided by Member Manager must be used as the authentication mechanism in WAS. Use the tasks...

• enable-security-wmmur-ldap
• enable-security-wmmur-db

...to use the realm feature.

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

When using enable-security-wmmur-db, the IDs entered in the wpconfig.properties file...

• PortalAdminId
• WasUserId
• ...

...are created in the database. These must not exist with its distinguished names or logon attributes in the other registries you want to add later.

Realms cannot be leveraged under any of the following conditions...

• When in non-security mode.

• When using enable-security-ldap.

• When using a custom user registry as the authentication mechanism.

See also...

• Configure a database user registry
• Configure LDAP for non-realm support
• Configure LDAP for realm support

 

Configuration

In a non-clustered environment, Member Manager configuration files are located in...

portal_server_root/wmm/

In a clustered environment, they are located in...

was_profile_root/wmm

...on the dmgr server.

They are federated using a configuration task that uploads and replicates them to all cluster nodes.

wmm.xml	Main configuration file. Where user repositories are defined. See wmmLDAPServerAttributes.xml.
wmmur.xml	Set... Suffixes for user and group creation Realm mappings to user repositories defined in wmm.xml
wmmAttributes.xml	Attributes (for example uid or cn) that Member Manager supports. Only adjust this file when making attribute changes.
wmmLDAPServerAttributes.xml	Map LDAP attributes to 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.

 

wmm.xml

The wmm.xml file defines general information about Member Manager:

defaultRealmName	Name of the realm used as default from the WMMUR information
horizontalPartitioning	Set to true if you will use multiple LDAP repositories or a database and an LDAP repository.
lookaside	Set to true if you will use a database store to store additional attributes beside the LDAP database. The default setting is false.
configurationFile	Attributes that Member Manager returns.
maximumSearchResult	Maximum number of returned objects for a non-paged search result. The default setting is 200.
searchTimeOut	Number of milliseconds a search result remains active.

 

Repository settings:

The tag <repositories>...</repositories> contain the following Member Manager repositories...

• Database Repository
• LDAP Repository
• Federation Repository
• Lookaside Repository
• Custom user repository

 

---

wmmLDAPServerAttributes.xml

wmmLDAPServerAttributes.xml sets Member Manager and LDAP attribute mappings.

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

Parameter	Description
wmmAttributeName	Attribute name used in Member Manager. (Required) Should match the name in wmmAttributes.xml
pluginAttributeName	Attribute name used in the profile repository. (Required)
applicableMemberTypes	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. (Required)
requiredMemberTypes	Member types that the attribute is mandatory for. Use a semicolon (;) as the separator. The valid member types are: Person;Group;Organization;OrganizationalUnit
multiValued	Set to true if the attribute is multi-value; otherwise, set to false. (Required)
readOnly	Set to true if the attribute is read only; otherwise set to false.
dataType	Data type of the attribute. The valid types are: String Integer Timestamp Object ByteArray Long Double MemberIdentifier (Required)
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	Default value of the attribute.
defaultAttribute	Default attribute to use when this attribute value is not set.
description	Description of the attribute.
pluginDataType	Data type of the plug-in attribute in the profile repository. This field is required if the pluginDataType is different from the dataType.

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

<repositoryAttributes> is the root tag.

• Stand-alone attributes are defined first using <attributeMap>
• Composite attributes are defined next using <compositeAttributeMap>

To define composite attributes, define...

<componentAttributeMap>

...or...

<componentCompositeAttributeMap>

...using...

<compositeAttributeMap>

Define non-composite component attributes using <componentAttributeMap> before defining <componentCompositeAttributeMap> within a composite attribute.

Within <componentCompositeAttributeMap>, we 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 match entries in the wmmAttributes.xml file.

 

wmmur.xml

To add additional realms, edit wmmur.xml, and insert the following between the <realms>...</realms> tags...

    
<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>

We 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 one node with the property...

defaultParent="Person"

...to be used as parent distinguished name when creating users and add one node with the property...

defaultParent="Group"

...to be used as parent distinguished name when creating groups.

For example, 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	Description
Realm	id	unique name of the realm.
	delimiter	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=yourco,dc=com" pluginNode="dc=yourco,dc=com"/> In wmmur.xml, the <node> could be: <node wmmnode=" dc=yourco,dc=com"/> The cases are sensitive. The wmmNode case in wmmur.xml should match the node case in wmm.xml.
	defaultParent	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. (Optional)

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	Description
admin	logonID	The ID used for logon.
	logonPassword	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	Distinguished user name.

 

Sample Configuration

The following are

There are different sample files for all LDAP directories supported by WebSphere Portal in...

portal_server_root/wmm/

...for example...

File Name	Description
wmm_LDAP.xml	Generic LDAP directory
wmm_LDAP_LA.xml	Additional configuration required for Lookaside database.
wmm_LDAP_LA_AD.xml	Microsoft Active Directory 2000, SSL plus Lookaside configuration
wmm_LDAP_LA_DM.xml	Domino Directory V6 plus Lookaside configuration
wmm_LDAP_LA_IDS.xml	IBM Tivoli Directory Server 5.1, SSL plus Lookaside configuration
wmm_LDAP_LA_NDS.xml	Novell eDirectory, SSL plus Lookaside configuration
wmm_LDAP_LA_SO.xml	Sun Java System Directory Server plus Lookaside configuration

When combining multiple LDAP registries, ensure that the distinguished names and the logon attributes are unique over all registries.

When using enable-security-wmmur-db, the IDs entered in the wpconfig.properties file (PortalAdminId, WasUserId, ...) are created in the database; these must not exist with its distinguished names or logon attributes in the other registries you want to add later.

Using a database user registry

portal_server_root/wmm/wmm_DB.xml
portal_server_root/wmm/wmmDBAttributes.xml

wmmur.xml...

    
 <?xml version="1.0" encoding="UTF-8"?>
    <wmmur>
        <realms>
            <realm id="portal" delimiter="@" default="true">
                <node wmmnode="o=Default Organization"/>
            </realm>
        </realms>
    </wmmur>

wmmLDAPServerAttributes.xml...

Check the files referenced by the wmm_LDAP_LA_* files in...

portal_server_root/wmm/

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 directory with multiple Member Manager nodes

wmm.xml:

There are different sample files for all LDAP directories supported by WebSphere Portal in...

portal_server_root/wmm/

The following table shows all supported files:

File Name	Description
wmm_LDAP.xml	Sample configuration for a generic LDAP directory
wmm_LDAP_LA.xml	Additional configuration required for Lookaside database
wmm_LDAP_LA_AD.xml	Active Directory 2000, SSL plus Lookaside configuration
wmm_LDAP_LA_DM.xml	Domino Directory V6 plus Lookaside configuration
wmm_LDAP_LA_IDS.xml	Tivoli Directory Server 5.1, SSL plus Lookaside configuration
wmm_LDAP_LA_NDS.xml	Novell eDirectory, SSL plus Lookaside configuration
wmm_LDAP_LA_SO.xml	Sun Java System Directory Server plus Lookaside configuration

For wmmLDAPServerAttributes.xml check the files referenced by the wmm_LDAP_LA_* files in...

portal_server_root/wmm/

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>

wmm.xml...

To successfully use the user/group search function for additional nodes that use different suffixes than the default realm, add them to the <nodeMaps> definition of the configured <ldaprepository> as shown below:

<-----Existing section for base node----->

                <ldapRepository name="wmmLDAP"
                                 UUID="LDAP1"
                                 profileRepositoryForGroups="LDAP1"
               ......... 
                 <nodeMaps>  //Point to the suffix information defined for the realm                                 <nodeMap node="dc=raleigh,dc=ibm,dc=com"
                                 pluginNode="dc=raleigh,dc=ibm,dc=com"/>
                                 <NodeMap node="cn=users,dc=raleigh,dc=ibm,dc=com"
                                 pluginNode="cn=users,dc=raleigh,dc=ibm,dc=com"/>
                                 <nodeMap node="cn=groups,dc=raleigh,dc=ibm,dc=com"
                                 pluginNode="cn=groups,dc=raleigh,dc=ibm,dc=com"/> 
                                <nodeMap node="dc=sanjose,dc=ibm,dc=com"
                                 pluginNode="dc=sanjose,dc=ibm,dc=com"/>
                                 <NodeMap node="cn=users,dc=sanjose,dc=ibm,dc=com"
                                 pluginNode="cn=users,dc=sanjose,dc=ibm,dc=com"/>
                                 <nodeMap node="cn=groups,dc=sanjose,dc=ibm,dc=com"
                                 pluginNode="cn=groups,dc=sanjose,dc=ibm,dc=com"/>
                </nodeMaps>
                </ldapRepository>

Combining multiple LDAPswmm.xml:

The following table shows sample configuration files for supporting multiple LDAPs:

File Name	Description
wmm_IDS_AD.xml	Sample configuration for supporting two LDAP repositories: Tivoli Directory Server and Active Directory
wmm_IDS_DM_LA.xml	Sample configuration for supporting two LDAP repositories: Tivoli Directory Server and Domino Directory, plus additional configuration required for LookAside database.

wmmLDAPServerAttributes.xml:

Check the files referenced by the wmm_LDAP_LA_* files in \wmm\ directory.

wmmur.xml:

<wmmur>
        <realms>
            <realm id="portal" delimiter="@" default="true">
                <node wmmnode="dc=raleigh,dc=ibm,dc=com/">
                <node wmmnode="OU=hr,o=ibm,C=us"/>
            </realm>
            <realm id="suffix2" delimiter="@" default="false">
                <node wmmnode="OU=hr,o=ibm,C=us"/>
                <node wmmnode="cn=users,OU=hr,o=ibm,C=us" defaultParent="Person" />
                <node wmmnode="cn=groups,OU=hr,o=ibm,C=us" defaultParent="Group" />
            </realm>
        </realms>
    </wmmur>

Combining a single LDAP directory with a database user registry

wmm.xml:

The file...

/wmm/wmm_DB_LDAP.xml

...contains the configuration without LookAside, while...

/wmm/wmm_DB_LDAP_LA.xml

...contains the LookAside.

wmmLDAPServerAttributes.xml:

Check the files referenced by the wmm_LDAP_LA_* files in the /wmm/ directory. wmmur.xml:

To combine multiple LDAPs with a database repository, use the following information as a starting point and then add the additional LDAP repositories to the database repository.

<wmmur>
    <?xml version="1.0" encoding="UTF-8"?>
        <realms>
            <realm id="portal" delimiter="@" default="true">
                <node wmmnode="dc=test,dc=com"/>
                <node wmmnode="o=Default Organization"/>
            </realm>
            <realm id="dbmode" delimiter="@" default="false">
                <node wmmnode="o=Default Organization"/>
                <node wmmnode="o=Default Organization" defaultParent="Person" />
                <node wmmnode="o=Default Organization" defaultParent="Group" />
            </realm>
        </realms>
    </wmmur>

 

Aspects when using Member Manager in a cluster

In a clustered environment, Member Manager files are not located at...

portal_server_root/wmm

They are moved to...

was_profile_root/config/wmm

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

If we need 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 we can make any changes.

Refer to Enabling LDAP server as Localmode for information about manually configuring the LDAP directory to perform authentication.

On the WAS 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 wmmWASAdmin.xml file.

• If you run the enable-security-wmmur-ldap task, this will be the same user ID specified by the WasUserid property in the wpconfig.properties file.

• If you run the enable-security-wmmur-db task, this will be the same user ID specified by the WasUserid property in the wpconfig.properties file.

  If you are configuring security with a database repository, we can only login to the portal and the WAS Administration console using the short ID, for example, as a portaladmin user, you would use the ID you specified in the wpconfig.properties file under PortalAdminId and as the WAS administrative user, you would use the ID for WasUserid.

Refer to the wmmWASAdmin.xml section for more information.

 

Enable LDAP server as Localmode

We can configure the authentication against an LDAP server by using the WebSphere Application Server administrative console. In the administrative console, navigate to...

Security | Global security | User Registries | Custom | Custom Properties

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

Name	Value	Description
wasUserRegistry Type	wmmLDAP	WebSphere Application Server user's profile is on LDAP server (Optional)

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

Name	Valid Value (Example)	Description
ldapURL	ldap://localhost:389 (for single LDAP) (Required) or ldap://ldap1.yourco.com:389 ldap://ldap2.yourco.com:389 (for multiple LDAP directories)	LDAP server URL. It can be a single LDAP URL or multiple LDAP URL. Use a space to separate multiple URL.
ldapType	(Optional) 0 = Tivoli Directory Server 1 = IBM SecureWaySecurity Server for z/OSand OS/390 2 = Sun Java System Directory Server 3 = Lotus Domino 4 = Active Directory 5 = Novell eDirectory	LDAP server. If not specified, 0 defaults as the ldapType.
baseDN	<DN>	The base distinguished name of wmmLDAP, which indicates the starting point for LDAP searches. (Required) 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	<ldapDN> (Optional)	If you are in the wmm.xml configuration 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=yourco,dc=com"/> Here ldapBaseDN="dc=yourco,dc=com" The DN is case sensitive. The ldapBaseDN case should match the pluginNode case set in wmm.xml.
bindDN	LDAP bind ID (Optional)	The distinguished name for the application server to use to bind to the directory server. If not specified, this property will be anonymous.
bindPassword	password (Optional)	The password used when binding the application server 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	Novell eDirectory: person:cn (Optional)	A Member Manager person RDN filter. This property should match the "Person" rdnAttrTypes value for Member Manager supportedMemberTypes If we are in Member Manager, the Member Manager attribute is mapped to a different name in LDAP directory; add the LDAP attribute name to the end and separate it with ":". For example, in the wmmLDAPAttributes.xml file, uid is mapped to the e-mail attribute. userIdMap=inetOrgPerson:uid:email. If not specified, the default value will be used.
ldapUserIdMap	<LDAP user RDN attribute name> (Optional)	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 wmmLdap 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	Novell eDirectory: (&(cn=%v)(objectclass=Person)) Optional	An LDAP filter clause for searching the registry for users. If not specified, the default value will be used.
groupFilter	Novell eDirectory: (&(cn=%v)(objectclass=groupOfNames)) Optional	An LDAP filter clause for searching the registry for groups. If not specified, the default value will be used.
sslConfig	true or false (Optional)	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 virtual portal can not log into the other virtual portals 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).

Manually configuring the LDAP server to perform authentication:

Refer to Enabling LDAP server as Localmode for information about manually configuring the LDAP server to perform authentication. Sample for multiple LDAPs:

<wmmur>
        <realms>
            <realm id="portal" delimiter="@" default="true">
                <node wmmnode="dc=raleigh,dc=ibm,dc=com"/>
                <node wmmnode="OU=hr,o=ibm,C=us"/>
            </realm>
            <realm id="suffix2" delimiter="@" default="false">
                <node wmmnode="OU=hr,o=ibm,C=us" />
                <node wmmnode="cn=users,OU=hr,o=ibm,C=us" defaultParent="Person" />
                <node wmmnode="cn=groups,OU=hr,o=ibm,C=us" defaultParent="Group" />
                <node wmmnode="uid=wpsadmin,cn=users,dc=raleigh,dc=ibm,dc=com"/>
            </realm>
        </realms>
    </wmmur>

 

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.

Lotus Domino Single Signon is not supported in combination with multiple user registries.

• Member Manager database repository configuration
  

• Member Manager LDAP repository configuration
  

• Member Manager Federation Repository
  This topic provides a sample Member Manager Federation Repository configuration in the wmm.xml file.

• Member Manager lookaside repository configuration
  This topic provides a sample Member Manager Lookaside Repository configuration in the wmm.xml file.

 

Parent topic:

Additional LDAP configuration

 

---