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 performs authentication checks on all requests for resources before passing those requests across a junction to the back-end server.
Starting with WebSphere® Portal Express® version 8.0, the type of junction supported between the front-end WebSEAL server and a back-end WebSphere Portal Express server is the virtual host junction. Prior releases supported the traditional, non-transparent WebSEAL junctions. With the proliferation of WebSphere Portal Express URLs, the virtual host junction is now the most efficient way to make a WebSphere Portal Express 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.yourco.com/junction1/wps/myportal. A not apparent 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 WebSphere Portal Express 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.yourco.com. This junction is only an example; you can use any host name that fits within your domain. 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 Tivoli® Access Manager handles the user authentication, and a Trust Association Interceptor (TAI) is used by WebSphere Application Server and WebSphere Portal Express to accept the identity of the user as asserted by WebSEAL.
The identity of the user must be passed to the TAI in a header called iv-user, which is inserted by WebSEAL into the request that is sent from WebSEAL to the WebSphere Application Server and the WebSphere Portal Express servers. The junction creation option to set this up 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 that is supported by the TAI.
For more details and options about how to configure junctions between WebSEAL with WebSphere Application Server and WebSphere Portal Express, including other options for specifying the WebSEAL server identity, use the WebSEAL Administration Guide and to the documentation for the HTTP Server that you are using with WebSphere Application Server.
The junctions between WebSEAL and WebSphere Application Server and WebSphere Portal Express 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, WebSphere Application Server, and WebSphere Portal Express. However, encrypted junctions require additional administration to move the necessary signing certificates between the systems, and also have a performance cost. If you are not comfortable that your network between the firewalls is secure against unauthorized access and observation, you should use encrypted junctions between WebSEAL and WebSphere Application Server/WebSphere Portal Express. If you are comfortable that your network is secure against unauthorized access and observation, especially for traffic across an inner firewall, you can use unencrypted junctions between WebSEAL and WebSphere Application Server/WebSphere Portal Express.
Setting up the WebSEAL-WebSphere Application Server/WebSphere Portal Express junction over SSL requires that you configure WebSphere Application Server and the HTTP server that is used by WebSphere Application Server to accept inbound SSL traffic and route this traffic correctly to WebSphere Application Server and WebSphere Portal Express. 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 Application Server and WebSphere Portal Express, you can also choose to have WebSEAL identify and authenticate itself to WebSphere Application Server and the TAI using its own client-side certificate. In this case, it is possible to configure the TAI to not do any further validation of 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, you can identify the WebSEAL server to the TAI using a Basic Authentication (BA) header. In this case a password will be placed into the BA header, and also configured into the TAI. This 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 will provide additional security by protecting this BA header from observation, but the TAI will still rely 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 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 that is configured into WebSEAL from the webseald-instance.conf file, on the basicauth-dummy-passwd property. The password in the webseald-instance.conf file must match the password for the ID that is specified on the com.ibm.websphere.security.webseal.loginid property of the TAI startup parameters in the WebSphere Integrated Solutions Console. For example, if you specify com.ibm.websphere.security.webseal.loginid=mistered on the TAI startup parameters, and the password for mistered is wilbur, then you must specify wilbur on the basicauth-dummy-passwd property in webseald-instance.conf on the WebSEAL server.