Configure ISAM for authorization

Configure ISAM for authorization | HCL Digital Experience

We can configure IBM Security Access Manager (ISAM) for both authentication and authorization. If we configure both, configure ISAM for authentication first. Using ISAM only for authorization is not supported. Configuring ISAM for authorization delegates decisions about what users or groups are granted access to Portal resources. This action is also called externalizing the access control for Portal resources. Normally these decisions are made by consulting the principal-to-role mappings stored in the Portal database. The following procedure configures Portal to obtain access control decisions for resources from ISAM instead rather than the Portal database. The procedure includes:

Configuration of properties that determine how the Portal resources are represented in the ISAM protected object namespace.
Configuration of how permissions are represented in the ISAM access control lists.

After this task is run, we can use the Resource Permissions portlet or xmlaccess.sh to place portal resources such as pages and portlets under ISAM control.
With an external security manager in a cluster environment and across mixed nodes additional configuration is required. Complete any ESM configuration after completing all other configuration tasks, including ensuring that the cluster is functional.

Implementation details of externalized access control

When Portal resources are moved to ISAM access control, portal creates entries corresponding to individual roles on the externalized resources in the ISAM protected object space. The roles in this case are the Portal roles on Portal resources; for example:

User@Welcome page
Administrator@Some Portlet

Access Control Lists (ACLs) are attached to these ISAM objects. The ACLs use the PDAction and PDActionGroup property values to determine what users are granted the various roles. portal security code queries ISAM for the users that have the PDAction within PDActionGroup permission on entries in the ISAM object space, and interprets that as granting the user the corresponding Portal role on the resource.
Any subset of Portal resources can be placed under external access control. Portal can maintain internal control of other resources.
There are multiple entries in the ISAM object space for every externalized resource, one entry per existing Portal role on that resource. In portal there are multiple different role types; for example, User, Privileged User, Editor, Manager, Administrator. Not every Portal role might be instantiated for every resource instance, and entries in ISAM exist only if the corresponding actual role on that Portal resource exists.

Format of the entries in ISAM:

By default, the entries in the ISAM object space have the following format:
PDRoot/Portal_Role@Portal_Resource[/EACappname/EACserverName/EACcellName]

For example:
/WP95/Administrator@VIRTUAL_EXTERNAL_ACCESS_CONTROL[/wps/WebSphere_Portal/Cell01

The ISAM object space entries might be different from the default, depending on the following properties:

If the reorderRoles property is set to true, the the role resource displays as...
Portal_Resource@Role
For example:
VIRTUAL_EXTERNAL_ACCESS_CONTROL@Administrator

Set all three of the EACserverName, EACcellName, and EACappname properties; otherwise, they are not included in the object space entries.

Procedure

Clustered environments: Complete this step on all nodes.
To validate that the PdPerm.properties file is correct and that communication between portal and the ISAM server works:
wp_profile_root/ConfigEngine
./ConfigEngine.sh validate-pdadmin-connection -DWasPassword=foo -Dwp.ac.impl.PDAdminPwd=foo

If the task does not run successfully: Run the run-svrssl-config task to create the properties file. For information, refer to Create the PdPerm.properties file. Then, run the validate-pdadmin-connection task again. If the task is not successful after a second attempt, do not proceed with any subsequent steps. The fact that the task does not run successfully indicates that the portal cannot connect to the ISAM server. Troubleshoot the connectivity issue between the portal instance and the ISAM server.

Update the Namespace management parameters in the wkplc_comp.properties file

To further distinguish externalized portal role names from other role names in the namespace, set all of the following to the Namespace context information:

wp.ac.impl.EACserverName
wp.ac.impl.EACcellName
wp.ac.impl.EACappname

For wp.ac.impl.reorderRoles, type false to keep the role order or true to reorder the roles by resource type first.

Update the following parameters in the wkplc_comp.properties file; go to the Portal authorization parameters heading:

wp.ac.impl.PDRoot- root object space name in the ISAM namespace for portal resource entries. For example: /WPv95
All Portal roles are installed with this entry. For multiple profiles and portal instances that all share a common ISAM instance, choose a unique name for each root object space entry. This unique name helps to easily distinguish the resources for different instances. Or use a common PDRoot value for all Portal instances so that all Portal roles from any instance have a common parent. We can then use the EACappname parameter to distinguish between instances. If it better suits the administration models, we can also mix these two approaches, by using a common PDRoot value for some instances, and unique PDRoot values for others.

For wp.ac.impl.PDAction, type the Custom Action created by the ISAM external authorization plug-in. The combination of the action group and the action determines the ISAM permission string. The permission string is used to assign membership to externalized portal roles. You might want to check with your ISAM administrator to determine what they want the PDActionGroup and PDAction values to be.
After creating ACLs in ISAM by using a PDAction and PDActionRoot value, these values must remain constant. Changing these values after we create ACLs that us the original settings, results in losing permissions.

For wp.ac.impl.PDActionGroup, type the Custom Action group that is created by the ISAM external authorization plug-in. The combination of the action group and the action determines the ISAM permission string. The permission string is used to assign membership to externalized portal roles.
After creating ACLs in ISAM by using a PDAction and PDActionRoot value, these values must remain constant. Changing these values after we create ACLs that us the original settings, results in losing permissions.

For wp.ac.impl.PDCreateAcl, set the value to true to automatically create and attach an ISAM ACL when portal externalizes the roles for a resource. Set the value to false to not create and attach a ISAM ACL when portal externalizes the roles for a resource. In this case, the ISAM Administrator must manually create and attach ACLs to the object space entries for the externalized portal resources and roles. Any ACLs created manually in this way, must use the PDAction and PDActionGroup values in order for the permissions to be found.

Save the changes to the properties file.

Enable ISAM authorization:
./ConfigEngine.sh enable-tam-authorization -DWasPassword=foo

Clustered note: In a clustered environment, complete this step on all nodes. The WasPassword value is the dmgr administrative password.
If the task does not run successfully: Verify the values in wkplc_comp.properties are valid.

Stop and restart the appropriate servers to propagate the changes.

Results

After after completing the authorization procedure, we can then use the portal administration tools (the Resource Permission portlet or XMLAccess scripting) to externalize the access control decisions for Portal resources. For any resources placed under IBM Security Manager access control, the ISAM protected object space contains entries for roles in the following format
PortalServer_root/role_name/application_name/server_name/cell_name
For example if...

wp.ac.impl.PDRoot was Portal_Instance_1
wp.ac.impl.EACcellName was Cell_A
wp.ac.impl.EACserverName was Server_B
wp.ac.impl.EACappName was Application_C

... then an object space entry corresponding to a Portal role name approximately looks like...
Portal_Instance_1/Administrator@VIRTUAL_EXTERNAL_ACCESS_CONTROL/Application_C/Server_B/Cell_A

Where the Portal role name Administrator@VIRTUAL_EXTERNAL_ACCESS_CONTROL is simplified from its actual appearance, which might include a generated UUID value or custom unique name.
The EACappname, EACserverName, and EACcellName must all be specified, or none of them appears in the ISAM object space entries.