Configure TAM to perform authentication only

 

+
Search Tips   |   Advanced Search

 

Contents

  1. Overview
  2. Configure TAM to perform authentication for WebSphere Portal
  3. WebSphere Application Server with WebSEAL Example
  4. WebSEAL over SSL and WebSEAL over LTPA
  5. WebSEAL junctions
  6. Nonencrypted junction using Basic Authentication

 

Overview

IBM WebSphere Portal runs on IBM WebSphere Application Server, which can use Trust Association Interceptors (TAIs) to provide third-party authentication.

If you use Tivoli Access Manager (TAM) to perform authorization for the portal, also use TAM to perform authentication for the portal. Using TAM to perform only authorization is not supported.

 

Configure TAM to perform authentication for WebSphere Portal

This procedure requires that you be familiar with WebSEAL administration concepts as presented in the WebSEAL Administrator's Guide.

This example assumes that HTTP Server is the Web server.

The term pdadmin refers to a command line utility that supports TAM administrative functions.

If you experience problems while performing this procedure, enable tracing to help troubleshoot. From the administrative console, click...

Troubleshooting | Logs and Trace | WebSphere Portal | Diagnostic Trace

 

Procedure

  1. Install and configure WebSphere Portal, the database software that will be used with WebSphere Portal, the LDAP Directory, and TAM.

  2. WAS, WebSphere Portal, and TAM will share the same LDAP directory.

    The TAM configuration tool secures the LDAP namespace by modifying the LDAP Access Control List of all suffixes that are defined. This may include the suffixes that are used by WebSphere Portal to store users and groups.

    To avoid problems when WebSphere Portal searches for users, use the administrative console to verify that a BIND DN and BIND DN password exist.

    This BIND DN and password must have sufficient access rights within the directory (at least under the subtree that is specified by the BaseDN) to do searches in both the user and group subtrees within the directory.

    When the directory is secured, WAS must have an identity that can read from the directory. WAS can use an identity that is already set up with the necessary read permission in the ACL of the directory, or we can add a new identity for WAS to the ACL for the directory. Setting up new identities in the ACL for the directory is a directory-specific task.

  3. Ensure that security for the portal has been enabled.

  4. If you plan to use an SSL junction, follow the instructions in steps 1-3 of Setting up SSL for WebSphere Portal .

    A junction is an HTTP or HTTPS connection between a front-end WebSEAL server and a back-end Web application server. A junction acts as a single point of access into a Web Application Network. WebSEAL performs authentication checks on all requests for resources before passing those requests across a junction to the back-end server.

    In the configuration described here, the WebSEAL component of TAM handles the user authentication, and a TAI is used by WAS and WebSphere Portal to accept the identity of the user as asserted by WebSEAL.

  5. Install and configure WebSEAL.

  6. If you plan to use an SSL junction, do the following steps:

    1. Use the IBM Key Management utility to load the Web server certificate into the keyring for the appropriate instance of WebSEAL.

    2. Restart WebSEAL.

  7. Create the trusted user account in TAM.

    This is the ID and password that WebSEAL uses to identify itself to WAS.

    To prevent potential vulnerabilities, do not use the sec_master or wpsadmin users for the trusted user account. The trusted user account should be for the TAI only.

    On the TAM machine, enter the following commands on the pdadmin command line:

    pdadmin> user create webseal_userid webseal_userid_DN firstname surname password 
    pdadmin> user modify webseal_userid account-valid yes 

  8. Verify connectivity to TAM by running validate-pdadmin-connection.

    1. Make a backup copy of...

      portal_server_root/config/wpconfig.properties

    2. Edit...

      portal_server_root/config/wpconfig.properties

      ...and set the following values in the Advanced Security Configuration section

      Do not change any settings other than those specified in these steps.

      Use / instead of \ for all platforms.

      Input Description
      PDAdminId User ID for the administrative TAM user.
      PDAdminPw Password for the administrative TAM user.
      PDPermPath Location of the TAM AMJRTE properties file.

    3. Save the file.

    4. Create the AMJRTE property files:

      ./WPSconfig.sh run-svrssl-config -DPdAdminPw=password

      i5/OS:

      WPSconfig.sh -profileName profile_root run-svrssl-config -Dpassword_property_key=password_value

      This command creates two files in...

        /usr/IBM /WebSphere/AppServer/java/jre/PolicyDirector/PdPerm.properties
        /usr/IBM /WebSphere/AppServer/java/jre/lib/security/PdPerm.ks

      If you get error messages indicating host/port of policy server cannot be found, try creating the files by hand...

      If these files do not exist, the validate-pdadmin-connection configuration task will fail.

    5. Start server1 and stop WebSphere_Portal. For a non-clusted environment...

      cd was_profile_root/bin
      ./startServer.sh server1
      ./stopServer.sh WebSphere_Portal -user admin_userid -password admin_password

      For a clustered environment, use the dmgr console.

    6. Run validate-pdadmin-connection

      cd portal_server_root/config
      ./WPSconfig.sh validate-pdadmin-connection -DPDAdminPw=password

      i5/OS:

      WPSconfig.sh -profileName profile_root validate-pdadmin-connection -Dpassword_property_key=password_value

      If the validate-pdadmin-connection configuration task failed issuing the message...

      Cannot contact server

      ...the validity of the PDAdmin ID and password values need to be verified in the wpconfig.properties file.

      If you get the error message...

      java.io.FileNotFoundException

      ...this indicates that the task failed on a new WAS and WebSphere Portal installation so that the PDPerm.properties file was not found. Recovery is covered in the next step. Here is the error message in detail:

      Wrappered Exception:
      java.security.PrivilegedActionException: java.io.FileNotFoundException: 
         C:\WebSphere\AppServer\java\jre\PdPerm.properties 
         (The system cannot find the path specified)     
      [
      HPDJA0108E   Invalid argument: Null configuration URL.
      ]
      

    7. If the validate-pdadmin-connection task succeeded, skip to the enable-tam-tai task..

      If the validate-pdadmin-connection task failed because the file PDPerm.properties was not found, do the following:

      1. Edit...

        portal_server_root/config/wpconfig.properties

        and enter the appropriate values in the Advanced Security Configuration section of the file. Do not change any settings other than those specified in these steps.

        Input Description
        PDServerName Unique application name used to create a new Tivoli server in the Access Manager Policy Server. This server represents the WebSphere Portal JVM in the pdadmin server list command.

        If a server with the same name appears in the server list command, the SvrSslCfg command will fail.

        PDAdminId The user ID for the administrative TAM user.
        PDAdminPw The password for the administrative TAM user.
        PDPermPath Location of the TAM AMJRTE properties file.
        SvrSslCfgPort Configuration port for the application name.
        SvrSslCfgMode Configuration mode of the SvrSslCfg command.
        TamHost Defines the TAM Policy Server used when running PDJrteCfg.
        PDPolicyServerList Defines a hostname, port, and priority combinations for yourTAM Policy servers used when running SvrSslCfg.
        PDAuthzServerList Defines a hostname, port, and priority combination for yourTAM authorization servers.
        PDKeyPath Stores encryption keys used for the SSL communication between AMJRTE and TAM.

      2. Save the file.

      3. Start server1 and stop WebSphere_Portal. For non-clustered...

        cd was_profile_root/bin
        ./startServer.sh server1
        ./stopServer.sh WebSphere_Portal -user admin_userid -password admin_password

        For clustered, cycle server1 and WebSphere_Portal with dmgr.

      4. cd portal_server_root/config.

      5. Enter the following command to run the appropriate configuration task for the specific OS:

        If the configuration task fails, validate the values in the wpconfig.properties file.

  9. Run the enable-tam-tai configuration task to create a WebSEAL junction.

    This task can create a TCP or an SSL junction. Options for creating junctions might vary depending on the environment. Provide all of the following information, noting that the task will attempt to create or overwrite a WebSEAL junction name in the JunctionPoint property.

    If you already created or will manually create a TCP, SSL or LTPA junction, specify a junction point that does not currently exist. You may optionally delete the junction created by the enable-tam-tai task in the future.

    1. Edit...

      portal_server_root/config/wpconfig.properties

      ...and enter the appropriate values in the Advanced Security Configuration section of the file. Do not change any settings other than those specified in these steps.

      Input Description
      PDAdminId User ID for the administrative TAM user.
      JunctionPoint WebSEAL junction point to the WebSphere Portal profile.
      JunctionType Type of junction to be created in TAM. Accepted values are tcp and ssl.
      PDAdminPw Password for the administrative TAM user.
      PDPermPath Location of the TAM AMJRTE properties file.
      WebSealInstance Specifies the WebSEAL instance used to create the junction.
      TAICreds Headers inserted by WebSEAL that the TAI uses to identify the request as originating from WebSEAL.
      WebSealHost Optional parameter that sets the WebSEAL TAI's hostnames parameter.
      WebSealPort Optional parameter that sets the WebSEAL TAI's ports parameter.
      WpsHostName (set to fully qualified hostname) Fully-qualified URL to WebSphere Portal.
      WpsHostPort Port number used to access the host machine identified by the WpsHostName property.
      WebSealUser (for tcp junctions only) Reverse proxy identity used when you create a TCP junction.
      BaUserName (for ssl junctions only) Reverse proxy identity used when you create an SSL junction.
      BaPassword (for ssl junctions only) When you create an SSL junction, we can provide a password to the identity representing the reverse proxy on every request.

    2. Save the file.

    3. Start server1 and stop WebSphere_Portal. For non-clustered environment...

      was_profile_root/bin
      ./startServer.sh server1
      ./stopServer.sh WebSphere_Portal -user admin_userid -password admin_password

      For clustered environment, use the dmgr console.

    4. Run enable-tam-tai

      cd portal_server_root/config.
      ./WPSconfig.sh enable-tam-tai -DPDAdminPw=password -DBaPassword=password

      i5/OS:

      WPSconfig.sh -profileName profile_root enable-tam-tai -Dpassword_property_key=password_value

      If the configuration task fails, validate the values in the wpconfig.properties file.

  10. If you created a TCP junction in the previous step, go to the WebSEAL machine and edit the webseald-instance.conf file for the appropriate WebSEAL instance. An example is webseald-default.conf. This sets the basicauth-dummy-passwd value to the password for the ID that WebSEAL uses to identify itself to WAS. This user ID and password were created in an earlier step. Stop and start the WebSEAL server before continuing.

  11. The length of the generated portal URLs may cause problems if the WebSEAL instance is on the Windows platform. Edit the webseald-instance.conf file and change the process-root-requests property value to filter to avoid problems with WebSEAL processing.

  12. Several portlets, including the Resource Permissions portlet and the productivity components editors, use relative Javascript within the portlet or component. These portlets and components will not function correctly when accessed through a WebSEAL junction. For this Javascript to be interpreted and followed correctly, WebSeal must be configured to insert the junction point into the Javascript. One way to accomplish this is through the use of the JMT table function in WebSEAL. To enable the JMT table function, define an ASCII text file called jmt.conf. The location of this file is specified in the [junction] stanza of the webseald-instance.conf configuration file:

    jmt-map = lib/jmt.conf

    The format for data entry in the table consists of the junction name, a space, and the resource location pattern. We can also use wildcard characters to express the resource location pattern. Note that jmt.conf resides in: Access Manager_install_root/PDweb/www-default/lib/. In the following example of the junction mapping configuration file, two back-end servers are junctioned to WebSEAL at /jctA and /jctB:

    /jctA /documents/release-notes.html
    /jctB /wps/*

    ...where jctB is the junction for WebSphere Portal.

    See the WebSEAL Administrator's Guide for more information.

  13. Optional If you would like to enable automatic user provisioning to TAM, follow this step.

  14. Optional

    If you enabled automatic user provisioning to TAM, you have already imported WebSphere Portal users and may skip this step. Import WebSphere Portal users and groups into TAM by entering the following commands on the TAM administrative command line, where wpsadmin is the user ID for the portal administrator, and wpsadmins is the portal administrators group name. The fully distinguished names of these user and group IDs will vary depending on the LDAP settings.

    user import wpsadmin uid=wpsadmin,cn=users,dc=ibm,dc=com
    user modify wpsadmin account-valid yes
    group import wpsadmins cn=wpsadmins,cn=groups,dc=ibm,dc=com

  15. Verify connectivity to TAM by running the validate-pdadmin-connection configuration task.

    1. Edit...

      portal_server_root/config/wpconfig.properties

      ...and enter the appropriate values in the Advanced Security Configuration section. Do not change any settings other than those specified in these steps.

      Input Description
      PDAdminId The user ID for the administrative TAM user.
      PDAdminPw The password for the administrative TAM user.
      PDPermPath Location of the TAM AMJRTE properties file.

    2. Save the file.

    3. Start server1 and stop WebSphere_Portal. For a non-clustered environment...

      cd was_profile_root/bin
      ./startServer.sh server1
      ./stopServer.sh WebSphere_Portal -user admin_userid -password admin_password

      For a clustered environment, use the dmgr console.

    4. Validate connection...

      cd portal_server_root/config
      ./WPSconfig,sh validate-pdadmin-connection -DPdAdminPw=password

      If the configuration task fails, validate the values in the wpconfig.properties file.

  16. Use the administrative console to review and save the trust association and interceptor updates:

    1. In the administrative console, click...

      Security | Global security | Authentication | Authentication mechanisms |LTPA | Trust Association

    2. Under General Properties, find Enable trust association. If it's box is checked then the trust association is already enabled. If it is not checked, select the check box and click OK to enable trust association.

    3. Click Save at the top of the screen under Message(s). Click Save again when prompted, to confirm the changes.

    4. Click...

      Security | Global security | Authentication | Authentication mechanisms | LTPA | Trust Association | Interceptors

    5. The following interceptor should be listed:

      com.ibm.ws.security.web.WebSealTrustAssociationInterceptor  

      If it is not listed, review the ConfigTrace.log for errors encountered during the enable-tam-tai configuration task, and re-run the task if necessary.

    6. Click Save at the top of the screen under Message(s). Click Save again when prompted, to confirm the changes.

  17. Proceed to External authentication, where you will verify that the TAI is working properly.

 


WebSphere Application Server with WebSEAL Example

Here is an example of how to set up a WebSphere Application Server application to be authenticated by WebSEAL.

  1. Create ServerA appserver on NodeA

  2. Create J2C authentication data entries

  3. Create JDBC Providers and Data Sources

  4. Deploy the ServerA EAR file

  5. Create a trusted user account in TAM.

    pdadmin> user create webseal_userid webseal_userid_DN firstname surname password
    pdadmin> user modify webseal_userid account-valid yes

  6. Enable SSO to WAS by setting SSO password in WebSEAL.

    On WebSEAL box, edit...

    webseal_install_directory/etc/webseald-default.conf

    ...and setting the following parameter...

    basicauth-dummy-passwd=webseal_userid_passwd

    ..and then restart WebSEAL.

  7. Create a virtual host entry for the secure port used by the ServerA web container.

  8. Configure TAM Java Runtime Environment on amsterdam.setgetweb.com (node).

    TAM Java Runtime Environment may be already installed with WAS 6. Check for existence of...

    %WAS_HOME%\java\jre\PolicyDirector

    Configure Access Manager Java Runtime Environment...

    set WAS_HOME=D:\WAS\6.0\AppServer
    set JAVA_HOME=%WAS_HOME%\java
    set WAS_CLASSPATH=%WAS_HOME%\properties;%WAS_HOME%\lib\bootstrap.jar;%WAS_HOME%\lib\j2ee.jar;%WAS_HOME%\lib\lmproxy.jar;%WAS_HOME%\lib\urlprotocols.jar
    set WAS_PATH=%WAS_HOME%\bin;%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;%PATH%
    set CLASSPATH=%JAVA_HOME%\jre\lib\ext\PD.jar;%WAS_CLASSPATH%
    set CLASSPATH=%JAVA_HOME%\jre\lib\ext\ibmjceprovider.jar;%CLASSPATH%
    set CLASSPATH=%JAVA_HOME%\jre\lib\ibmpkcs.jar;%CLASSPATH%

    java -Djava.ext.dirs -Dpd.home="%WAS_HOME%\java\jre\PolicyDirector" com.tivoli.pd.jcfg.PDJrteCfg -action config -was -host iam-t-cpps.setgetweb.com -port 7138

  9. Configure SSL for TAI on WAS (between WPS and TAM) on amsterdam.setgetweb.com (node)

    Execute...

    set WAS_HOME=D:\WAS\6.0\AppServer
    set JAVA_HOME=%WAS_HOME%\java
    set WAS_CLASSPATH=%WAS_HOME%\properties;%WAS_HOME%\lib\bootstrap.jar;%WAS_HOME%\lib\j2ee.jar;%WAS_HOME%\lib\lmproxy.jar;%WAS_HOME%\lib\urlprotocols.jar
    set WAS_PATH=%WAS_HOME%\bin;%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;%PATH%
    set CLASSPATH=%JAVA_HOME%\jre\lib\ext\PD.jar;%WAS_CLASSPATH%
    set CLASSPATH=%JAVA_HOME%\jre\lib\ext\ibmjceprovider.jar;%CLASSPATH%
    set CLASSPATH=%JAVA_HOME%\jre\lib\ibmpkcs.jar;%CLASSPATH%

    %JAVA_HOME%\bin\java com.tivoli.pd.jcfg.SvrSslCfg -action config -admin_id act_admin -admin_pwd P455w0rd1 -appsvr_id amsterdam -port 9449 -mode remote -policysvr iam-t-cpps.setgetweb.com:7138:1 -authzsvr iam-t-cpps.setgetweb.com:7136:1 -cfg_file %WAS_HOME%\java\jre\PdPerm.properties -key_file %WAS_HOME%\java\jre\lib\security\pdperm.ks -cfg_action replace

    If command fails with message...

    Unable to find %JAVA_HOME\jre\PolicyDirectory\PDJLog.properties

    ...manually create a PDJLog.properties file.

    If you get the error...

    Exception in thread "main"
    [
    HPDAC1050E   Operation is not authorized.
    ]
       at com.tivoli.pd.jutil.br.a(br.java:76)
       at com.tivoli.pd.jutil.br.a(br.java:37)
       ...
    

    HPDAC0153E indicates that the system could not build ACL with the supplied ACL entries. An ACL entry failed the validity check. You need to log onto the tiam.setgetweb.com TAM server and add administrative access groups to yours account (in this case act_admin).

    If the command fails, we can try to reconfigure Java Runtime Environment or the SvrSslCfg

    %JAVA_HOME%\bin\java com.tivoli.pd.jcfg.SvrSslCfg -action unconfig -admin_id act_admin -admin_pwd P455w0rd1 -appsvr_id amsterdam.setgetweb.com -port 9449 -policysvr iam-t-cpps.setgetweb.com:7138:1 -cfg_file %WAS_HOME%\java\jre\PdPerm.properties

  10. Configure single signon using trust association interceptor++

    com.ibm.websphere.security.webseal.checkViaHeader false
    com.ibm.websphere.security.webseal.configURL file:///D:/WAS/6.0/AppServer/java/jre/PdPerm.properties
    com.ibm.websphere.security.webseal.hostnames iam-t-wbs1,iam-t-wbs3,tiam.setgetweb.com,iam-t-wbs1.setgetweb.com,iam-t-wbs3.setgetweb.com
    com.ibm.websphere.security.webseal.id iv-creds
    com.ibm.websphere.security.webseal.ignoreProxy false
    com.ibm.websphere.security.webseal.loginId act_admin
    com.ibm.websphere.security.webseal.ports 9449,80,443
    com.ibm.websphere.security.webseal.ssoPwdExpiry 0
    com.ibm.websphere.security.webseal.viaDepth 0

  11. Create a junction between WebSEAL and WAS using the iv-creds (TAI) and the HTTP basic authentication headers.. Log onto the TAM server, execute pdadmin, and run...

    
    server task tiam.setgetweb.com-webseald-amsterdam.setgetweb.com create 
           -t ssl 
           -b supply 
           -c iv-creds 
           -h amsterdam.setgetweb.com        -p 9449
           junction_name 
    

  12. Create new JKS key store and trust store files on amsterdam

    D:\WAS\6.0\Profiles\NodeA\etc\amsterdamkey.jks
    D:\WAS\6.0\Profiles\NodeA\etc\amsterdamtrust.jks

  13. Use iKeyman to generate a certificate request

  14. Generate cert using certificate request

  15. Use iKeyman to load new received cert.

    amsterdam.setgetweb.com.cer was received into the JKS Database File on amsterdam

    D:\WAS\6.0\AppServer\etc\amsterdamkey.jks

  16. Create new SSL repertoire configuration

    NodeA/AmsterdamSSL

  17. Assign new SSL repertoire alias to SSL transport

    Click...

    Server | Application server | servername | Communications | Ports

    Locate a transport chain where SSL is enabled and click...

    View associated transports | transport_channel_name | Transport Channels | SSL Inbound Channel (SSL_2)

 

WebSEAL over SSL and WebSEAL over LTPA

Setting up the WebSEAL-WAS-WebSphere Portal junction over SSL requires that you configure WAS and the HTTP server that is used by WAS to accept inbound SSL traffic and route this traffic correctly to WAS and 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.

A second method creates an SSL junction using LTPA authentication on the WebSEAL node. WebSEAL performs authentication checks on all requests for resources before passing those requests across a junction to the back-end server. Upon successful login, WebSEAL will generate an LTPA authentication token to pass to the back-end server. Here are the steps to follow:

  1. Enable SSL on WebSphere Portal.

  2. Open a pdadmin command prompt from any node that has a TAM Runtime component installed. This can be done on the TAM Server node, WebSEAL node or the WebSphere Portal node.

  3. Create a junction between WebSEAL and WAS...

    server task server_name-webseald-your.host.name create 
           -t ssl 
           -b filter 
           -A 
           -F LTPA-Keys-Path 
           -Z LTPA-Password 
           -h Target-Host 
           -c all 
           Junction-Name 

    For example, if the configured name of a single WebSEAL server is amsterdam, and the host to create a junction to is called skyway2.setgetweb.com,...

    server task amsterdam-webseald-skyway2.setgetweb.com create -t ssl -b filter -A -F LTPA-Keys-Path -Z LTPA-Password -h skyway2.setgetweb.com -c all SkyWayJunction

    The -A option enables LTPA cookies

    The -F option specifies the full path name to the key file on the WebSEAL server used to encrypt the shared key. This key file was originally created on the WebSphere Application Server server and copied to the WebSEAL box.

    The -Z keyfile-password option and argument specifies the password required to open the key file

If you choose to use encrypted junctions between WebSEAL and WAS 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, 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, we 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 will cause 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 property...

com.ibm.websphere.security.webseal.loginid

...of the TAI startup parameters in the administrative 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 specify wilbur on the basicauth-dummy-passwd property in webseald-instance.conf on the WebSEAL server.

 

Junctions and the XML configuration interface

By default, the XML configuration interface cannot access the portal through a WebSEAL junction. To enable the XML configuration interface to access the portal through a WebSEAL junction, use TAM to define the configuration URL...

/wps/config

...within the junction as unprotected.

After the configuration URL is defined as unprotected, only WebSphere Portal enforces access control to this URL. Other portal resources that are protected within the WebSEAL junction, for example the URL...

/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, which is inserted by WebSEAL into the request that is sent from WebSEAL to the WAS and the WebSphere Portal 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.

The junctions between WebSEAL and WAS and WebSphere Portal can be configured to be encrypted to prevent eavesdropping. Note that encrypted junctions add complexity (certificate management) and have a performance cost, so if the network between the inner firewalls and Portal is secure against unauthorized access, you might want to use unencrypted junctions.

 

Related information

 

Parent topic:

Using TAM with WebSphere Portal