WebSEAL junctions: Planning
A junction is an HTTP or HTTPS connection between a front-end WebSEAL server and a back-end web server. WebSEAL leverage a security managers such as IBM Security Verify Access to do authentication checks on requests for resources, passing those requests across a junction to the back-end web application server. The junction acts as a single point of access into a web application network. Example route:
NetScaler ==> WebSEAL ==> Web server ==> WebSphere Portal
Supported junction types between the front-end WebSEAL server and a back-end WebSphere Portal server are:
type Description Transparent junction For simple use cases such as a single logical instance of portal using default /wps context root, where logical instance can be a server, cluster, or farm nodes. Virtual host junction Supported for all use cases. With the proliferation of portal URLs, this junction is the recommended way to make a WebSphere Portal server work behind a WebSEAL proxy.
Transparent junctions use an existing token in the URL to identify the junction. For example, the /wps token in /wps/myportal. A non-transparent junction has a token in the URL that corresponds to the junction in WebSEAL. For example...
http://webseal.host.myco.com/myjunction/wps/myportal
The problem with both of these methods is that 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...
myjunction.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. An interceptor is used by WebSphere Application Server and WebSphere Portal to accept the identity of the user as asserted by WebSEAL. To properly secure the WebSphere portal system against an attack, the TAI must still authenticate the WebSEAL server. Only legitimately presented request that pass through that WebSEAL server are accepted. There are different ways to configure this authentication between WebSEAL and the trust association interceptor (TAI) in WAS.
Non-encrypted junctions
The identity of the user is 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 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.
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 set in webseald-instance.conf must match the password for the ID specified in the WAS admin console for property...
com.ibm.websphere.security.webseal.loginid
For example, if we specify...
com.ibm.websphere.security.webseal.loginid=myid
...on the WAS TAI startup parameters, and the password for myid is mypassword, then we must specify mypassword for the basicauth-dummy-passwd property in webseald-instance.conf on the WebSEAL server.
Encrypted junctions
For more details and options about how to configure junctions between WebSEAL with 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 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 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 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 you choose to use encrypted junctions between WebSEAL and 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 you choose not to use client-side certificates to identify the WebSEAL server, or if you 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.
xmlaccess.sh considerations
By default, xmlaccess.sh cannot access WebSphere Portal through a WebSEAL junction. To enable xmlaccess.sh to access 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 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.