+

Search Tips   |   Advanced Search

Configure IBM Security Verify Access

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

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, we can also configure HCL WebSphere Portal user provisioning to fully activate the created users as Security Access Manager users. By default, users created in LDAP by HCL WebSphere Portal are not Security Access Manager users. This configuration is necessary only if we do not have an enterprise Identity Management system and provisioning process that is integrated with IBM Security Verify Access, and are using HCL WebSphere Portal as the user creation tool.

To integrate HCL WebSphere Portal and IBM Security Verify Access for authentication, create one or more junctions in WebSEAL that points to HCL WebSphere Portal. Starting with HCL WebSphere Portal v8.0, the type of junction supported depends on the specific use case:

Use case Supported junction type

Simple use case

A single, logical HCL WebSphere Portal instance behind the WebSEAL layer, using the default /wps context root. The HCL WebSphere Portal 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. 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 WebSphere Portal URLs start with /wps. For transparent junctions, configure multiple junctions to get all requests passed back to HCL WebSphere Portal from WebSEAL. To avoid this complication, use a single virtual host junction.

To change the HCL WebSphere Portal 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.

Virtual Portals can be defined and identified in an incoming request 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 WebSphere Portal, 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 WebSphere Portal (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 HCL WebSphere Portal. The virtual host junction itself can be defined 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 Verify Access:


Parent Security Access Manager