Configuring Security Access Manager | HCL Digital Experience

HCL Digital Experience can be integrated with IBM Security Access Manager to provide authentication services, authorization, and to link HCL Digital Experience's credential vault to the ISAM GSO Lockbox feature.

About this task

Authentication, Authorization and Credential Vault features can be configured in the following combinations:
  • Authentication can be configured either with or without the other features
  • Credential Vault integration can be configured either with or without the other features
  • Authorization cannot be configured without configuring Authentication.

As part of the Authentication integration, you can also configure HCL Digital Experience user provisioning to fully activate the created users as Security Access Manager users. By default, users that are created in LDAP by HCL Digital Experience are not Security Access Manager users. This configuration is necessary only if you do not have an enterprise Identity Management system and provisioning process that is integrated with IBM® Security Access Manager, and are using Digital Experience as your user creation tool.

Important information about authentication: To integrate HCL Digital Experience and IBM® Security Access Manager for authentication, you must create one or more junctions in WebSEAL that points to HCL Digital Experience. Starting with HCL Portal Version 8.0, the type of junction that is supported depends on your specific use case:
Table 1. Use cases for junction type

Read the following information to choose the type of junction to create based on your use case.
Use case Supported junction type
Simple use case
A single, logical HCL Digital Experience instance behind the WebSEAL layer, by using the default /wps context root. The HCL Digital Experience instance can be one of the following deployments:
  • A stand-alone server
  • A single cluster
  • A common set of Portal instances in a farm
 Either a transparent junction or a virtual host junction can be used. The junctions can be either TCP or SSL. They can use a TAI in WebSphere®, or generate LTPA tokens in WebSEAL for identity assertion.

Not all HCL Digital Experience URLs start with /wps. Therefore, if you use transparent junctions, you must configure multiple transparent junctions to get all requests passed back to HCL Digital Experience from WebSEAL. To avoid this complication, use a single virtual host junction.

Tip: If you plan to change the HCL Digital Experience context root, use virtual host junctions.
Other use cases
Anything other than a simple use case.
 The supported junction type for the general case is virtual host junctions. The virtual host junctions can be either TCP or SSL. They can use a TAI in WebSphere®, or generate LTPA tokens in WebSEAL for identity assertion.
Integrating WebSEAL and HCL Portal by using virtual portals:

Virtual Portals can be defined and identified in an incoming request by using either a token in the URL, or a virtual host name. If the URL token is used, it comes immediately after the servlet mapping of the URL, for example the portal or myportal token. If a virtual host name is used, then the host name for a request that targets the virtual portal has a different host name than requests to other virtual portals or the base portal.

When HCL Digital Experience, using the virtual hostname-defined virtual portals, is integrated behind WebSEAL as a proxy, the configuration is to have one virtual host junction in WebSEAL, per virtual portal in HCL Digital Experience (one to one in both directions). In addition, the virtual host junction host name in WebSEAL must be identical to the corresponding virtual portal host name on WebSphere® Portal. The virtual host junction itself can be defined by using either the virtual portal host name identical to the virtual host junction host name, or the real portal or HTTP server host name, as the backend server host (the value of the -h parameter on the junction definition). It is better to use the virtual portal host name because some operations (such as redirect calculations) depend on the value of the HOST header, and the -h parameter on the junction definition causes WebSEAL to set the HOST header to this value. If the virtual portal host name is used, then either a secondary, internal DNS resolution, or manipulation of the hosts file, must be used by WebSEAL to resolve that host name to the IP address of the HTTP Server or Portal host.

Choose the appropriate tasks to configure IBM® Security Access Manager below.