Integrate community membership with Portal security

Overview

IBM WAS uses Virtual Member Manager (VMM) to manage information about community membership.

VMM interfaces with repository types, including:

• Federated
• Stand-alone
• Custom user

We configure VMM to recognize Connections as a repository, allowing to access community user and group information from communities.

After configuring Connections with VMM, we can:

• Search for Connections public and private communities by name (represented as groups in WebSphere)
• Resolve public and private community membership for particular users (represented as group membership in WebSphere)
• Display the WebSphere users that are members of a particular Connections public or private community

If more than one community name matches a query, instead of returning a unique externalID, nothing is returned.

The operation to display WebSphere users that are members of a particular Connections community can have a performance impact for large groups.

Tivoli Directory Integrator is recommended for populating user data into Connections.

When using the profile data population wizard, a user's email might not be populated into the Communities database. A user might not appear in the proper communities until they have logged in to Communities, used a feature from the Communities service, or their profile is synchronized with TDI.

VMM uses externalId to map the user object ID field from the LDAP server, identifying users and determining Community Membership.

IBM Connections and WebSphere Portal must share a common LDAP.

Hidden email is supported.

In the 3.0.1.1 refresh, it is not mandatory any longer to have email enabled.

Configure VMM to recognize a Connections repository

1. Configure single sign-on between Connections and Portal.

2. Start portal

3. To support SSL, similar to the import the SSL certificate from WebSphere Portal, we log on to the the Connections WAS console, retrieve signer-certificate, and set host, port, and alias for the Portal server. For example:

   Host	portal.myco.com
   Port	10025 (SOAP port on Portal)
   Alias	Portal Certificate (Admin can choose an alias)

4. From the portal server, update the VMM schema so that PersonAccount on the Portal server includes personCorrelationAttribute.

   Use this attribute to specify the corresponding person relative distinguished name attribute. For example, ibm-primaryEmail.

   From dmgr....

   cd $PROFILE_HOME/bin ./wsadmin.sh
   $AdminTask addIdMgrPropertyToEntityTypes {-name <personCorrelationAttribute> -dataType string -entityTypeNames PersonAccount}
   $AdminConfig save

   For example, if the personCorrelationAttribute matches ibm-entryUuid, use:

   $AdminTask addIdMgrPropertyToEntityTypes {-name ibm-entryUuid -dataType string -entityTypeNames PersonAccount}
   $AdminConfig save

   Portal must be running while executing this command.

5. Restart the portal server to apply the changes.

Configure the Connections repository to work with VMM

Complete these tasks to configure the Connections User Repository adapter. When configuration is complete, we can verify that it is working by logging in to WebSphere Portal as an administrator. Open the Users and Groups portlet from the Administration tab. Search for groups that must be present as communities in the Connections deployment. If we find the correct groups and the members of the groups are listed, the deployment is successful.

Make sure that you configured Common directory services when we installed the portlets. Common directory services are a requirement for configuring the VMM adapter.

See

• Deploy libraries for the Connections portlets
• Configure the Connections repository for VMM
• Verify impersonation configuration

Parent topic:
Community Pages

Related:

Mapping a community page to a community