wimconfig.xml

wimconfig.xml

Overview
Stanzas
configurationProvider
EntityTypes
Repositories
ldapServerConfiguration
ldapServers
ldapEntityTypes
groupConfiguration
attributeConfiguration
contextPool
cacheConfiguration
realmConfiguration

Overview

wimconfig.xml controls the behavior of the Virtual Member Manager (VMM) services, which WebSphere Portal leverages for...

login
user and group search
access control assignments
other tasks...

In Portal 6.1 and later VMM has replaced the WebSphere Member Manager (WMM). There is no WMM code in Portal or WAS 6.1. Most of the terms used in WMM (realm, searchBase) translate directly to VMM and the configuration "pattern" of properties and their values represented as XML applies to VMM as well.
VMM is simpler to manage in that there is only a single major configuration file, wmmconfig.xml. A number of associated files that were required in WMM (depending on the configuration) are not used in VMM. For example, in WMM realms were defined in the file wmmur.xml and attribute mappings in wmmAttributes.xml (and other files). In VMM all the major configuration properties are included in wimconfig.xml.
The core Portal code does not communicate with a configured repository directly. Calls are made by VMM at the direction of Portal components; principal among these is PUMA, the Portal User Management Architecture. For example, a search for a user by CN in the Manage Users and Groups portlet makes calls to PUMA which in turn calls VMM to fetch data from the repository. Similarly, PUMA API calls also result in method calls by VMM.
VMM is a component of WAS. Defects fixed in VMM are delivered in WAS APARs and Fixpacks. You may be required to upgrade the Application Server in order to resolve a defect in VMM.
Portal configuration tasks, for example wp-create-ldap, update the VMM configuration as well as other Portal resources. APARs that resolve defects in Portal configuration tasks are delivered in Portal Cumulative Fixes and Refresh Packs.
Portal configuration tasks cover most scenarios (for example, the addition of a new realm) but manual modification of wimconfig.xml, eithe through the WAS console, or using text editor, may be necessary to complete or "fine tune" a configuration. In addition, there are properties that may require update in wimconfig.xml for which no Portal configuration task exists. Manual editing of wimconfig.xml is supported and is often the most efficient way to make necessary adjustments.
If there is no Portal configuration task to modify certain properties in the wimconfig.xml, WAS tools such as the AdminTask facility can be used if manual modifications are not to be permitted or to script changes to the file.
The default, out-of-the-box, Portal security configuration is the federated repository type. Configuring Portal to use a stand-alone LDAP repository by running the configuration task wp-modify-standalone-ldap effectively "converts" the configuration to the stand-alone type. If you intend to support multiple repositories or create multiple realms and associate the realms to virtual portals, maintain a federated configuration.

Stanzas

configurationProvider
<configurationProvider maxPagingResults="500" 
                       maxSearchResults="4500" 
                       maxTotalPagingResults="1000" 
                       pagedCacheTimeOut="900" 
                       pagingEntityObject="true" 
                       searchTimeOut="600000">
This stanza appears once in wimconfig.xml. There are no Portal configuration tasks to modify the properties in this section. maxSearchResults can be adjusted to limit the number of results fetched from the LDAP. It is recommended to leave the other properties at the default values.

EntityTypes
<supportedEntityTypes defaultParent="cn=internal,ou=user,dc=ibm,dc=com" 
                      name="PersonAccount">

   <rdnProperties>uid</rdnProperties>

</supportedEntityTypes>

<supportedEntityTypes defaultParent="ou=role,ou=group,dc=ibm,dc=com" 
                      name="Group">

   <rdnProperties>cn</rdnProperties>

</supportedEntityTypes>

<supportedEntityTypes defaultParent="o=defaultWIMFileBasedRealm" 
                      name="OrgContainer">

   <rdnProperties>o</rdnProperties>
   <rdnProperties>ou</rdnProperties>
   <rdnProperties>dc</rdnProperties>
   <rdnProperties>cn</rdnProperties>

</supportedEntityTypes>
The defaultParent defines the default container where users and groups will be created if the Portal UI is used to add users and groups to the repository. There can be only 1 parent per EntityType no matter how many repositories are configured. defaultParents can be set per realm, however. If users and groups are created directly in the repository the parent entities do not need to be modified from the default since they will not be used.
The defaultParent for OrgContainer is not used by WebSphere Portal. The OrgContainer defaultParent will be defined as...
"o=defaultWIMFileBasedRealm"

.even in federated multiple repository configuration unless the entry has been modified manually.

Repositories
<repositories xsi:type="LdapRepositoryType" 
              adapterClassName="com.ibm.ws.wim.adapter.ldap.LdapAdapter"
              id="ClusterLdap" 
              isExtIdUnique="true" 
              supportAsyncMode="false" 
              supportExternalName="false" 
              supportPaging="false" 
              supportSorting="false" 
              supportTransactions="false" 
              certificateFilter=""
              certificateMapMode="EXACT_DN" 
              ldapServerType="IDS6" 
              translateRDN="false">
There will be one stanza for each repository in the environment. A repository may be configured to use 1 or more realms. To map a realm to a Virtual Portal the configuration type must be federated.
For a Custom User Repository ensure the adapterClassName is set to the name of the custom class. wkplc.properties provides a default class for the LDAP and database repositories.
ldapServerType options are defined in wkplc.properties.
Do not use CUSTOM as the ldapServerType unless a Custom Repository is actually being configured.

ldapServerConfiguration
<baseEntries name="dc=ibm,dc=com" 
             nameInRepository="dc=ibm,dc=com"/>
baseEntries "nameInRepository" must be a valid LDAP container (ie, the actual name of the container in the LDAP)
<loginProperties>uid</loginProperties>

loginProperty defines the property used to login to the LDAP.
<ldapServerConfiguration primaryServerQueryTimeInterval="15" 
                         returnToPrimaryServer="true"
                         searchCountLimit="500" 
                         searchTimeLimit="120000" 
                         sslConfiguration="">
There are no tasks to modify the the ldapServerConfiguration properties.

ldapServers
<ldapServers authentication="simple" 
             bindDN="uid=wpsbind,cn=internal,ou=user,dc=ibm,dc=com" 
             bindPassword="{xor}KC8sPTYxOw==" 
             connectionPool="true" 
             connectTimeout="0" 
             derefAliases="always" 
             referal="ignore"
             sslEnabled="false">

    <connections host="ldap.ibm.com" port="389"/>
</ldapServers>

</ldapServerConfiguration>
LDAP-specific properties. The bindDN must be able to bind to, search, and have permission in the LDAP to return all attributes associated to Portal users and groups. The bindDN can be any id and does not have to be the LDAP administrator id. bindDN should be set to a fully qualified distinguished name. bindPassword can be encoded with WAS utility propFilePasswordEncoder. The "referal" (sic) property can be set to cause VMM to "follow" a referral to another LDAP.

ldapEntityTypes
<ldapEntityTypes name="OrgContainer">
        <rdnAttributes name="o" objectClass="organization"/>
        <rdnAttributes name="ou" objectClass="organizationalUnit"/>
        <rdnAttributes name="dc" objectClass="domain"/>
        <rdnAttributes name="cn" objectClass="container"/>
        <objectClasses>organization</objectClasses>
        <objectClasses>organizationalUnit</objectClasses>
        <objectClasses>domain</objectClasses>
        <objectClasses>container</objectClasses>
      </ldapEntityTypes>

     <ldapEntityTypes name="PersonAccount" searchFilter="">
        <objectClasses>inetOrgPerson</objectClasses>
        <searchBases>ou=user,dc=ibm,dc=com</searchBases>
      </ldapEntityTypes>

    <ldapEntityTypes name="Group" searchFilter="">
        <objectClasses>groupOfUniqueNames</objectClasses>
        <searchBases>ou=role,ou=group,dc=ibm,dc=com</searchBases>
    </ldapEntityTypes>
Define the objectClasses for users (PersonAccount), Groups and OrgContainer (the OrgContainer type is not used by WebSphere Portal). The objectClasses are a primary search criteria used by VMM. Add additional searchBases on a new line to limit the scope of a search. Do not use ; or : to concatenate searchBases. ObjectClasses must match the EntityType in LDAP (confirm this with an ldif export from the LDAP). Multiple ObjectClasses can be listed on separate lines.
Do not set or enable a searchFilter for the PersonAccount or Group Entities unless advised to by IBM Support.

groupConfiguration
<groupConfiguration>

<memberAttributes dummyMember="uid=dummy" 
                     name="member" 
                     objectClass="groupOfNames" 
                     scope="direct"/> (TDS and others)

<memberAttributes dummyMember="uid=dummy" 
                     name="uniqueMember" 
                     objectClass="groupOfUniqueNames" 
                     scope="direct"/> (TDS and others)

<memberAttributes dummyMember="" 
                     name="member" 
                     objectClass="group"
                     scope="direct"/> (MSAD)
Group member attributes. Both the name and objectClass must match the class name in the LDAP otherwise searches will fail. Typically, this is observed in the Users and Groups portlet when a group can be retrieved but its members cannot or members of a group do not see Portal content after access control assignments.

attributeConfiguration
<membershipAttribute name="ibm-allGroups" 
                        scope="direct"/> (TDS example)

  <membershipAttribute name="nsRole" 
                          scope="direct"/> (SunOne example)

  <dynamicMemberAttributes name="memberurl"
                               objectClass="groupofurls"/>
memberAttributes name and objectClass must match the entityTypes definitions above. Verify using an LDIF export. membershipAttribute name can be used to "shortcut" group searches to improve performance. dynamicMemberAttributes is used to configure dynamic groups.
For both memberAttributes and membershipAttribute scope values are:

direct The membership attribute only contains direct groups (default).
nested The membership attribute that contains the direct groups and the nested groups.
all The membership attribute contains direct groups, nested groups, and dynamic members.

The use of nested or dynamic groups can negatively affect search performance.
<attributes name="unicodePwd" 
               propertyName="password" 
               syntax="unicodePwd"/>

        <propertiesNotSupported name="description"/>
        <propertiesNotSupported name="jpegPhoto"/>
        <propertiesNotSupported name="labeledURI"/>
        <propertiesNotSupported name="carLicense"/>
        <propertiesNotSupported name="pager"/>
        <propertiesNotSupported name="roomNumber"/>
<
attributes available to Portal the attribute must be added to VMM and then mapped in the VMM configuration using
the appropriate configuration tasks.
LDAP attributes unavailable in Portal will be shown as 'propertiesNotSupported.' An "unsupported" attribute will not be queried. You may set a an attribute as NotSupported to prevent its use in the Portal. Set a given attribute as NotSupported if the property is not indexed in the repository to increase performance.

contextPool
<contextPool enabled="true" 
             initPoolSize="1" 
             maxPoolSize="20" 
             poolTimeOut="0" 
             poolWaitTime="3000" 
             prefPoolSize="3"/>
VMM maintains a pool of threads (or "contexts") to communicate with the repository. Contexts are used for user and group searches and to determine membership during login. There are no config tasks to modify these properties. A context is not the same as a connection.
The Portal 6.1 Tuning Guide recommends the following pool settings:
initPoolSize="10"
maxPoolSize="0"
poolTimeOut="0"
poolWaitTime="3000"
prefPoolSize="30"

In particular, maxPoolSize 0 allows the pool to grow as large as needed.

cacheConfiguration
 <cacheConfiguration>

        <attributesCache attributeSizeLimit="2000" 
                            cacheSize="4000" 
                            cacheTimeOut="1200" 
                            enabled="true"/>

        <searchResultsCache cacheSize="2000" 
                            cacheTimeOut="600" 
                            enabled="true" 
                            searchResultSizeLimit="1000"/>

      </cacheConfiguration>
By default, both VMM and the Portal User Management Architecture (PUMA) cache objects such as LDAP attributes. The cache settings can be tuned in this section.

realmConfiguration
<realmConfiguration defaultRealm="DefaultPortalRealm">

<realms delimiter="/" 
        name="DefaultPortalRealm" 
        securityUse="active" 
        allowOperationIfReposDown="false">

  <participatingBaseEntries name="dc=ibm,dc=com"/>
  <participatingBaseEntries name="dc=raleigh,dc=ibm,dc=com"/>

  <uniqueUserIdMapping propertyForInput="uniqueName" propertyForOutput="uniqueName"/>
  <userSecurityNameMapping propertyForInput="principalName" propertyForOutput="externalName"/>
  <userDisplayNameMapping propertyForInput="principalName" propertyForOutput="principalName"/>
  <uniqueGroupIdMapping propertyForInput="uniqueName" propertyForOutput="uniqueName"/>
  <groupSecurityNameMapping propertyForInput="cn" propertyForOutput="externalName"/>
  <groupDisplayNameMapping propertyForInput="cn" propertyForOutput="cn"/>

</realms>

<realms delimiter="/" 
        name="PortalRealm_Releigh" 
        securityUse="active" 
        allowOperationIfReposDown="false">

  <participatingBaseEntries name="dc=raleigh,dc=ibm,dc=com"/>
  <uniqueUserIdMapping propertyForInput="uniqueName" propertyForOutput="uniqueName"/>
  <userSecurityNameMapping propertyForInput="principalName" propertyForOutput="externalName"/>
  <userDisplayNameMapping propertyForInput="principalName" propertyForOutput="principalName"/>
  <uniqueGroupIdMapping propertyForInput="uniqueName" propertyForOutput="uniqueName"/>
  <groupSecurityNameMapping propertyForInput="cn" propertyForOutput="externalName"/>
  <groupDisplayNameMapping propertyForInput="cn" propertyForOutput="cn"/>
</realms>
</realmConfiguration>
This section defines the Portal realms. In this example, there are two realms, the default realm called "DefaultPortalRealm" and a second realm called "PortalRealm_Raleigh."
The defaultRealm (also called the "super realm" in the Portal Infocenter) must contain the participatingBaseEntries for all realms defined. Realms are usually "bound" or attached to Virtual Portals. More than one realm may be defined in a single repository. Other than the addition of new realms, baseEntries and other properties such as defaultParents, manual modification to wimconfig.xml is usually required to establish a multiple realm configuration.

+
Search Tips | Advanced Search

direct	The membership attribute only contains direct groups (default).
nested	The membership attribute that contains the direct groups and the nested groups.
all	The membership attribute contains direct groups, nested groups, and dynamic members.