Migrate Security Access Manager

Migrate Security Access Manager

The portal migration process migrates the security configurations, including user registry, VMM settings, and the IBM WAS security setup, including any TAI configurations. However, there is no provision for the automatic migration of any WebSEAL junction definitions. Replace the old junction definitions with the new virtual host junction definitions.
The WebSphere Portal migration process cannot change the junction definitions in WebSEAL to point to the new server. It cannot switch from standard non-transparent or transparent junctions to the new virtual host junctions. Manually run these tasks within Security Access Manager.
The steps below assume created the new virtual host junction before deleting the old junctions. This approach assumes there are no detected conflicts to prevent the new junction from coexisting with the old junctions. A conflict might arise if the vhost_label value is the same between the new and old junctions. Try to avoid or work around these conflicts. If conflicts are unavoidable, delete the old junction before creating the new virtual host junction. Create a backup copy of the WebSEAL configuration file first so we can refer to it if necessary.

Install the latest version of TAI on the current version of WebSphere Portal server.

On the previous instance of WebSphere Portal:

Open the WebSEAL configuration file, and search for stanzas that define the junctions. For example:
[junction:junction_name]

Record the configuration value for each junction for future reference.

Save a backup copy of the WebSEAL configuration file.

Create the new virtual host junctions based on the junctions from the previous instance:
pdadmin> server task myinstance-webseald-WebSEAL-HostName virtualhost create -t type -h hostname [options] vhost-label

Mandatory parameters...

myinstance-webseald-WebSEAL-HostName Includes...

Configured name of a single WebSEAL instance, for example web1
Literal string -websealed-
Host name, for example, webseal.myco.com
For example...
web1-websealed-webseal.myco.com

To display the correct format of the server name...
pdadmin> server list

virtualhost vhost-label is the name for the virtual host junction, and must be unique within each instance of WebSEAL. Virtual host junctions are always mounted at the root of the WebSEAL object space. Because the junction resides in a protected object space, the label name must not contain the forward slash character (/).
-t type Whether the junction is encrypted (-t ssl) or not encrypted (-t tcp). Mandatory.when creating a virtual host junction.
-h hostname Backend server to which the junction connects. Generally the host name of the HTTP server that sits in front of WebSphere Portal.

The [options] includes the following parameters:

-p port Port number for the backend server to which the junction connects. If not specified, the default value is 80 for HTTP or 443 for HTTPS. It is best to specify this value explicitly in the junction creation command even if the default values are in use.
-v vhost[:port] Virtual host name and port number that defines the junction. WebSEAL maps incoming requests to this host name and port to this junction. If not specified, the values default to the -h hostname and -p port values.
-c header_type Inserts the Security Access Manager client identity in HTTP headers across the junction. The header_type argument can include any combination of the following Security Access Manager HTTP header types:

{iv_user|iv_user-l}
iv_groups
iv_creds
all

The header types must be comma-separated, and cannot have a space between the types. For example:
-c iv_user,iv_groups

Specifying -c all is the same as specifying...
-c iv_user,iv_groups,iv_creds

This parameter is valid for all junctions except for the type of local. The setting here depends on how we want the TAI running within WAS to operate. In certain modes, the TAI might be looking for the presence of one or more of these headers. The TAI looks for these headers to know that it must claim the request when interrogated by WAS security. This setting must be set to match what the TAI is looking for. Consult the WebSphere system administrator if we are in doubt as to how the TAI is configured.
-b Controls how WebSEAL passes authentication information to the backend server. Usually this setting depends on how we want the TAI to be configured in WebSphere to validate a trust relationship with WebSEAL. The usual option chosen is -b supply. See the ETAI installation and configuration documentation.
-k Controls whether WebSEAL includes its own session cookie in the request to the backend server. In some situations, sending the WebSEAL session cookie to the backend server is necessary. This action is necessary to support single sign-on from WebSphere Portal to other backend services where WebSEAL also protects those backend services.

Junctions to WebSphere Portal, whether direct or through an HTTP server, do not support the -q option the query_contents function. Query_contents is not possible on WebSphere Portal
The following command creates a virtual host TCP junction, on the web1 WebSEAL instance running on host webseal.myco.com, for the virtual host name portalvhost.myco.com, running on port 80, and requiring a TAI in WebSphere Application Server. The virtual host junction is labeled vhost_junction_portal_1. The virtual host junction host name is mapped in DNS to the WebSEAL server. The portal or http server is running on host portal.myco.com and is using port 8080:
pdadmin> server task web1-webseald-webseal.myco.com virtualhost create -t tcp -v portalvhost.myco.com:80 -h portal.myco.com -p 8080 -c all -k -b supply vhost_junction_portal_1

Delete the old junctions...
server task instance_name -webseal-host delete junction_point

Parent Add-ons, features, and third-party integration tasks
Related tasks:
Configure Security Access Manager for authentication only
Configure Security Access Manager for authentication, authorization, and the Credential Vault
Administer WebSEAL

myinstance-webseald-WebSEAL-HostName	Includes... Configured name of a single WebSEAL instance, for example web1 Literal string -websealed- Host name, for example, webseal.myco.com For example... web1-websealed-webseal.myco.com To display the correct format of the server name... pdadmin> server list
virtualhost	vhost-label is the name for the virtual host junction, and must be unique within each instance of WebSEAL. Virtual host junctions are always mounted at the root of the WebSEAL object space. Because the junction resides in a protected object space, the label name must not contain the forward slash character (/).
-t type	Whether the junction is encrypted (-t ssl) or not encrypted (-t tcp). Mandatory.when creating a virtual host junction.
-h hostname	Backend server to which the junction connects. Generally the host name of the HTTP server that sits in front of WebSphere Portal.

-p port	Port number for the backend server to which the junction connects. If not specified, the default value is 80 for HTTP or 443 for HTTPS. It is best to specify this value explicitly in the junction creation command even if the default values are in use.
-v vhost[:port]	Virtual host name and port number that defines the junction. WebSEAL maps incoming requests to this host name and port to this junction. If not specified, the values default to the -h hostname and -p port values.
-c header_type	Inserts the Security Access Manager client identity in HTTP headers across the junction. The header_type argument can include any combination of the following Security Access Manager HTTP header types: {iv_user\|iv_user-l} iv_groups iv_creds all The header types must be comma-separated, and cannot have a space between the types. For example: -c iv_user,iv_groups Specifying -c all is the same as specifying... -c iv_user,iv_groups,iv_creds This parameter is valid for all junctions except for the type of local. The setting here depends on how we want the TAI running within WAS to operate. In certain modes, the TAI might be looking for the presence of one or more of these headers. The TAI looks for these headers to know that it must claim the request when interrogated by WAS security. This setting must be set to match what the TAI is looking for. Consult the WebSphere system administrator if we are in doubt as to how the TAI is configured.
-b	Controls how WebSEAL passes authentication information to the backend server. Usually this setting depends on how we want the TAI to be configured in WebSphere to validate a trust relationship with WebSEAL. The usual option chosen is -b supply. See the ETAI installation and configuration documentation.
-k	Controls whether WebSEAL includes its own session cookie in the request to the backend server. In some situations, sending the WebSEAL session cookie to the backend server is necessary. This action is necessary to support single sign-on from WebSphere Portal to other backend services where WebSEAL also protects those backend services.