Dynamic groups. These are defined as a search query maintained by the LDAP. Dynamic groups allow for greater LDAP administrative efficiency by providing an alternative to maintaining static group membership lists. For example, the USWorkforce group could be defined as all users with c=US.
Note: Dynamic groups generally impose a high performance overhead because of the number of LDAP requests involved. An alternative, whereby rule based groups are managed within VMM rather than the LDAP, is available on the IBM Lotus and WebSphere Portal Business Solutions Catalog (Nav Code 1WP1002PK).
If you are interested in setting dynamic groups up and trying them out, here is an article from IBM for WebSphere Application Server 6.1 on how to set it up. The steps are not that different for WebSphere Application Server 7.0.
Application groups. These are maintained in a VMM database repository. Members may exist in other repositories. These are for WebSphere Portal's use only and are useful if you are using a read-only LDAP as the user repository yet still want to use groups in assigning access rights.
Reusing WebSphere Application Server groups. WebSphere Application Server collects group information during authentication and, rather than repeating this work, WebSphere Portal can be configured to re-use WebSphere Application Server's results of determining group membership. This can improve performance. Consider whether WebSphere Application Server's group resolution is the same as VMM's to maintain functionality
You can divide a federated repository into realms on the basis of base distinguished names, and you can use these realms to define user bases for virtual portals.
WebSphere Portal maintains realm/virtual portal associations; only users from the associated realm can log in to the virtual portal.
VMM maintains realm definitions. For example, the following wimconfig.xml excerpt defines two realms, VP1Realm and VP2Realm, with each realm containing users and groups from two different repositories:
<config:repositories ... id="ibm1"...>
<config:baseEntries name="dc=node1,dc=ibm1,dc=com" ... />
<config:baseEntries name="dc=node2,dc=ibm1,dc=com"... />
...
</config:repositories>
<config:repositories ... id="ibm2"...>
<config:baseEntries name="dc=node3,dc=ibm2,dc=com" ... />
<config:baseEntries name="dc=node4,dc=ibm2,dc=com"... />
...
</config:repositories>
...
<config:realms delimiter="/" name="VP1Realm" securityUse="active">
<config:participatingBaseEntries name="dc=node1,dc=ibm1,dc=com"/>
<config:participatingBaseEntries name="dc=node4,dc=ibm2,dc=com"/>
...
</config:realms>
<config:realms delimiter="/" name="VP2Realm" securityUse="active">
<config:participatingBaseEntries name="dc=node2,dc=ibm1,dc=com"/>
<config:participatingBaseEntries name="dc=node3,dc=ibm2,dc=com"/>
...
</config:realms>
To get the realms defined, we need to create a file called addrealm.properties
realmName=racfRealm
securityUse=active
delimiter=/
addBaseEntry=o=a70zcorp,DC=BCBSSC
In this file value of realmName
is the name that you want to give to this realm and the value of addBaseEntry
is the one that you see as the value of Base Entry for that repository in the WAS Admin Console.
To add the realm, execute this task
$ ./ConfigEngine.sh wp-create-realm -DWasPassword=passw0rd -DparentProperties=/opt/wasprofiles/wp_profile/ConfigEngine/config/helpers/addrealm.properties
Once the build is successful, WebSphere Portal needs to be restarted.
NOTE: Not sure this step is needed. The next step is definitely needed though.
Now, the next step is to configure the base for users and accounts for this realm. Create a file modifyrealmparent.properties
realmName=racfRealm
realm.personAccountParent=ou=user,o=a70zcorp,DC=BCBSSC
realm.groupParent=ou=group,o=a70zcorp,DC=BCBSSC
realm.orgContainerParent=o=a70zcorp,DC=BCBSSC
Now execute the following task
$ ./ConfigEngine.sh wp-modify-realm-defaultparents -DWasPassword=passw0rd -DparentProperties=/opt/wasprofiles/wp_profile/ConfigEngine/config/helpers/modifyrealmparents.properties
Once again, restart WebSphere Portal for the settings to take effect.
If you skipped the previous command, you should start up here
Lastly, we have to enable WebSphere Portal to enable the full distinguished name login. Create a file modifyrealenabledn.properties
realmName=racfRealm
Now execute the following task
$ ./ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=passw0rd -DparentProperties=/opt/wasprofiles/wp_profile/ConfigEngine/config/helpers/modifyrealenabledn.properties
And yet again, restart WebSphere Portal for the settings to take effect.
At this point the realm is ready to be used. When creating the new virtual portal, the realm should be listed under the User Realm
option.
Once a realm has been identified, more base entries can be added to the realm. Create a file addrealmentry.properties
realmName=racfRealm
addBaseEntry=o=defaultWIMFileBasedRealm
addBaseEntry
is the base entry that you see as the value of Base Entry for that repository in the WAS Admin Console that you want to add.
Now execute the following task
$ ./ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=passw0rd -DparentProperties=/opt/wasprofiles/wp_profile/ConfigEngine/config/helpers/addrealmentry.properties
At this point you should be able to look at your <portal_home>/config/cells/<cell_name>/wim/config/wimconfig.xml
file and see the realm specified with two entries for config:participatingBaseEntries
- one for each base entry.
And yet again, restart WebSphere Portal for the settings to take effect.
To remove a defined realm, create a file called deleterealm.properties
deleteRealmName=racfRealm
In this file, the value of deleteRealmName
is the name of the realm that should be removed.
To remove the realm, execute this task
$ ./ConfigEngine.sh wp-delete-realm -DWasPassword=passw0rd -DparentProperties=/opt/wasprofiles/wp_profile/ConfigEngine/config/helpers/deleterealm.properties
Once the build is successful, WebSphere Portal needs to be restarted.
Q: When I attempt to add the realm, I get an error message Create realm failed. Baseentry could not be added
A: When you specified the value of addBaseEntry
in addrealm.properties
it didn't match the base entry of a repository that already exists. Check the Base Entry
values in your Federated Repositories configuration to make sure they match.
When a virtual portal is setup using only specific repositories, that means that those virtual portals will only be administerable through those repositories. Make sure you have a way to manage the virtual portal.
See more notes at http://jsturdevant.roughdraft.io/
Written with StackEdit.
I hope it is still useful. I wrote this up 7 years ago precisely because there wasn't much information I could find.