Plan for WebSEAL junctions
A junction acts as a single point of access into a web application network. A junction is an HTTP or HTTPS connection between a front-end WebSEAL server and a back-end web application server. WebSEAL does authentication checks on all requests for resources before it passes those requests across a junction to the back-end server. Supported junction types between the front-end WebSEAL server and a back-end HCL WebSphere Portal server are:
Virtual host junctions This junction type is generally supported for all use cases. Transparent junctions Support for Transparent junctions with HCL WebSphere Portal is limited to a simple use case. For example, one HCL WebSphere Portal logical instance that uses the default /wps context root. The logical instance might be one server or cluster or set of related farm nodes that run a single logical instance of a Portal website, which might include virtual portals. Anything more complex than this simple use case requires the use of Virtual host junctions.
With the proliferation of HCL WebSphere Portal URLs, the virtual host junction is now the most efficient way to make a HCL WebSphere Portal server work behind a WebSEAL proxy. All discussions around encryption, Trust Association Interceptor (TAI) versus LTPA and other setup options continue to be applicable. The difference is the overall junction type, which determines how the junction is visible to the users.
A traditional non-transparent junction has a token in the URL that corresponds to the junction in WebSEAL. For example, the URL might be...
http://webseal.hostname.myco.com/junction1/wps/myportal
A transparent junction uses an existing token in the URL to identify the junction; for example, it uses the /wps token in /wps/myportal. The problem with both of these methods is that HCL WebSphere Portal has many URLs and not all of them start with /wps. They are also difficult to configure to use a consistent prefix.
Virtual host junctions use a virtual host name to identify the junction. To identify the junction, the host name might be...
junction1.webseal.hostname.myco.com
The junction is then defined in WebSEAL to use the incoming host name, instead of a URL token, to identify the junction and the corresponding back-end servers.
In the configuration described here, the WebSEAL component of Security Access Manager handles the user authentication. A TAI is used by WebSphere Application Server and HCL WebSphere Portal to accept the identity of the user as asserted by WebSEAL.
To properly secure the WAS and HCL WebSphere Portal system against an attack, the TAI must still authenticate the WebSEAL server. So that only requests that are legitimately presented through that WebSEAL server are accepted. There are different ways to configure this authentication between WebSEAL and the TAI in WAS. We can choose between the different ways to configure depending on how much effort and performance we want to put into securing the network. The decisions that you make determines how we set up the junctions between the WebSEAL server and HCL WebSphere Portal.
By default, xmlaccess.sh cannot access HCL WebSphere Portal through a WebSEAL junction. To enable xmlaccess.sh to access HCL WebSphere Portal through a WebSEAL junction, use Security Access Manager to define the configuration URL (/wps/config) within the junction as unprotected. Use the WebSEAL documentation for specific instructions about defining separate URLs within the junction and assigning separate ACLs to these URLs. After the configuration URL is defined as unprotected, only HCL WebSphere Portal enforces access control to this URL. Other resources that are protected within the WebSEAL junction (for example, the wps/myportal URL) are still protected by WebSEAL.
Nonencrypted junction using Basic Authentication
The identity of the user must be passed to the TAI in a header called iv-user. The header is inserted by WebSEAL into the request sent from WebSEAL to the WAS and the HCL WebSphere Portal servers. The junction creation option to pass the user identity is -c iv-user. While WebSEAL can be configured to pass the user identity in other ways, the iv-user header is the only one supported by the TAI.
Advanced junction configurations
For more details and options about how to configure junctions between WebSEAL with WAS and HCL WebSphere Portal, including other options for specifying the WebSEAL server identity, use the WebSEAL Administration Guide and to the documentation for the HTTP Server we are using with WAS.
The junctions between WebSEAL and WAS and HCL WebSphere Portal can be configured to be encrypted or not. Encrypted junctions enhance security by making sure that no one can eavesdrop on information that is flowing between WebSEAL, WAS, and HCL WebSphere Portal. However, encrypted junctions require more administration to move the necessary signing certificates between the systems, and also have a performance cost. If we are not comfortable the network between the firewalls is secure against unauthorized access and observation, use encrypted junctions between WebSEAL and WAS/Portal. If we are comfortable the network is secure against unauthorized access and observation, especially for traffic across an inner firewall, use unencrypted junctions between WebSEAL and WAS/Portal.
Setting up the WebSEAL WAS/Portal junction over SSL requires that we configure WAS and the HTTP server used by WAS to accept inbound SSL traffic and route this traffic correctly to WAS and HCL WebSphere Portal. This process includes importing the necessary signing certificates into at least the WebSEAL certificate keystore, and possibly also the HTTP server certificate keystore.
If we choose to use encrypted junctions between WebSEAL and WAS and HCL WebSphere Portal, we can also choose to have WebSEAL identify and authenticate itself to WAS and the TAI using its own client-side certificate. In this case, we can configure the TAI to not further validate the WebSEAL server, relying on the mutual SSL connection to supply a trustable identity for the WebSEAL server.
If we choose not to use client-side certificates to identify the WebSEAL server, or if we choose not to use an SSL junction, we can identify the WebSEAL server to the TAI using a Basic Authentication (BA) header. In this case, a password is placed into the BA header, and also configured into the TAI. This action represents a "shared secret" that only the TAI and the WebSEAL server know, which allows the TAI to trust that it really is the WebSEAL server that is asserting the user's identity, and the TAI can trust it. In this case, using an SSL junction provides more security by protecting this BA header from observation, but the TAI still relies on the BA header for identifying the WebSEAL server.
To set up the junction to use the Basic Authentication header to identify the WebSEAL server, use the -b supply option on the junction creation command. This option causes WebSEAL to build the BA header using the user's user ID (which is ignored by the TAI, in favor of the iv-user header) and the password configured into WebSEAL from the webseald-instance.conf file, on the basicauth-dummy-passwd property. The password in webseald-instance.conf must match the password for the ID specified on the...
com.ibm.websphere.security.webseal.loginid
...property of the TAI startup parameters in the WAS admin console. For example, if specified...
com.ibm.websphere.security.webseal.loginid=mistered
...on the TAI startup parameters, and the password for mistered is wilbur, then we must specify wilbur on the basicauth-dummy-passwd property in webseald-instance.conf on the WebSEAL server.
Parent Plan for external security managers
Related information
WebSEAL Administration Guide