Property extension(formaly LookAside) – Adding custom attributes to file based repository

There may scenarios where security teams doesn’t allow you provide the write access to LDAP from portal to store any additional attributes. To overcome this issue you can use the property extension to store those additional attributes.

Following link explain steps to setup or configure the property extension database

Above wiki talks about the setting up the property extension on separate DB. But for testing it on the local portal installation you can add custom attributes to file based repository that comes out of the box websphere portal installation.

Perform the following steps to add new attributes to your user registry:
  1. Install the required Enterprise Archive (.ear) file on WebSphere Application Server. Select the appropriate task to install the .ear file:
run the ./ wp-la-install-ear -DWasPassword=password task from the wp_profile_root/ConfigEngine directory
  1. Stop and restart the appropriate servers to propagate the changes.
  2. Use a text editor to open the file, located in the wp_profile_root/ConfigEngine/properties directory.
  3. Enter a values for the following required parameters in the file and save the changes
    • la.providerURL = corbaloc:iiop:localhost:10035
    • la.propertyName = yourOwnProperty
    • la.entityTypes  = PersonAccount
    • la.dataType   = String
    • la.multiValued  = false

  1. Run the ./ wp-add-property -DWasPassword=password task to add the attribute to the user registry.
  2. Stop and restart the appropriate servers to propagate the changes.
  1. la.providerURL = corbaloc:iiop:localhost:10035” , Here 10035 bootstrap port number.
  2. If “wp-add-property” fails because of the authentication , you can try changing following unders “sas.client.props”

# RMI/IIOP user identity
  1. If you have multiple properties to add then change the “la.propertyName” and run the wp-add-property task for each custom property.
  2. If everything is successful , then you can see the following xml element for each additional property added in <wp-profile>/config/cells/<cell>/wim/model/wimxmlextension.xml

    <wim:propertySchema nsURI="" dataType="STRING"
        multiValued="false" propertyName=" yourOwnProperty ">

  1. To test whether additional attributes can store values for each user successfully or not
a). Click on the Edit profile from theme or edit the user from the “manage users and groups”
b). Click the portlet menu and click on “configure” portlet
c). check the  “yourOwnProperty” in that.
d). Add a value for the “yourOwnProperty”.

  1. Open “fileregistry.xml” under <wp-profile>/config/cells/<cell>/ and check whether the value you have selected is available or not.

    <wim:entities xsi:type="wim:PersonAccount">
      <wim:identifier externalId="8690e35e-9d79" externalName="uid=wpsadmin,o=defaultWIMFileBasedRealm"
          uniqueId="8690e-9d79-4c397" uniqueName="uid=wpsadmin,o=defaultWIMFileBasedRealm"/>
        <wim:identifier uniqueName="o=defaultWIMFileBasedRealm"/>

Note: “fileregistry.xml” is your local user repository so be careful and suggests not to edit manually.

Additional Info:


How can I verify the attribute mappings configured in a WebSphere Portal or Quickr server?


There are two methods to verify or review the Virtual Member Manager (VMM) attribute mappings in a WebSphere Portal environment.
1. Run the ConfigEngine task wp-query-attribute-config from the <wp_profile_root>/ConfigEngine directory.

AIX example: wp-query-attribute-config -DWasPassword=password

The output of this task is a file called availableAttributes.html that is written to the directory <wp_profile_root>/ConfigEngine/log.

The HTML file will list the properties and corresponding mapping (if any) in table format for the VMM entities PersonAccount (users) and Group.

2. If wp-query-attribute-config fails or the HTML file does not contain the expected output, you can review the mappings manually by visual inspection of the VMM XML configuration files.

Standard Attributes

a. Open the file <wp_profile_root>/config/cells/<cell>/wim/config/wimconfig.xml

b. Look for the XML that begins with <config:attributeConfiguration>. Under this block or stanza all of the attribute mappings will be listed.

For each attribute entry, "name" refers to the attribute in the repository (usually an LDAP) and "propertyName" refers to the "VMM name" for the property or attribute.

For example:

<config:attributes name="userPassword" propertyName="password"/>
<config:attributes name="krbPrincipalName" propertyName="kerberosId">

password is mapped to userPassword and kerberosId is mapped to krbPrincipalName for PersonAccount (users).

<config:attributes name="postalAddress" propertyName="homePostalAddress">

homePostalAddress is mapped to repository property postalAddress for both users and groups.

<config:attributes name="mail" propertyName="ibm-primaryEmail">

ibm-primaryEmail is mapped to mail in the repository.

Unsupported attributes 

If any property has been marked or set as "not supported" the property will appear at the end of the attributeConfiguration section. An property that is not supported will not be used by VMM and no query should be sent by VMM to the repository to fetch a non-supported attribute or its value.

All of the properties in the list below are marked as not supported.

<config:propertiesNotSupported name="homeAddress"/>
<config:propertiesNotSupported name="businessAddress"/>
<config:propertiesNotSupported name="countryName"/>
<config:propertiesNotSupported name="c"/>
<config:propertiesNotSupported name="viewIdentifiers"/>
<config:propertiesNotSupported name="identifier"/>
<config:propertiesNotSupported name="localityName"/>
<config:propertiesNotSupported name="stateOrProvinceName"/>
<config:propertiesNotSupported name="createTimestamp"/>
<config:propertiesNotSupported name="entitlementInfo"/>
<config:propertiesNotSupported name="modifyTimestamp"/>
<config:propertiesNotSupported name="displayName"/>
<config:propertiesNotSupported name="principalName"/>

Custom attributes

If you have installed the LA ("lookaside") enterprise application WIMSYSTEM.ear by running the ConfigEngine task wp-la-install-ear and have added custom attributes to the configuration, these attributes are written to file wimxmlextension.xml in<wp_profile_root>/config/cells/<cell>/wim/model.

Sample entries for custom properties are shown below:

<wim:propertySchema nsURI="" dataType="String" multiValued="false" propertyName="EmployeeID">

<wim:propertySchema nsURI="" dataType="String" multiValued="false" propertyName="region">


Follow the Portal User Management Architecture (PUMA) Collecting Data document for the version of Portal in use. Refer to the links below in the Related URLs section.


1. Custom properties do not have to be mapped in VMM provided they are referred to by the attribute name as it appears in wimxmlextension.xml and an entry for the attribute exists in the file.

2, In some configurations, VMM may send a query for properties marked as NotSupported if a Property Extension database is configured.

3. If the property is known to VMM by default (the list of attributes VMM uses by default depends on the repository type) and the property is referenced by its actual name in the Portal (such as in custom code that you have written), then there is no need to map the property to another name in VMM.

For example, if you use IBM Directory Server you do not need to create a mapping for uid in VMM unless you intend to use uid under a different name. This means that uid does not need to be mapped "to itself", however, it is not an error to do so.

4. See the WebSphere Application Server documentation for more information about the default attribute set for each repository type.

No comments:

Post a Comment