IBM(R) Tivoli(R) Access Manager for e-business WebSEAL, Patch 5.1.0-TIV-AWS-FP0036 README
==============================================================================

(C) Copyright International Business Machines Corporation 2004.
All rights reserved.
U.S. Government Users Restricted Rights -- Use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

NOTE:  Before using this information and the product it supports,
       read the general information under "NOTICES" in this document.

DATE:  Wednesday, 10 March 2004

------------------------------------------------------------------------------
    CONTENTS

   1.0 ABOUT THIS PATCH
       1.1 Patch contents
       1.2 Architectures
       1.3 Patches superseded
       1.4 Dependencies

   2.0 APARS AND DEFECTS FIXED
       2.1 Problems fixed by patch 5.1.0-TIV-AWS-FP0036
       2.2 Problems fixed by patch 5.1.0-TIV-AWS-FP0034
       2.3 Problems fixed by patch 5.1.0-TIV-AWS-FP0032
       2.4 Problems fixed by patch 5.1.0-TIV-AWS-FP0030
       2.5 Problems Fixed by Patch 5.1.0-TIV-AWS-FP0026
       2.6 Problems Fixed by Patch 5.1.0-TIV-AWS-FP0024
       2.7 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0022
       2.8 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0020
       2.9 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0017
       2.10 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0015
       2.11 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0013
       2.12 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0009
       2.13 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0006
       2.14 Problems Fixed by Patch 5.1-AWS-FP04
       2.15 Problems Fixed by Patch 5.1-AWS-FP02
       2.16 Problems fixed by patch 5.1-AWS-0001

   3.0 BEFORE INSTALLING THIS PATCH
       3.1 Back up Tivoli Access Manager data
       3.2 Upgrade GSKit to Version 7.0.4.11

   4.0 INSTALLING THIS PATCH
       4.1 Installing this patch on AIX(R) systems
       4.2 Installing this patch on HP-UX systems
       4.3 Installing this patch on Linux systems
       4.4 Installing this patch on Solaris Operating Environment systems
       4.5 Installing this patch on Windows systems

   5.0 UNINSTALLING THIS PATCH

   6.0 AFTER INSTALLING THE PATCH
       6.1 Verifying patch level
       6.2 Adding new components To a system
       6.3 Configuring WebSEAL to use the SecurID client library
       6.4 Configuring WebSEAL to use HTTP Header Authentication

   7.0 DOCUMENTATION UPDATES
       7.1  [cdsso] and [e-community-sso] stanzas (45107)
       7.2  New configuration option - default-tokens-use-argument (45261)
       7.3  WebSEAL Administration Guide correction (45908)
       7.4  Additional WebSEAL Administration Guide corrections
       7.5  Attribute Retrieval Service plug-in example - README correction
       7.6  Authorization C API Developer Reference correction
       7.7  Authorization Java Classes Developer Reference correction
       7.8  New [FILTER-CONTENT-TYPES] entries undergo script filtering (45959)
       7.9  [ldap] stanza-related timeout entries not documented (APAR IY53103)
       7.10 CDSSO cannot rely on browser referer header (28346)
       7.11 Cannot update some Active Directory expired passwords (46200)
       7.12 WebSEAL token authentication now supports Lotus Domino and Active
            Directory user registries (44954)
       7.13 Authentication cookie is refreshed on login (IY53475)
       7.14 New optional parameter to [junction] stanza (IY50317)
       7.15 A new parameter in the [script-filtering] stanza (47032)
       7.16 Expired password in AD_LDAP might prevent WebSEAL auth (43684)
       7.17 Filtering is broken if the BASE HREF contains ONLY host name(43515)
       7.18 Server-relative URL filtering is not working. (IY49886)
       7.19 Trace log contains 302 "content-encoding: gzip" responses.(38952)
       7.20 CDSSO-ARGUMENT NOT FUNCTIONING - iv_groups aren't passed to
            BackEnd server. (IY51261)
       7.21 CLARIFICATION OF WEBSEAL LOGGING CONFIGURATION (IY53897)
       7.22 CUSTOMER HAS PROBLEMS CONFIGURING MSGS RECEIVING THEM IN VARIOUS
            LANGUAGES (IY52390)
       7.23 INCORRECT DESCRIPTION OF INTRA-CONNECTION-TIMEOUT (50058)
       7.24 Clarification of Valid Characters for ACL Names (IY53637)
       7.25 Users with expired password can CDSSO, SU, be VOUCHFOR'ED (44563)
       7.26 WebSeal 3.8 custom login pages don't work for 5.1 (47291,IY55336)
       7.27 Docs for using BA headers for SSL needs to be combined (IY56542)
       7.28 WebSEAL script-filter parameter description correction (49901)
       7.29 This line left blank intentionally!
       7.30 Change all server passwords for security purposes (50791)
       7.31 Confusing doc for %BASICAUTHN%, %CERTAUTHN%, and %TOKENAUTHN% (IY58348)
       7.32 Document PDADMIN terminate session command (48787)
       7.33 New config option to suppress-backend-server-identity (51470)
       7.34 Allow junctioned virtualservers to set virtual domain cookie (IY54986)
       7.35 Bad content length POST returning 'Request entity too large' (IY55367)
       7.36 %ERROR% Macro not set when username or pw is left blank (IY56902)
       7.37 WebSeal drops "?" when search string is empty (IY59576)
       7.38 Incorrect PATH name for cdsso_key_gen in WebSEAL Admin Guide (IY58445)
       7.39 Undocumented webseald message codes need to be documented (IY57186)
       7.40 Incorrect package name listed in the Upgrade Guide (IY61297)
       7.41 Modifying JavaScript inserted by the "-j" junction option (IY61959)
       7.42 Cookies with the same name but different paths replace each other (54075)
       7.43 Backward compatibility allows cdas to return custom error codes(54076)
       7.44 When suppress-server-identity = yes, a junctioned backend server
            cannot set a Server header (IY44464 fix completion) (54078)
       7.45 Response codes for some message pages are missing (54336)
       7.46 Upgrade of TAM 4.1 WebSEAL to TAM 5.1 WebSEAL fails with an
            error message "Unable to create file upgradever.txt" (IY57544)
       7.47 WebSeal ADMIN GUIDE does not list network-interface in
            Appendix A (IY64351)
       7.48 Documentation for chpwd and update_pw (IY65998)
       7.49 WebSEAL ADMIN GUIDE erroneously mentions "certstepup.html" (IY66932)
       7.50 WebSEAL ADMIN GUIDE is missing the name of the Linux
            built-in switch user shared library (IY67398)
       7.51 Document Generic HTTP Header Session Key Support (57810)
            (*** contains important note about a change to session key use for
             clients that authenticate using HTTP Headers)
       7.52 The 'pdweb.sescache' statistics component is not documented
            correctly in the Problem Determination Guide (IY67758)
       7.53 Implementation of domain cookie name mangling for backward
             compatibility and clarification of domain cookie name mangling
             functionality in "-j" junctions (IY67835, IY85168, IY85168)
       7.54 attributes in custom entitlement library not in creds (IY69063)
       7.55 Configured number of threads more than system can support (IY70268)
       7.56 Statistics collected via pdweb.threads statistics does not equal the
            sum of the statistics collected via show <junction> command (IY70884)
       7.57 prompt_as_needed cert auth fails if images are in login page (IY69993)
       7.58 413 responses from backends exposes internal rewind error (IY71685)
       7.59 Webseal does not forward error 503 (IY71987)
       7.60 %BACK_NAME% will be filtered as "NONE" instead of "HOME" when a
            referer header is not present (IY72614)
       7.61 WebSEAL Administration Guide correction (IY73286)
       7.62 Custom CDAS return codes being logged but not displayed in browser
            (IY72745).
       7.63 Certificate login error page does not work as documented (IY74261)
       7.64 When using IBM 4960 crypto card, UNIX-GROUP must be set to PKCS11
            (IY74618)
       7.65 ECSSO works with request caching. (IY65436)
       7.66 README: Idle timeout before actual login is attempted (IY70071)
       7.67 Many erroneous responses not logged in request log (IY72402)
       7.68 ADDITIONAL CONFIGURATION IS NEEDED FOR IY65805 (IY75372)
       7.69 Allow relative URL in redirect location - backward compatibility
           (IY74759)
       7.70 Document character encoding requirements for DynURL. (IY74052)
       7.71 Incorrect action for DPWWA2080E message (IY75033)
       7.72 SUSE SLES9 of zSeries is not supported (66818)
       7.73 Update to the supported MIT Kerberos5 versions on the Linux
            platforms. (IY77010)
       7.74 WebSeal ADMIN GUIDE does not contain Linux instructions for
            installing SPNEGO.  (67132)
       7.75 Customers with root users having shell other than ksh or sh may 
            face problem running the pdweb_start script(IY79257)
       7.76 SUSE SLES9 does not install Korne Shell (ksh) by default (67370)
       7.77 Config parameters limiting reposting aren't doc'd (IY79911)
       7.78 -J junction cookie script not XHTML 1.0 compliant (IY75809)
       7.79 Pdadmin command for making authorization space root object
            for replicated front-end webseal servers incomplete (IY82120)
       7.80 Handling CDSSO PD-ID and PD-REFERER query string arguments (IY82093)
       7.81 Directory permission was changed after installing PDWebADK (IY85268)
       7.82 New configuration option - allow-shift-jis-chars (IY82621)
       7.83 New configuration option - error-on-pipelined-request (IY83227)
       7.84 New configuration option - use-filename-for-pkmslogout (IY86806)
       7.85 Document update - Name used when creating SPNEGO account  (IY90379)
       7.86 WebSEAL sessions have inaccurate expiry time (IY90315)
       7.87 Error message reference used the wrong names for configuration 
	    file settings (IY92997)
       7.88 WEBSEAL IS RESETTING THE REQUEST AND NOT CLOSING A PIPELINE (IY90982)
       7.89 New configuration option - dynamic-addresses (IY96223)
       7.90 CONTENT COMPRESSION RULES NEGLECTED (IZ00793)
       7.91 Document additional verification of macro values (81389)
       7.92 New configuration option - connection-request-limit (IZ07508)
       7.93 New configuration option - preserve-base-href2 (IZ10008)
       7.94 Step-up to Basic Authentication is not supported (IZ17083)
       
   8.0 SOFTWARE LIMITATIONS
       8.1 Images in acct_locked.html are not displayed when using ba-auth (IY84076)
       8.2 Auto-resending of POST requests are not supported with stateful 
           junctions (IZ04849)

   9.0 KNOWN PROBLEMS AND WORKAROUNDS, IF AVAILABLE
       9.1 WebSEAL installation wizard hangs (45569) (APAR IY52675)
       9.2 Install the WebSEAL language package prior to configuring WebSEAL
           (44829)
       9.3 File Downloads getting truncated when no/short delay is involved.
           (APAR IY48098)
       9.4 Switchuser doesn't work for users other than sec_master (IY47522)


  10.0 NOTICES
       10.1 Trademarks


1.0 ABOUT THIS PATCH
--------------------
This patch package contains fixes for problems in the various components that
comprise the Tivoli Access Manager WebSEAL software.


1.1 Patch Contents

This patch package contains:

    - This README file
    - Update patch packaging


1.2 Architectures

This patch package applies to the following architectures:

    - IBM AIX(R) 5.1 and 5.2
    - IBM AIX(R) 5.3 with
        1.xlC.rte (6.0.0.0 C Set ++ Runtime)
        2.xlC.aix50.rte (6.0.0.13 C Set ++ Runtime for AIX 5.0)
        3.bos.rte.libc (5.3.0.0 libc Library)
    - Sun Solaris Operating Environment 2.8, 2.9, and 10
    - HP-UX 11 and 11i
    - Red Hat Enterprise Linux 3.0 update 3 Intel
    - SuSE SLES8 for IA32
    - SuSE SLES8 for zSeries(R) (31-bit systems) with SP 2
    - Microsoft Windows 2000 Server and Advanced Server with SP 3
    - Microsoft Windows 2003 Standard Server and Enterprise Server


NOTE:  SuSE Linux is one of four partner companies whose products are
       based on UnitedLinux 1.0; other companies being the SCO Group,
       Turbolinux, and Conectiva. When SuSe Linux Enterprise Server (SLES)
       is listed as supported, other partner companies' products based on
       UnitedLinux 1.0 support is implied as well. For more information,
       consult the UnitedLinux Web site at:
       http://www.unitedlinux.com


1.3 Patches Superseded

All patches are cumulative unless otherwise explicitly stated.

Patches superseded by this patch:

    5.1.0-TIV-AWS-FP0034
    5.1.0-TIV-AWS-FP0032
    5.1.0-TIV-AWS-FP0030
    5.1.0-TIM-AWS-FP0026
    5.1.0-TIM-AWS-FP0024
    5.1.0-TIM-AWS-FP0022
    5.1.0-TIM-AWS-FP0020
    5.1.0-TIM-AWS-FP0017
    5.1.0-TIM-AWS-FP0015
    5.1.0-TIV-AWS-FP0013
    5.1.0-TIV-AWS-FP0009
    5.1.0-TIV-AWS-FP0006
    5.1-AWS-FP04
    5.1-AWS-FP02
    5.1-AWS-0001


1.4 Dependencies

IBM Tivoli Access Manager Base, Version 5.1 with patch 5.1.0-TIV-TAM-FP0036
IBM Tivoli Access Manager WebSEAL, Version 5.1
GSKit Version 7.0.4.11

NOTE: IBM Tivoli Access Manager Base, Version 5.1 patch 5.1.0-TIV-TAM-FP0036
      needed to be installed in the same system where this patch will 
      be installed as well as the above mentioned GSKit Version.
      Please follow the 5.1.0-TIV-TAM-FP0036.README about how to install that
      patch.


2.0 APARS AND DEFECTS FIXED
---------------------------
Because patches are cumulative, this patch corrects all the problems
outlined in the following sections.


2.1 Problems Fixed by Patch 5.1.0-TIV-AWS-FP0036

    APAR IZ10008
    SYMPTOM: LAST COMPONENT OF BASE HREF TAGS IS STRIPED WHEN MISSING THE
	     TRAILING SLASH.
	     If a backend response contains a base href that does not end
	     in a trailing slash (/), the last component of the base path
	     will be stripped when filtered by WebSEAL.

    APAR IZ11655
    SYMPTOM: WEBSEAL PROCESS CONSUME CPU
	     WebSEAL's  CPU usage spikes. This may occur when evaluating an 
	     authzrule depending on ADI from the query string or POST body.

    APAR IZ13657
    SYMPTOM: WEBSEAL'S STABILITY FIX RELATED TO DEFAULT-MANAGEMENT ACL


2.2 Problems Fixed by Patch 5.1.0-TIV-AWS-FP0034

    APAR IZ10811
    SYMPTOM: documentation added regarding behavior of auto-reposting
             for stateful junctions under specific conditions

    APAR IZ01446
    SYMPTOM: webseal core on solaris under rare conditions

    APAR IZ09966
    SYMPTOM: webseal does not cache very old contents

    APAR IZ00793
    SYMPTOM: content compression rules neglected

    APAR IZ03065
    SYMPTOM: webseal cores when user tries to login

    APAR IZ04679
    SYMPTOM: webseal considers a backend unavailable and switches to the
             replica when two posts arrive within a short time

    APAR IZ07508
    SYMPTOM: persistent connections are closed after 100 transactions
             are performed on the connection

    APAR IZ09965
    SYMPTOM: upgrade to TAM 6.0 requires back time-stamping files

    APAR IZ09967
    SYMPTOM: webseal allows only 100 requests on a persistent connection


2.3 Problems Fixed by Patch 5.1.0-TIV-AWS-FP0032

    APAR IY96223
    SYMPTOM: Webseal only resolves junction hostname to IP address
             when junction is initially loaded.

    APAR IY91418
    SYMPTOM: Webseald core under rare conditions during certificate
             authentication

    APAR IY93073
    SYMPTOM: Wrong error in ERROR_CODE macro during MAS authentication
             when using at least two Webseal servers configured for ECSSO
             and local redirection  

    APAR IY97626
    SYMPTOM: Webseald core/hang under rare conditions during
             certificate authentication


2.4 Problems Fixed by Patch 5.1.0-TIV-AWS-FP0030

    APAR IY91823
    SYMPTOM: The pkcs11-token-pwd parameter cannot be stored in the
             obfuscated configuration file.

    APAR IY91823
    SYMPTOM: The pkcs11-token-pwd parameter cannot be stored in the
             obfuscated configuration file.

    APAR IY93446
    SYMPTOM: WebSEAL can crash during stopping (pdweb stop) when the
             pdweb.snoop trace enabled. 

    APAR IY86737
    SYMPTOM: MEMORY LEAK WITH GSKIT CRL
	     WebSEAL had a memory leak when CRL (Certificate Revocation
 	     List )cache is enabled. Fixed using GSKit Version 7.0.4.11

    APAR IY87771
    SYMPTOM: PDADMIN SERVER TASK RELOAD COMMAND FAILED

    APAR IY90982
    SYMPTOM: WEBSEAL IS RESETTING THE REQUEST AND NOT CLOSING A PIPELINE 
	     When webseald receives multiple requests in a pipeline format,
	     webseald will fulfill the first request as normal, but then 
	     reset the connection for the remaining requests.

    APAR IY92997
    SYMPTOM: ERROR MSG REF USED THE WRONG NAMES FOR CONF FILE SETTINGS

    APAR IY93026
    SYMPTOM: COOKIE WITH PATH MANGLED INTO COOKIE NAME IS NOT DELIVERED

    APAR IY86797
    SYMPTOM: While using junction with scripting support enabled (-j
	     junction) or using junction mapping table, a mobile device
	     browser sends a cookie with the $Path="/". The cookie with
	     the $Path="/" is filtered out while sending the request to
	     the backend server.

    APAR IY87036
    SYMPTOM:  When LANG=ja_JP.eucJP, if the sum of the length of the URL 
	      and Referer header was larger than about 300 characters, the 
	      month parts of the request.log would be garbled.

    APAR IY87133
    SYMPTOM: Clients going through NATs or IP proxies change IP addresses, 
	     but WebSEAL always sends the original.

    APAR IY87964
    SYMPTOM: The GSO Resource Credential Update page has a problem.
	     If the input string which contains space character in userid 
	     field, these space characters will be convert to +.

    APAR IY89384
    SYMPTOM: Cannot send some binary POST bodies if dynurl checking enabled.

    APAR IY89713
    SYMPTOM: WebSEAL stability fix.

    APAR IY88062
    SYMPTOM: WebSEAL stability fixes for ECSSO configuration.


2.5 Problems Fixed by Patch 5.1.0-TIV-AWS-FP0026

    APAR IY82621 
    SYMPTOM: When using the -w option to disallow aliased WIN32 file names,
             customers using Japanese shift-jis characters within path
             names receive an invalid URL error. 

    APAR IY83227 
    SYMPTOM: 500 BAD REQUEST error should be returned for pipelined requests.

    APAR IY84483
    SYMPTOM: WEBSEAL hang/crash when reaches 1023 file descriptors.

    APAR IY86832
    SYMPTOM: There is a rare possibility of webseal crash when webseal
             startup or shutdown is in progress and junction operation
             are requested by pdadmin or any other admin api's.

    APAR IY87073
    SYMPTOM: Extended attributes not filled in for CDAS when using token
             authentication.

    APAR IY87306
    SYMPTOM: When using custom sso create or consume libraries for ECSSO,
             webseal will disable ECSSO, printing a message about not being
             able to find SSO domain keys. 

    APAR IY85752
    SYMPTOM: Need to implement domain cookie mangling for backward
             compatibility.  Before the 510 release,  customers were able
             to use domain cookie mangling to prevent overwriting of
             cookies when several junctioned servers set domain cookies
             with the same name and path attributes.


2.5 Problems Fixed by Patch 5.1.0-TIV-AWS-FP0024

    APAR IY78998
    SYMPTOM:  Log details missing on why certificates are rejected.
    Missing details include:    DN from the certificate,
    expiration  and signer errors on certificates.

    APAR IY79279
    SYMPTOM:  AE IY70071 Fix completion: sudden session expiration

    APAR IY79465
    SYMPTOM:  Webseal may hang when attempting a junction delete using pdadmin.

    APAR IY79517
    SYMPTOM: Possible WebSEAL crash when using Stateful Junctions.
             This possibility increases when more cookies are involved.

    APAR IY80570
    SYMPTOM: Attempting to use token login using pre-5.1 customized html 
             will fail with a 5.1 server.

    APAR IY80788
    SYMPTOM:  WebSEAL core is being produced while executing code in the 
              trace logging mechanism.
    
    APAR IY80835
    SYMPTOM:  With PlugIn configured for Passthru Auth, password change on 
              WebSEAL fails, even though success is stated.

    APAR IY81819
    SYMPTOM: WebSEAL can start with invalid settings in webseal.conf.

    APAR IY82093
    SYMPTOM: PD-REFERER and PD-ID arguments are passed to the Backend Server 
             while using CDSSO Configuration.

    APAR IY82120
    SYMPTOM:  Incomplete example in chapter 2 of "Tivoli Access Manager 5.1 
              WebSEAL Administration Guide" The example of the pdadmin command
	      for creating a new object to be the common root of authorization 
	      space for replicated front-end WebSEAL servers is incomplete

    APAR IY83248
    SYMPTOM:  ECSSO not redirecting to correct page after login.

    APAR IY83546
    SYMPTOM:  Missing cookie when using "mangle-path-into-cookie-name=yes" in
              webseald.conf and junctions created using the -j option. 

    APAR IY84156
    SYMPTOM: WebSEAL does not start when "basicauth-dummy-passwd" key item is 
             obfuscated. It shows the following error:   DPWIV0156E   
	      "Configuration item missing (junction, \ basicauth-dummy-passwd)"

    APAR IY84455
    SYMPTOM: The "user-dir" property is no longer used but is still treated as 
             required by Webseal. Therefore removing the entry from
             webseald.conf prevents webseald from starting.


2.7 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0022

    APAR IY74602
    SYMPTOM: under certain conditions when ECSSo is enabled, when a
             request is made to a junction resource without a trailing
             backslash, a "Page Not Found" error is generated instead
             of routing the user to the requested resource

    APAR IY74894
    SYMPTOM: an unnecessary error message, "DPWWA2080E   The session
             inactivity timestamp is missing from the failover cookie."
             is logged when a failover cookie has expired and the
             failover server is configured to require the session 
             inactivity timestamp

    APAR IY76359
    SYMPTOM: pdweb.auth statistics do not always show up correctly

    APAR IY77902
    SYMPTOM: webseald core

    APAR IY77993
    SYMPTOM: Webseal double UTF-8 encodes an accountid or password
             retrieved from LDAP or a cred by FSSO

    APAR IY78392
    SYMPTOM: webseald core

    APAR IY78462
    SYMPTOM: Under heavy load a request sent on a persistent connec-
             tion can timeout if a 5 second delay occurs between
             reads (or writes) from/to the client.  It should require
             a 120 second delay to timeout a read/write.

    APAR IY79328
    SYMPTOM: failover cookies not working when browsers access webseal
             using a different domain than the domain of the fully
             qualified host name automatically detected by webseal


2.8 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0020

    APAR IY77242
    SYMPTOM: after applying LA16 OR FP17, users can not submit POSTs
             larger than request-body-max-read

    APAR IY73535 
    SYMPTOM: Webseal crash on windows.

    APAR IY73720
    SYMPTOM: for a -J junction the option mangle-path-into-cookie-name=yes
	     does not work properly.

    APAR IY74327
    SYMPTOM: WebSEAL, in a junction created with -j option, inserts a script 
	     into outgoing HTML documents in a manner which breaks HTML 4.0.1 
	     compliance.

    APAR IY74836
    SYMPTOM: Junction flags for mutual BA authentication lost when webseal 
	     restarts causing 'object list' command on the junction to fail with 
	     "Object list failed: DPWWA1954E HTTP list request failed". 

    APAR IY75117
    SYMPTOM: webseald core

    Internal CMVC Defect: 64045
    SYMPTOM: disable login page for prompt_as_needed certificate
             authentication

    APAR IY77513
    SYMPTOM: Webseal core on Windows 2000 with Fixpack 5.1.0.9 APAR IY73535

    APAR IY75809
    SYMPTOM: script code generated by webseal for -J junctions needs to be
             XHTML 1.0 compliant


2.9 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0017

    APAR IY69275
    SYMPTOM: Some entries in notice logs are garbled when LANG=JaJp932 set

    APAR IY69998
    SYMPTOM:  On 404, WEBSEAL resends request to backend, prepends junction

    APAR IY70002
    SYMPTOM: If session lifetime timeout = 0, failover authentication fails

    APAR IY70071
    SYMPTOM: If idle timeout is reached before actual login is attempted, then
             credential data is not supplied to login-redirect-page application

    APAR IY71424
    SYMPTOM: Webseal does not properly handle ampersands in URI attribute

    APAR IY71792
    SYMPTOM: IY62229 fix causes $VERSION attribute to be inserted into all
             cookies, which some junction applications may not tolerate

    APAR IY72206
    SYMPTOM: IY56902 when incomplete login information is originally supplied,
             webseal returns pkms help page instead of the originally
             requested resource after successful login

    APAR IY72402
    SYMPTOM: Many erroneous responses not logged in request log

    APAR IY72447
    SYMPTOM: The "request entity too large" error misdocumented in the SAMS

    APAR IY72912
    SYMPTOM: Changed Failover authentication to make it more secure

    APAR IY73240
    SYMPTOM: WEBSEAL does not handle URL strings with filename=somepage.html

    APAR IY73284
    SYMPTOM: WEBSEAL performs double posts with -j junction option

    APAR IY74222
    SYMPTOM: Double posting caused by referer header

    APAR IY74759
    SYMPTOM: port redirect-using-relative option to TAM 5.1


2.10 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0015

    APAR IY49655
    SYMPTOM: Webseal responds with "Bad Request" when 'HTTP' is not uppercase

    APAR IY54105
    SYMPTOM: Webseal performance issue... worker thread bottleneck

    APAR IY65436
    SYMPTOM: ECSSO request caching does not work

    APAR IY67264
    SYMPTOM: Webseal may accept revoked certs when
             accept-client-cert = prompt_as_needed

    APAR IY67376
    SYMPTOM: PD-S-SESSIONID issue where valid sessionid entries could
             be deleted from sessionid cache

    APAR IY67778
    SYMPTOM: Webseal appends non-standard port number to host header

    APAR IY68047
    SYMPTOM: disable-tls-v1 in [JUNCTION] stanza does not work

    APAR IY68167
    SYMPTOM: If webseald-default.conf file contains a badly malformed stanza,
             the ownership of the conf file could be changed

    APAR IY68337
    SYMPTOM: When Autotrace is configured and WebSEAL is the only blade
             configured, starting it via pdweb_start script can cause errors
             to be logged in syslogd

    APAR IY68421
    SYMPTOM: Length of Webseal instance name should not be enforced in TAM

    APAR IY68773
    SYMPTOM: Webseal sessions remain in cache well beyond timeout limits

    APAR IY69442
    SYMPTOM:  Modifying Webseal junction properties on Linux causes errors

    APAR IY69993
    SYMPTOM: PROMPT_AS_NEEDED cert auth fails if images are in login page

    APAR IY70227
    SYMPTOM: LTPA cache counter never decreases


2.11 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0013

    APAR IY48974
    SYMPTOM: webseald core

    APAR IY53870
    SYMPTOM: Securityfocus ASN.1 Parsing Vulnerability program crashes

    APAR  IY58363
    SYMPTOM: PDINFO_PDWEB_BLADE.PL not installed - PDBACKUP Does not work

    APAR  IY62229
    SYMPTOM: WebSeal improperly filters specific incoming HTTP cookies

    APAR IY62319
    SYMPTOM: STEPUP - existing Creds not passed to CERT CDAS

    APAR  IY63406
    SYMPTOM: Webseald process is consuming 100% CPU resource

    APAR  IY63700
    SYMPTOM: Log invalid content length error message (DPWWA1964E)

    APAR  IY63386
    SYMPTOM: WebSeal is not sending cached information if the data within their
             datagram are small

    APAR  IY63809
    SYMPTOM: Update error reference for invalid content length (DPWWA1964E)

    APAR IY63847
    SYMPTOM: HTTP_COOKIE environment variable not set when accessing local a junction

    APAR IY65131
    SYMPTOM: Customer migrated to 5.1 FP6 from 3.9 Base and is experiencing cores
             when using embedded font tags in javascript function call args

    APAR IY65805
    SYMPTOM: EAI clients can reauthenticate using a different auth level


2.12 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0009

    APAR  IY56386
    SYMPTOM: Backward compatibility allows cdas to return custom error codes

    APAR  IY58298
    SYMPTOM: TAM 5.1+FP3: relative URL is prefixed with 'slash' "/"

    APAR  IY58325
    SYMPTOM: When suppress-server-identity = yes, a junctioned backend server
             cannot set a Server header

    APAR  IY58516
    SYMPTOM: Do not decode an encoded NULL.  Instead, pass the encoded
             "%00" on to the decoded buffer.

    APAR  IY58997
    SYMPTOM: Changing unix-pid-file causes pdweb_start stop failure

    APAR  IY59095
    SYMPTOM: Webseal tries to migrate conf file, fails and exits if .obf missing

    APAR  IY59640
    SYMPTOM: Cert requirement not enforced when reusing failed ssl session

    APAR  IY59987
    SYMPTOM: CGI handling difference on win32 vs. Unix platforms

    APAR  IY63066
    SYMPTOMS: Cookies with the same name but different paths replace each other

    APAR  IY63067
    SYMPTOM: WEBSEAL crashes in a complex environment

    APAR  IY63068
    SYMPTOM: Failover-cdsso does not work

    APAR  IY63069
    SYMPTOM: Session cookie values ends with incrementing number

    APAR  IY63070
    SYMPTOM: With a hardened AIX environment pd_start gives error about time

    APAR  IY63073
    SYMPTOM: When login.html has %USERNAME% and reauth-for-inactive is set
             to "yes", webseal will overwrite authenticated username  with
             unauthenticated or even bad username

    APAR  IY63074
    SYMPTOM: Bad filtering for "=" sign in URI


2.13 Problems Fixed by Patch 5.1.0-TIM-AWS-FP0006

    APAR IY56878
    SYMPTOM: Webseal changing cookies that then become invalid

    APAR IY54986
    SYMPTOM: Allow junctioned virtualservers to set virtual domain cookie

    APAR IY59576
    SYMPTOM: WebSeal drops "?" when search string is empty

    APAR IY55367
    SYMPTOM: Bad content length POST returning 'Request entity too large'

    APAR IY56902
    SYMPTOM: %ERROR% Macro not set when username or pw is left blank

    APAR IY58289
    SYMPTOM: SWITCH-USER form adjustment CMVC 50369


2.14 Problems Fixed by Patch 5.1-AWS-FP04

    DEFECT: IY51361  (APAR: IY57662)
    SYMPTOM: If a WebSEAL server is configured to resend WebSEAL set-cookies,
             and not to generate e-community sso cookies, and receives an ECSSO
             cookie, the server will crash.

    DEFECT: IY53140  (APAR: IY57663)
    SYMPTOM: Failed connection requests when certs are required, are not logged
             in request.log.

    APAR IY53179
    SYMPTOM: If timeout for max lifetime is 0 it caused high CPU usage

    APAR IY55117
    SYMPTOM: Entitlements service not passing multi-values

    APAR IY55120
    SYMPTOM: WebSEAL not releasing worker threads when clicking "back" on
             a not found page

    APAR IY55336
    SYMPTOM: WebSeal 3.8 custom login pages don't work for 5.1

    APAR IY55478
    SYMPTOM: WEBSEAL failed to start if dynurl-map is commented out on Linux

    DEFECT: IY55621  (APAR: IY57665)
    SYMPTOM: If a junction is deleted whose stats are on, webseald dies on next
             stats gathering and writing to log file.

    APAR IY57662
    SYMPTOM: If resend-webseal-cookies is set, and PD-ECC set w/out ECSSO
             configured, the server will crash

    APAR IY57663
    SYMPTOM: WEBSEAL is not logging requests when accept-client-certs=required

    APAR IY57664
    SYMPTOM: Multiple HTTP POST in request.log

    APAR IY57665
    SYMPTOM: WebSEAL 4.1 cores when STAT is ran for a deleted junction.

    Internal CMVC DEFECT: 44563
    SYMPTOM: Users with expired password can CDSSO, SU, be VOUCHFOR'ED

    Internal CMVC DEFECT: 47291
    SYMPTOM: LOGIN-FORM-TYPE configuration variable for login forms

    Internal CMVC Defect 50522
    SYMPTOM: WebSEAL will crash if any error, like a timeout, occurs on a
             connection.


2.15 Problems Fixed by Patch 5.1-AWS-FP02

    APAR IY46618
    SYMPTOM: Session state cannot be maintained with SSL IDs when using Opera
             Web Browser.

    APAR IY46695  (Internal CMVC Defect 44453)
    SYMPTOM: XML/XHTML filtering within WebSEAL causes high CPU utilization.
             This can cause WebSEAL to hang when a user accesses a non-html
             document type.

    APAR IY47032
    SYMPTOM: When a meta-tag refresh is returned from a Backend server accessed
             via a -j junction, the refresh does not work via an HTTP Smart
             Compression proxy with a Netscape 4.x browser.

    APAR IY48098  (Internal CMVC Defect 44452)
    SYMPTOM: File downloads get truncated when no/short delay is involved.

    APAR IY49645
    SYMPTOM: Failed cdmf_get_usr_attributes will not cause CDSSO and ECSSO
             token creation. If the attributes are necessary for an
             application, the application will fail.

    APAR IY49886
    SYMPTOM: Server-relative URL filtering is not working.

    APAR IY49943
    SYMPTOM: WebSEAL leaks file descriptors and (possibly) memory if all of the
             following are true:

             -- a junction was created with one of the -b options
             -- the junction returns a 401 unauthorized response
             -- the response contains a set-cookie header

    APAR IY50317
    SYMPTOM: Cookie handling within webseal not compatible with J2EE apps.

    APAR IY50332 reference IY50754 (Internal CMVC Defect 45026)
    SYMPTOM: WebSEAL returns a bad request OX38CF0424 and a large DBCS or UTF8
             POST body is encountered (larger than the configured size).

    APAR IY51074
    SYMPTOM: A user logs in and is redirected to the login-redirect-page. If
             the user then changes his password, he is redirected to the
             login-redirect-page again. The login-redirect directive should
             only redirect on login, not password changes.

    APAR IY51525
    SYMPTOM: Mutually authenticated SSL junctions cannot load balance. If a
             user uses one certificate for each server, only the first server
             defined within the actual junction definition functions.

    APAR IY51261  (Internal CMVC Defect 44642)
    SYMPTOM: CDSSO-ARGUMENT NOT FUNCTIONING - iv_groups aren't passed to
             BackEnd server. New configuration parameter
             (default-tokens-use-argument).

    APAR IY53464  (Internal CMVC Defect 40361)
    SYMPTOM: If a user's password expired in Active Directory, the user could
             not authenticate to WebSEAL.

    Internal CMVC Defect 32647
    SYMPTOM: Potential crashes due to lack of memory or inaccurate output may
             be displayed when using the sample cdmf library.

    Internal CMVC Defect 38952
    SYMPTOM: Trace log contains 302 "content-encoding: gzip" responses. When
             a user requests a junction point without a trailing slash /.

    Internal CMVC Defect 43515
    SYMPTOM: Filtering is broken if the BASE HREF contains ONLY the host name.

    Internal CMVC Defect 44293
    SYMPTOM: Base tag filtering for server relative URLs fails. This
             problem occurs when the BASE HREF does not have a trailing slash.

    Internal CMVC Defect 44510
    SYMPTOM: Memory leak when WebSEAL is configured for CDSSO on Windows 2003.

    Internal CMVC Defect 44736
    SYMPTOM: Poor startup performance when WebSEAL is configured to use
             cookies to maintain a session with clients.

    Internal CMVC Defect 44868
    SYMPTOM: An "Invalid Content Length header" error is returned if a response
             contains multiple content-length headers.

    Internal CMVC Defect 45933
    SYMPTOM: Failover cookie does not work since patch 5.1-AWS-0001. The
             WebSEAL log file states "unable to decode failover cookie"
             when trying to consume a failover cookie.

    Internal CMVC Defect 48068
    SYMPTOM: This issue will require upgrading GSKIT to 7.0.1.16.
             IBM has identified a specific reliability issue in all products
             that use the GSKIT component for managing SSL (Secure Socket
             Layer) communication.  In the case of this issue, when subjected
             to a very specific malformed transmission, the IBM product will
             either have a serious performance degradation, or will terminate.
             The termination of the application does not introduce any further
             security concerns such as being able to access a remote system.


2.16 Problems fixed by patch 5.1-AWS-0001

    APAR IY53474
    SYMPTOM: When using cookies as sessions on authentications, a new cookie
             should be generated by WebSEAL.


3.0 BEFORE INSTALLING THIS PATCH
--------------------------------
Before installing this patch, review the following prerequisites and
dependencies.


3.1 Back up Tivoli Access Manager data

Before applying any maintenance, be sure to back up your system.  Use
the pdbackup command provided with the Tivoli Access Manager product
to back up Tivoli Access Manager-specific data.  Documentation for the
pdbackup command is located in the "IBM Tivoli Access Manager Command
Reference, Version 5.1."


3.2 Upgrade GSKit to Version 7.0.4.11

Upgrade the IBM Global Security Toolkit (GSKit) to version 7.0.4.11
BEFORE installing the Tivoli Access Manager packages in this patch.

The updated GSKit installation packages may be downloaded at the URL:

   https://www14.software.ibm.com/webapp/iwm/web/reg/download.do?source=gskitupdt&S_PKG=GSKit_7.0.4.11

After downloading the updated GSKit installation packages, use the
instructions located in the 5.1.0-TIV-TAM-FP0036.README to install the upgraded
GSKit packages.


4.0 INSTALLING THIS PATCH
-------------------------
Before installing this patch, be sure that you have reviewed the
prerequisites and have completed the back up procedure in section 3.0,
"BEFORE INSTALLING THIS PATCH".

If the Tivoli Access Manager product is distributed over multiple machines,
this patch must be applied to all WebSEAL systems within a secure domain.

This README assumes that $PATCH (or %PATCH% for Windows) is the path to
your temporary directory.


4.1 Installing this patch on AIX systems

  1. Log in to the system as root.

  2. Extract the archive into a temporary directory.  For the
     purpose of this README, assume that the symbol $PATCH
     points to this temporary directory.

  3. Stop the Tivoli Access Manager processes:

        /opt/pdweb/bin/pdweb_start stop

  4. At the command prompt, enter the following:

       installp -a -g -X -d $PATCH <package>

       where <package> is one of the following:

       PDWeb.RTE  Specifies the Access Manager Web Security Runtime
       PDWeb.Web  Specifies the Access Manager WebSEAL Server
       PDWeb.ADK  Specifies the Access Manager Web Services ADK
       PDWeb.ARS  Specifies the Access Manager Attribute Retrieval Service

  5. Restart the Tivoli Access Manager processes:

       /opt/pdweb/bin/pdweb_start start



4.2 Installing this patch on HP-UX systems


   1. Log in to the system as root.

   2. Extract the archive into a temporary directory.  For the
      purpose of this README, assume that the symbol $PATCH
      points to this temporary directory.

   3. Stop the Tivoli Access Manager processes:

        /opt/pdweb/bin/pdweb_start stop

   4. At the command prompt, enter the following:

        swinstall -s $PATCH/<package> <patch>

        where <package> and <patch> are one of the pairs
        from the following table:

             <package>                                      <patch>
        ---------------------------------                -------------
        PDWEBRTE000510-36.depot                            PDWebRTE
        PDWEB000510-36.depot                               PDWeb
        PDWEBADK000510-36.depot                            PDWebADK
        PDWEBARS000510-36.depot                            PDWebARS

   5. Restart the Tivoli Access Manager processes:

        /opt/pdweb/bin/pdweb_start start


4.3 Installing this patch on Linux systems


  1. Log in to the system as root.

  2. Extract the archive into a temporary directory.  For the
     purpose of this README, assume that the symbol $PATCH
     points to this temporary directory.

  3. Stop the Access Manager processes.

       /opt/pdweb/bin/pdweb_start stop

  4. At the command prompt, enter the following:

       rpm -U <patchname>

       where <patchname> is one of the following:

       Linux on xSeries(R)

            PDWebRTE-PD-5.1.0-36.i386.rpm
            PDWeb-PD-5.1.0-36.i386.rpm
            PDWebADK-PD-5.1.0-36.i386.rpm
            PDWebARS-PD-5.1.0-36.i386.rpm

       Linux on zSeries

            PDWebRTE-PD-5.1.0-36.s390.rpm
            PDWeb-PD-5.1.0-36.s390.rpm
            PDWebADK-PD-5.1.0-36.s390.rpm
            PDWebARS-PD-5.1.0-36.s390.rpm

       Linux on pSeries(R) and iSeries

            PDWebRTE-PD-5.1.0-36.ppc.rpm
            PDWeb-PD-5.1.0-36.ppc.rpm
            PDWebADK-PD-5.1.0-36.ppc.rpm
            PDWebARS-PD-5.1.0-36.ppc.rpm


       Note:
       If Tivoli Access Manager is already configured, you
       might need to install with the --noscripts flag:

           rpm -U --noscripts <patchname>

   5. Restart the Tivoli Access Manager processes:

       /opt/pdweb/bin/pdweb_start start


4.4 Installing this patch on Solaris Operating Environment systems

  1. Log in to the system as root.

  2. Extract the archive into a temporary directory.  For the
     purpose of this README, assume that the symbol $PATCH
     points to this temporary directory.

  3. Stop the Tivoli Access Manager processes:

        /opt/pdweb/bin/pdweb_start stop

  4. At the command prompt, enter the following:

       cd $PATCH
       patchadd <package>

       where <package> is one of the following:


    PDWEBRTE000510-36   Specifies the TAM Web Security Runtime
    PDWEB000510-36      Specifies the TAM WebSEAL Server
    PDWEBADK000510-36   Specifies the TAM Web Services ADK
    PDWEBARS000510-36   Specifies the TAM Attribute Retrieval Service


  5. Restart the Tivoli Access Manager processes:

      /opt/pdweb/bin/pdweb_start start


4.5 Installing this patch on Windows systems

   1. Log in to the Windows system as the Administrator.

   2. Shut down the Tivoli Access Manager WebSEAL server:
      a.  From Control Panel -> Services click Access Manager
          WebSEAL Server and then click Stop.
      b.  To confirm this action, click Yes.

   3. Unpack the self-extracting archive into a temporary
      directory. For the purpose of this README, assume that
      %PATCH% points to this temporary directory.

   4. Change to the patch directory and run the install command:

           cd %PATCH%
           5.1.0-TIV-AWS-FP0036-WIN.exe

      Note: If, for any reason, you have to reboot your system to
      complete this installation (for example, to overcome a
      shared DLLs problem), you might subsequently encounter a
      problem running the Web Portal Manager to access the console.
      If this happens, confirm that the WebSphere service is
      running. The WebSphere service is installed in manual startup
      mode and might not be running after a reboot.

   5. Restart the Tivoli Access Manager WebSEAL server:

      From the Windows Start menu, click:

      a. Settings -> Control Panel -> Administrative Tools -> Services
      b. Click Access Manager WebSEAL Server -> Start
      c. Click IBM WS AdminServer -> Start



5.0 UNINSTALLING THIS PATCH
---------------------------

NOTE:  Uninstallation is not available on Microsoft Windows systems.

If the Tivoli Access Manager product is distributed over multiple machines,
uninstall this patch on those systems in the reverse order as it was applied.

To remove the patch on UNIX systems, perform the following steps.

   1. Log in to the system as root.

   2. Stop the Tivoli Access Manager processes:

       /opt/pdweb/bin/pdweb_start stop

   3. At the command prompt, enter the following:

      On AIX, reject the applied patch:

         installp -r <package>

         where <package> is one of the following:

           PDWeb.RTE
           PDWeb.ADK
           PDWeb.Web
           PDWeb.ARS


      On HP-UX, remove the patch:

         swremove <patch>

         where <patch> is one of the following:

           PDWebRTE
           PDWeb
           PDWebADK
           PDWebARS


      On Linux, apply the previous patch level:

         rpm -U --oldpackage <old_package>

         where <old_package> is one of the following:

         Linux on xSeries

            PDWebRTE-PD-5.1.0-0.i386.rpm
            PDWeb-PD-5.1.0-0.i386.rpm
            PDWebADK-PD-5.1.0-0.i386.rpm
            PDWebARS-PD-5.1.0-0.i386.rpm

         Linux on zSeries

            PDWebRTE-PD-5.1.0-0.s390.rpm
            PDWeb-PD-5.1.0-0.s390.rpm
            PDWebADK-PD-5.1.0-0.s390.rpm
            PDWebARS-PD-5.1.0-0.s390.rpm


         Linux on pSeries and iSeries

            PDWebRTE-PD-5.1.0-0.ppc.rpm
            PDWeb-PD-5.1.0-0.ppc.rpm
            PDWebADK-PD-5.1.0-0.ppc.rpm
            PDWebARS-PD-5.1.0-0.ppc.rpm


      On Solaris, remove the patch:

         patchrm  <package>

         where <package> is one of the following:

           PDWEBRTE000510-36
           PDWEB000510-36
           PDWEBADK000510-36
           PDWEBARS000510-36


   4. Restart the Tivoli Access Manager processes:

        /opt/pdweb/bin/pdweb_start start



6.0 AFTER INSTALLING THE PATCH
------------------------------

6.1 Verifying patch level

To verify the patch level of your Tivoli Access Manager installation,
do the following.

   On AIX:      lslpp -L PD\*

   On HP-UX:    swlist <package>, example: swlist PDWeb

   On Solaris:  showrev -p

   On Linux:    rpm -q -i PDRTE-PD

   On Windows:  1. run 'regedit'
                2. find \HKEY_LOCAL_MACHINE\
                            SOFTWARE\
                               Tivoli\
                                  Access Manager WebSEAL\
                                     5.1.0.0\

You also can use the pdversion command.


6.2 Adding new components to a system

To install a new component of Tivoli Access Manager on an EXISTING
machine in the Tivoli Access Manager environment after this patch has
been installed:

   1. Install the component using the Tivoli Access Manager Version 5.1
      installation media.

   2. After the new component is installed, reapply this patch to the system.


6.3 Configuring WebSEAL to use the SecurID client library

The default shared library for token authentication maps SecurID (RSA)
token passcode data to a Tivoli Access Manager user identity.  The
authentication process requires an RSA SecurID client library file, located
on the WebSEAL server machine, to communicate with a remote RSA server.

For successful communication between this client file and server, you must
manually set the proper permissions on the file and set an environment
variable that points WebSEAL to the location of the library file:

    1. Change the permissions of the securid file to allow "read"
       access by everyone. The following example assumes the location
       of the file is the /opt/ace/ace/data directory:

       UNIX:
                 cd /opt/ace/ace/data
                 chmod 444 securid

       Windows:
                 Set the Security Properties on the file for "Everyone".

    2. Set the VAR_ACE environment variable to inform WebSEAL
       of the directory location of this file. The following
       example assumes the location of the file is the
       /opt/ace/ace/data directory:

       UNIX:
               export VAR_ACE=/opt/ace/ace/data

       Windows:
               Start -> Settings -> Control Panel -> System -> Environment


6.4 Configuring WebSEAL to use HTTP Header Authentication

A change was made to the default WebSEAL behavior for HTTP header authentication.
In order to successfully continue using HTTP header authentication after
applying this fixpack, please read Section 7.51 of this README.


7.0 DOCUMENTATION UPDATES
-------------------------
The product documentation for Tivoli Access Manager Version 5.1 can be
found at the following Web address:

http://publib.boulder.ibm.com/tividd/td/IBMAccessManagerfore-business5.1.html

Updated information related to the documentation is as follows.


7.1 [cdsso] and [e-community-sso] stanzas (45107)

When an SSO token is generated, a call is made to the Cross Domain Mapping
Framework (CDMF) API to determine the extended attributes that must be
encoded into the token. This is so the user can be correctly mapped across the
SSO authentication. The propagate-cdmf-errors parameter determines whether
the failure of the cdmf_get_usr_attributes call will cause token creation
to fail. If propagate-cdmf-errors = no (default), a default attribute list is
generated if the CDMF fails, and token creation proceeds without error.
However, if propagate-cdmf-errors = yes and CDMP fails, token creation is
aborted.


7.2 New configuration option - default-tokens-use-argument (45261)
    (reference IY51261)

default-tokens-use-argument is a new configuration parameter in the cdsso and
ecsso stanzas. This parameter defaults to 'yes' as follows:

[cdsso]
default-tokens-use-argument = yes
[ecsso]
default-tokens-use-argument = yes

A 'yes' value specifies to use the default ssocreate and ssoconsume libraries
with cdsso or ecsso. They create/consume tokens with the token name of the
cdsso/vf-argument configuration parameter.

To be backward compatible, set this parameter to 'no'. A 'no' value specifies
for the standard sso libraries to create/consume tokens, called PD-ID (cdsso)
and PD-VF (ecsso), regardless of the cdsso/vf-argument configuration
parameters.


7.3 WebSEAL Administration Guide correction (45908)

On page 54 in the "Multi-locale messages" section, step 5 should read:

"If there are no installed language packs for all the languages
listed in the header, WebSEAL defaults to the language environment
which WebSEAL is running in, as determined by the LC_ALL or LANG
environment variables set in the operating system's environment when
WebSEAL started."


7.4 Additional WebSEAL Administration Guide corrections

The configuration parameter for specifying an authentication strength (step-up)
for certificate authentication is incorrect. Instead of "level=certificate,
" the correct entry is as follows:

level=ssl

Examples on pages 119, 121, and 122 (PDF) are incorrect.  The example on page
123 is correct.


7.5 Attribute Retrieval Service plug-in example - README correction

Step 5 in README file for the ARS sample application is missing an endquote. On
Windows platforms, the README file is located in the following directory:

C:/<install directory>/Tivoli/PDWebARS/protocol_plugin

Replace Step 5 with the following corrected text:

5 - Create an authorization rule that will exercise the example protocol using
pdadmin. For example:
pdadmin> authzrule create examplerule
"<xsl:if test='example_protocol_test_container/test_container = \"test_data\"'>!TRUE!</xsl:if>"


7.6 Authorization C API Developer Reference correction

The attribute azn_cred_ldap_dn is incorrectly deprecated and is still listed.

In "Deprecated API elements" on page 71 (PDF), replace
"azn_cred_group_registry_ids" with "azn_cred_registry_id"

In "Obtaining the user's authorization identification" on page 71 (PDF), replace
"azn_cred_ldap_dn" with "azn_cred_registry_id"

In the following sections and reference pages, remove "azn_cred_ldap_dn" from
the list of read-only attributes:

  - "Modifying the contents of a credential" on page 65 (PDF)
  - "Setting and getting string attribute values for a credential" on page 66 (PDF)
  - azn_creds_modify()
  - azn_creds_set_attr_value_string()
  - azn_svc_creds_modify()


7.7 Authorization Java Classes Developer Reference correction

A deprecated method is used in sample code. In "Obtaining entitlements for the
specified user" on page 22 (PDF), replace the line:

PDAttrValues results = attrsOut.get(PDStatics.AZN_ENT_SVC_PD_POBJ_MATCHES);

with the following:

Collection results = attrsOut.getValues(PDStatics.AZN_ENT_SVC_PD_POBJ_MATCHES);


7.8  New [FILTER-CONTENT-TYPES] entries undergo script filtering (45959)

In the "WebSEAL Administration Guide," Chapter 10 in the "Standard URL
filtering rules for WebSEAL" section, the following information is
provided:

"By default, WebSEAL filters only documents of MIME type 'text/html' and
'text/vnd.wap.wml' that are received from junctioned servers. Additional
MIME types can be configured using the [filter-content-types] stanza of the
WebSEAL configuration file."

Additional content types added to the [filter-content-types] stanza are "not"
subject to standard URL filtering rules. These new content types are filtered
using script filtering rules. WebSEAL scans the body of the entire document
looking for absolute URLs matching junction servername/port/transport
combinations.


7.9  [ldap] stanza-related timeout entries not documented (APAR IY53103)

The "WebSEAL Administration Guide, Version 5.1," Appendix A does not document
that "ssl-port", "replica", "timeout", "authn-timeout", and "search-timeout" are
legal in the [ldap] stanza of webseald.conf. They are legal and have the same
significance as documented in the "Base Administration Guide," Appendix A. They
are also legal in any blade's configuration file.

The "WebSEAL Administration Guide, Version 5.1" also documents an [ldap] stanza
configuration parameter of "ssl-keyfile-label". There is no such [ldap] stanza
configuration parameter. The correct parameter is "ssl-keyfile-dn" as documented
in the "Base Administration Guide," Appendix A.

On page 40 of the "Authorization C API Developer Reference," an
[ldap] stanza configuration parameter of "ldap-replica" is described. The
name in the example is incorrect. The correct parameter name is "replica".

In the "Authorization C API Developer Reference," the [ldap] stanza
configuration parameter "ldap-server-config" is not documented. It is legal
in any blade's configuration file and is documented in the "Base Administration
Guide," Appendix A.

Note: If a blade's config file specifies an "ldap-server-config" parameter,
then azn_initialize() overrides the values for "enabled", "host", "port",
"ssl-port", "max-search-size", and "replica" obtained from the blade's config
file with the values read from the "ldap-server-config" file. This is true for
WebSEAL also, but since WebSEAL requires the "ldap-server-config" parameter,
for WebSEAL, the effective values for these five parameters are always obtained
from the ldap-server-config file.


7.10  CDSSO cannot rely on browser referer header (28346)

Customized ssocreate libraries that rely on the standard ssoconsume library
should always have a PD-REFERER query string argument.

If the ssocreate library is customized, and the library generates a cdsso
redirect without the PD-REFERER query string argument, the standard ssoconsume
library relies on the browser referer header to determine where the request
came from (and which key to use for decryption).


7.11  Cannot update some Active Directory expired passwords (46200)
      (reference IY53464)

The Tivoli Access Manager for e-business Release Notes, Version 5.1 advised that
if a user's password expired in Active Directory, the user could not authenticate
to WebSEAL. This problem has been corrected. For more information, see
"Expired password in Active Directory (AD_LDAP) might prevent WebSEAL
authentication (43684)" in the Release Notes.


7.12  WebSEAL token authentication now supports Lotus Domino and Active Directory
user registries (44954)

The "WebSEAL Administration Guide" describes token authentication support for LDAP
user registries. Token authentication support has been expanded to include Lotus
Domino and Active Directory user registries.  To configure WebSEAL token
authentication to authenticate users through Lotus Domino or Active Directory
registries, you must specify use of the Tivoli Access Manager User Registry Adapter
Framework (URAF).

See the "Token authentication configuration" section in Chapter 6 of the "WebSEAL
Administration Guide." In the "Specify the token authentication" section, add the
following text to the end of step 3:

"To enable token authentication support for Lotus Domino or Active Directory user
registries, specify the following configuration entry in the WebSEAL configuration
file:

[authentication-mechanisms]
token-cdas = libxtokenauthn.so& URAF

For more information on the User Registry Adapter Framework, see Appendix A in the
"Base Administration Guide, Version 5.1."


7.13  Authentication cookie is refreshed on login (IY53475)

When using cookies to maintain session, WebSEAL will now refresh the authentication
cookie upon login. To return to the previous behavior of maintaining the same
authentication cookie, set the following value in the [session] stanza of the
webseald.conf file:

login-update-session-cookie = false

7.14 New optional parameter to [junction] stanza (IY50317)

This fix introduces a new optional parameter to the
[junction] stanza of webseald.conf,
"encode-mangled-cookienames".

With this parameter set to "yes", WebSEAL will mangle the
cookie in a manner to contain only legal characters.

7.15 A new parameter in the [script-filtering] stanza (47032)

A new parameter is available in the [script-filtering] stanza of webseald.conf,
junction-cookie-at-end. When this is set to "yes" the junction cookie script
inserted into HTML pages from -j junctions will be inserted at the end of the
documents, instead of the beginning.


7.16 Expired password in AD_LDAP might prevent WebSEAL auth (43684).

If a user's password expired in Active Directory, the user could not
authenticate to WebSEAL. This problem has been corrected. For more information,
see Chapter 3 of the Tivoli Access Manager for e-business Release Notes,
Version 5.1: "Expired password in Active Directory (AD_LDAP) might prevent
WebSEAL authentication."

7.17 Filtering is broken if the BASE HREF contains ONLY the host name.

For example, if an HTML page has a BASE tag similar to:
<BASE HREF="http://server.ibm.com/">
where junction /jct points to server.ibm.com,
WebSEAL maps the HREF to /jct/ and the BASE tag appears as:
<BASE HREF="https://webseal/jct/">
However, if an HTML page has a BASE tag similar to:
<BASE HREF="http://server.ibm.com"> (without a trailing slash)
where junction /jct points to server.ibm.com,
WebSEAL maps the HREF to /jct, deletes the "jct" (no trailing slash),
and the BASE tag appears as: <BASE HREF="https://webseal/">

7.18 Server-relative URL filtering is not working. (IY49886)

To filter non-html documents, a user would add the following configuration
option in the [server] stanza of the webseald.conf file.

    [server]
    filter-nonhtml-as-xhtml = yes

If the option is set to yes, all non-html documents are filtered similar to
html documents.

7.19 Trace log contains 302 "content-encoding: gzip" responses.(38952)

POP attributes were not being correctly retrieved for requests for a junction
point if the requested URL did not have a trailing slash.  For instance, POPs
would not be correctly applied to a request for "/junction."

7.20 CDSSO-ARGUMENT not functioning - iv_groups aren't passed to BackEnd
server. (IY51261)

cdsso-argument is not functional with the default ssocreate and ssoconsume
libraries. If the customer is has customized both libraries, they should
be ok. When a cdsso token is being generated, ssocreate is called out to,
and the default library creates a cdsso token with the name PD-ID, instead
of the configured cdsso-argument value.
When a cdsso token is being consumed, the ssoconsume library is called out
to if a query string argument matches the configured cdsso-argument
(this is correct behavior). However, the default ssoconsume library cannot
decode any token not called PD-ID.

WebSEAL's token d/encoding libraries (which are called by ssocreate and
ssoconsume) will be updated to handle the cdsso-argument value instead of
just PD-ID.

7.21 Clarification of Webseal logging configuration (IY53897)

The WebSEAL Admin Guide's description of configuring WebSEAL's logging
is not as clear as it could be.

The first difficulty is that the documentation is spread across multiple
manuals.  Because WebSEAL is just a blade of Access Manager, the Access
Manager documentation must be considered as a part of the WebSEAL
documentation.

  Note that the "examples" on p101 of the WebSEAL 5.1 Admin Guide are not
  examples.  They are the logcfg statements instantiated by WebSEAL's
  default HTTP logging when requested by webseald.conf's settings in the
  [logging] stanza.  For example, if "requests = yes" is specified in the
  [logging] stanza of webseald.conf, then the effect is identical to
  specifying

    logcfg = http.clf:file path=<requests-file>,flush=<flush-time>, \
             rollover=<max-size>,log=clf,buffer_size=8192,queue_size=48

in the [aznapi-configuration] stanza.

There have been questions about the option

    log=clf

This option is explained on p199 of the TAM 5.1 Base Admin Guide:

In a configuration entry, the option names are case-insensitive and can be
abbreviated to any shortened length of the full option name that remains
unique.

  Therefore,

    log=clf

  is equivalent to

    log_id=clf

On p203 of the TAM 5.1 Base Admin Guide there is a description of a critical
behavior of logging:

A file is only opened once. If multiple configuration entries exist to
selectively capture events at different points of the event pool hierarchy to
the same file, the file opens according to the options found in the first
configuration entry processed.

After a file has been opened, further file configurations can simply use the
following shorthand notation to record events to the same file:

    [aznapi-configuration]
    logcfg = <category>:file log_id=<logid>

An unstated side-effect of these paragraphs is that any configuration entry for
a particular log_id that precedes the first configuration entry specifying a
file's path is ignored.

When webseald initializes, the [aznapi-configuration] stanza's logcfg entries
are processed before the logcfg entries created by the [logging] stanza's
settings are processed.  Therefore, if any one of the 3 types of default
WebSEAL HTTP logging is enabled in the [logging] stanza -- requests, referers,
or agents --  and the logcfg created for that logging is the first one
processed with that log_id that specifies a file path, then any configuration
entries using that log_id in the [aznapi-configuration] stanza are ignored.

For example, if webseald.conf says

	[logging]
	requests=yes
	requests-file = /var/pdweb/www/log/request.log

	[aznapi-configuration]
	stats = pdweb.authn 40
	logcfg = stats.pdweb.authn:file path=/opt/pdweb/log/stats,log=clf

	logcfg = http.conf:file log,log=clf

then all three kinds of logging will appear in the /opt/pdweb/log/stats.log
file because that logcfg entry was the first one processed for log_id=clf that
had a file path specified.

If, instead, that last logcfg entry read

    logcfg = stats.pdweb.authn:file log=clf

then only the "requests" logging would appear in the
/var/pdweb/www/log/request.log file.  The other two types of logging would not
appear anywhere.

7.22 Customer has problems configuring messages, receiving them in various
     lanquages (IY52390)

In the "Multi-locale support for Web services" section of the WebSEAL
Administrator Guide there is a nice example of how WebSEAL handles an
accept-language header containing "pt-br".  The final paragraph describes the
default behavior of WebSEAL that occurs if there are no installed language
packs for all languages listed in the header, but nowhere is it said what
WebSEAL's behavior is if it receives a message with no accept-language header
at all. In fact, WebSEAL performs the same default behavior in this case as in
the no-language-packs-installed case: it defaults to the language environment
in which WebSEAL is running, as determined by the LC_ALL or LANG environment
variables set in the operating system's environment when WebSEAL started.

7.23 Incorrect description of intra-connection-timeout (50058)

The behavior of the intra-connection-timeout config parameter as implemented
by the fix to IY48098 in WebSEAL 5.1 differs from its behavior in WebSEAL 4.1.
Now the intra-connection-timeout parameter *must* be set >0 to cause an RST to
be sent on a timeout of a client connections.  If the intra-connection-timeout
parameter is not set or is set to zero then the browser will not be aware that
WebSEAL has timed-out the connection.

The WebSEAL 5.1 implementation of the fix to IY48098 enables write timeouts on
both TCP and SSL client connections, where the WebSEAL 4.1 implemented write
timeouts on only SSL client connections.

7.24 Clarification of Valid Characters for ACL Names (IY53637)

  The WebSEAL Admin Guide, Chapter 5, section titled 'Valid characters
  for ACL names' fails to mention that the number characters 0 through 9
  are valid.  It should read:

  The following characters are valid for creating ACL names:
    A-Z
    a-z
    0-9
    underscore(_)
    hyphen (-)
    backslash (\)
    Any character from a double-byte character set

  Again, the 0 through 9 characters are valid for use in ACL naming.

7.25 Users with expired password can CDSSO, SU, be VOUCHFOR'ED (44563)

  This has been fixed in 5.1-AWS-0003LA

7.26 WebSeal 3.8 custom login pages don't work for 5.1 (47291,IY55336)

  To re-enable the pre-5.1 handling of form authentication, the
  following change needs to be in the webseald.conf file:

  default-login-form-type = pwd


  EXAMPLE
  -------
  :
  :
  [forms]
  #----------------------
  # FORMS
  #----------------------

  default-login-form-type = pwd

  # Enable authentication using the forms authentication mechanism
  # One of <http, https, both, none>
  forms-auth = both

7.27 Docs for using BA headers for SSL needs to be combined (IY56542)

  When reading the "Configuring BA headers for single sign-on solutions"
  section of the "Single sign-on solutions across junctions" chapter
  (IBM Tivoli Access Manager WebSEAL Administration Guide), you must
  additionally refer to "Handling client identity information across
  junctions" located in the "Mutually authenticated SSL junctions"
  section of the "WebSEAL junctions" chapter.

7.28 WebSEAL script-filter parameter (49901)

  Correction to Webseal Admin Guide v5.1 (page 290) should read as follows:
  This filtering solution parses a script embedded in HTML code and therefore
  requires additional processing overhead that can negatively impact
  performance. Only enable the script-filter parameter when your WebSEAL
  environment requires filtering of embedded absolute URLs.

7.29 This section left blank intentionally!

7.30 Change all server passwords for security purposes (50791)

  For security purposes, it is recommended that you change all server passwords
  from the original password set during configuration.

7.31 Confusing doc for %BASICAUTHN%, %CERTAUTHN%, and %TOKENAUTHN% (IY58348)

  Error Description:
  The WebSeal Administration Guide page 90 it documents these macros as...

  Substitution variable used to alter login form.
  When authentication method valid, WebSEAL removes the variable.
  When authentication method invalid, WebSEAL comments out the macro.
  Used in tokenlogin.html, certlogin.html, and stepuplogin.html.

  Correction:
  Documentation should be updated to clarify that the macro is not actually
  commented out, but that it actually gets replaced by a start comment
  delimiter, "<!--".
  This results in everything following this macro to be commented out until
  a comment closing delimiter, "-->" is reached.

7.32 Document PDADMIN terminate session command (48787)

  Terminating single user sessions.

  You can terminate a specific user session based on the User Session ID.
  A back-end application can use the Tivoli Access Manager administration
  API to terminate a specific user session based on the User Session ID
  passed in an HTTP header across the junction. In such a scenario, the
  application would invoke the ivadmin_server_performtask() function.

  The WebSEAL server instance, the User Session ID, and the terminate session
  command from the standard pdadmin expression for this task are necessary
  parameters to this function:

  pdadmin> server task instance-webseald-host terminate session user_session_id

Note:

 Although you can manually perform this pdadmin operation, the long User
  Session ID string value (obtained from the HTTP header) can make this task
  cumbersome. WebSEAL verifies that the back-end server initiating the
  terminate operation has appropriate permissions before terminating the user
  session. It is important to consider the conditions under which this command
  might be used.

  If the intent is to make sure a user is removed from the secure domain
  entirely, the termination of a single user is only effective when, in
  addition, the account for that user is made invalid (removed). Certain
  authentication methods, such as Basic Authentication, client-side
  certificate, and failover cookies, return cached authentication information
  automatically with no user intervention. The terminate session action would
  not prevent return logins for a user using any of those authentication
  methods. You must additionally invalidate the appropriate user account in the
  registry.

  Refer to the IBM Tivoli Access Manager Administration C API Developer
  Reference for further information and for ivadmin_server_performtask()syntax.

7.33 New config option to suppress-backend-server-identity (51470)

  HTTP responses normally include a header ("server") containing the identity
  and version of the server sending the response. Examples:

  server: WebSEAL/6.0.0
  or
  server: IBM_HTTP_SERVER/1.3.19  Apache/1.3.20 (Win32)

  To suppress WebSEAL server identity in HTTP server responses, set the
  suppress-server-identity parameter in the [server] stanza of the WebSEAL
  configuration file to "yes":

  [server]
  suppress-server-identity = yes

  The default setting is "no".

  To suppress back-end application server identity in HTTP server responses,
  set the suppress-backend-server-identity parameter in the [server] stanza of
  the WebSEAL configuration file to "yes":

  [server]
  suppress-backend-server-identity = yes

  The default setting is "no".

7.34 Allow junctioned virtualservers to set virtual domain cookie (IY54986)

  A new hidden parameter may be set in the [session] stanza:

  support-virtual-host-domain-cookies = yes/no

  It will be set to yes by default. It can be documented as follows:

  If allow-backend-domain-cookies is set to "yes",
  then this option will modify how WebSEAL validates the domain.

  This option will have no effect if validate-backend-domain-cookies = no

  If set to "yes" then the domain cookie will be validated by comparing it with
  the virtual host specified for a backend server with the -v junction option.
  If set to "no", or if no virtual host was specified for a junction, then the
  fully qualified hostname will be compared with the domain value of a backend
  cookie for validation.

7.35 Bad content length POST returning 'Request entity too large' (IY55367)

  If a customer expects that they will be sending content length headers that
  are longer than the actual content for POST requests, and they are interested
  in seeing  a 'no content' error page returned instead of a 'request entity too
  large' page, then they should add this hidden config item to the server stanza
  in the config file:

  send-post-nocontent-errors = yes

  It defaults to no, and is by default hidden.

7.36 %ERROR% Macro not set when username or pw is left blank (IY56902)

  This APAR introduced and hidden config option that needed to be added to the
  [forms] stanza of the webseald.conf file.

  [forms]
  allow-empty-form-fields = yes

  Default value for this flag is FALSE.

7.37 WebSeal drops "?" when search string is empty (IY59576)

  For this APAR, wesbeald.conf file need to be modified for the server stanza
  with following config condition:

  [server]
  keep-null-query-string = yes

7.38 Incorrect PATH name for cdsso_key_gen in WebSEAL Admin Guide (IY58445)

  Error Description:
  The WebSeal Administration Guide page 203, under section "Create an encryption
  key for cookie data", the path for the cdsso_key_gen tool for UNIX is stated as
  /opt/pdweb/bin/cdsso_key_gen

  Correction:
  The correct path for the tool is /opt/pdwebrte/bin/cdsso_key_gen so the correct
  example for UNIX is:
  /opt/pdwebrte/bin/cdsso_key_gen absolute_pathname_for_keyfile

7.39 Undocumented webseald message codes need to be documented (IY57186)

	dceweb_st_nocontent	     0x38cf041e
  Explanation: The client sent a request with a content length header value
  greater than the length of the actual content sent.
  Action: None.

	dceweb_st_movedtemp  	     0x38cf0421
  Explanation: HTTP 302 error - The requested resource resides temporarily
  under a different URI.
  Action: None.

	dceweb_st_badrequest	     0x38cf0424
  Explanation: A request was sent that did not adhere to the HTTP
  specification.
  Action: None.

	dceweb_st_forbidden	     0x38cf0427
  Explanation: The user's credential doesn't have sufficient permissions to
  access the resource.
  Action: None

	dceweb_st_methodnotallowed   0x38cf0429
  Explanation: A POST request was made to a directory or a non-executable
  resource.
  Action: None.

	dceweb_st_internalerror	     0x38cf042f
  Explanation: An internal error has occurred.
  Action: Check logs for more information.

	dceweb_st_notimplemented     0x38cf0430
  Explanation: HTTP 501 error - The server does not support the functionality
  required to fulfill the request.
  Action: None

	dceweb_st_serviceunavailable 0x38cf0432
  Explanation: The resource requested in unavailable.
  Action: Try again later, or check the status of the junction of the request.

	dceweb_st_entitytoolarge     0x38cf0467
  Explanation: Request was larger than request-body-max-read
  Action: Ensure request-body-max-read is set as intended.

7.40 Incorrect package name listed in the Upgrade Guide (IY61297)

  The Tivoli Access Manager for e-business-5.1 Upgrade Guide lists the
  wrong package on page 57, Step 15(AIX: Upgrading a WebSEAL Server).
  The package for the WebSeal ADK should be PDWeb.ADK and not PD.WebADK

  The installp command should read as
         installp -cagNXd . PD.AuthADK PDWeb.ADK

7.41 Modifying JavaScript inserted by the "-j" junction option (IY61959)

  The "-j" junction option modifies HTML documents returned from junctioned
  servers to include a small piece of JavaScript that sets a cookie on the
  browser interpreting the document. The junction cookie is described in greater
  detail in the IBM Tivoli Access Manager WebSEAL Administration Guide chapter
  titled, "Handling server-relative URLs with junction cookies (-j)."
  The JavaScript inserted by the -j junction option may cause problems in some
  environments. There are two configuration options that allow administrators
  greater control over the script.

  Inserting the JavaScript at the end of the document: Normally WebSEAL
  prepends  the JavaScript at the beginning of HTML documents returned from
  junctions. This may cause HTML rendering problems in some environments.
  Administrators may configure WebSEAL to append the JavaScript to the document
  instead via the "-J trailer" junction option.
      Example: pdadmin> server task server-name create ... -j -J trailer ...

  Multiple junctions using the -j junction option: In environments where a
  single client is using multiple junctions simultaneously, the IV_JCT cookie
  created by the JavaScript may refer to the wrong junction. As an example,
  consider a scenario with two junctions, /jctA and /jctB, both using the -j
  junction option. If a client first requests a page from /jctA, then switches
  to /jctB, then returns to /jctA, the client will send the wrong IV_JCT cookie
  to WebSEAL. If the request does not include the junction point (typically
  because of an unfiltered server-relative URL), WebSEAL will attempt to
  service the request using /jctB instead of /jctA. To work around this
  problem, administrators may configure WebSEAL to use the JavaScript "onfocus"
  event handler in the JavaScript. The "onfocus" handler is used to reset the
  IV_JCT cookie whenever clients switch the browser focus from one window to
  another.
      Example: pdadmin> server task server-name create ... -j \
                        -J trailer,onfocus ...

  The "onfocus" option should always be used in conjunction with the "trailer"
  option. Otherwise, the JavaScript inserted by WebSEAL may interfere with
  rendering of HTML frame sets.

  Note: No error message is provided if the options specified to -J are invalid.
  If the -J junction option does not behave as expected, double-check that you
  are providing the correct argument.

7.42 Cookies with the same name but different paths replace each other (54075)

    *This defect contains documentation in reference to IY63066:
  Edit webseald.conf and add the following line to the [JUNCTION] stanza:

  mangle-path-into-cookie-name=yes

7.43 Backward compatibility allows cdas to return custom error codes(54076)

    *This defect contains documentation in reference to IY56386:
  In order to use this fix, three things need to be done:
  1. The new pdxauthnutils library will have to be installed, For unix, a link
  from /usr/lib is necessary:
  [example]
    ln /opt/pdwebrte/lib/libpdxauthnutils.so /usr/lib/libpdxauthnutils.so

  This step is only required for a testfix deployment;  Once this defect is
  in a fixpack, this library will be  installed and linked correctly
  automatically.

  2. The password CDAS will have to be relinked against the  new pdxauthn
     library.

  3. The new 'hidden' config flag "propagate_custom_cdas_errors" must be passed
  to the passwd-cdas authentication-mechanism in webseal's configuration file.

  The syntax is: passwd-cdas = <library> & propagate_custom_cdas_errors

  For example:
  passwd-ldap = /opt/pdwebrte/lib/libxauthn.so & propagate_custom_cdas_errors

7.44 When suppress-server-identity = yes, a junctioned backend server
     cannot set a Server header (IY44464 fix completion) (54078)

    *This defect contains documentation in reference to IY58325:
  This entry is the existing config option with an updated description:

  WebSEAL writes a Server header with the value "WebSEAL/version.number"
  with most responses (except those from a junctioned server).
  Including this header can be suppressed by setting this to "yes".
    suppress-server-identity = no

  This entry is the new config option:

  For responses that were from a junctioned server, WebSEAL writes the Server
  header sent in the response from the backend. If the backend response did not
  include a Server header, then WebSEAL will not write any Server header to the
  client.

  Writing this header can be suppressed by setting this to "yes".
    suppress-backend-server-identity = no

7.45 Response codes for some message pages are missing (54336)

  The WebSEAL 5.1 Administration Guide provides a table for message
  pages (incorrectly referred to as "error" message pages, as several of the
  pages do not indicate errors) with HTTP response codes.  Complete
  information regarding these WebSEAL HTML error pages (38*.html), including
  HTTP status code returned are omitted from the WebSEAL Admin Guide under the
  section describing the "Static HTML Server Response Pages".

  Filename  WebSEAL Internal Error          Brief Description      Status Code
  --------  ----------------------          -----------------      -----------
  38ad52fa  iv_s_cant_delete_non_empty_dir  Non-empty Directory     HTTP 500
  38cf013d  wand_s_request_too_large        Request Caching Failed  HTTP 500
  38cf0259  wand_s_fetch_sso_info           Could Not Sign User On  HTTP 500
  38cf025a  wand_s_no_sso_info_for_user     User Has No SSO Info    HTTP 500
  38cf025b  wand_s_no_sso_target_for_user   No SSO Target for User  HTTP 500
  38cf025c  wand_s_multiple_sso_target      Multiple SSO Targets    HTTP 500
  38cf025d  wand_s_sso_authentication_req   Login Required          HTTP 500
  38cf025e  wand_s_sso_target_incorrect     Could Not Sign User On  HTTP 500
  38cf025f  wand_s_sso_filtering            Unexpt. Auth Challenge  HTTP 500
  38cf0425  dceweb_st_unauthorized          Login Required          HTTP 401
  38cf0434  dceweb_st_privacyrequired       Privacy Required        HTTP 403
  38cf0442  dceweb_st_mutual_auth_fail      Service Unavailable     HTTP 503
  38cf04c6  wand_s_jct_cant_connect         Server Not Responding   HTTP 500
  38cf04d7  wand_s_jct_service_unavailable  Server Not Responding   HTTP 500
  38cf07aa  dceweb_st_badcgi                CGI Program Failed      HTTP 500
  38cf08cc  webseal_azn_perminfo_fail_reas  Access Denied           HTTP 403
  38cf0437  <MAPPED_TO_INTERNAL_ERROR>      Server Suspended        HTTP 500
  38cf0439  <MAPPED_TO_INTERNAL_ERROR>      Session Info Lost       HTTP 500
  132120c8  <MAPPED_TO_FORBIDDEN>           Authentication Failed   HTTP 403

7.46 Upgrade of TAM 4.1 WebSEAL to TAM 5.1 WebSEAL fails with an
     error message "Unable to create file upgradever.txt" (IY57544)

  If TAM 4.1 WebSEAL is not installed in the default installation
  directory, the upgrade of TAM 4.1 WebSEAL to TAM 5.1 WebSEAL fails
  with an error message "Unable to create file upgradever.txt"
  To prevent this, run the following steps.
    On Windows, create the directory C:\Program Files\Tivoli\PDWeb\etc
        on UNIX, create the directory /opt/pdweb/etc
    Continue with the upgrade steps, as documented in the Tivoli
        Access Manager 5.1 Upgrade Guide under the chapter 'Upgrading
        a WebSEAL server', up to the step that requires TAM WebSEAL 5.1
        to be started in manual mode.
    On Windows, the file upgradever.txt will be created in the
        C:\Program Files\Tivoli\PDWeb\etc directory, while on UNIX
        the file will be created in the /opt/pdweb/etc directory.
    Copy the upgradever.txt file to the installation directory that
        WebSEAL was installed in. For example, on Windows, if TAM 4.1
        WebSEAL was installed in C:\IBM\AM\PDWeb, copy the
        upgradever.txt file from C:\Program Files\Tivoli\PDWeb\etc
        to C:\IBM\AM\PDWeb\etc
    Complete the remaining steps as documented in the Upgrade
        Guide to successfully complete the TAM 5.1 WebSEAL upgrade

7.47 WebSeal ADMIN GUIDE doesn't list network-interface in Appendix A (IY64351)

  Appendix A of the WebSeal Admin Guide should contain the following:

  The network-interface configuration parameter is used to specify an
  alternative I.P. address to be used by the default WebSEAL instance.
  This allows two or more WebSEAL instances to run on the same machine
  listening on the same ports while using different I.P. addresses and host
  names.

  Use the network-interface parameter when you want WebSEAL to only bind to
  one interface.  This will prevent getting the error DPWCF0466E port in use
  when trying to configure on a virtual network interface.

  This stanza entry is not required. Hence, by default, this configuration
  parameter is commented out.

  [server] stanza
  network-interface = 1.2.3.4

  Default value: 0.0.0.0

7.48 Documentation for chpwd and update_pw (IY65998)

  Changing the GSO resource credential password.
  A user can update the stored GSO password for a GSO resource or a GSO
  resource group using the Access Manager Web-based password tool, chpwd.
  Before you can use this tool, a resource credential must have been created.
  Use this tool after first changing the password on the resource.

  Note: use of the chpwd and update_pwd CGI programs is not recommended for
  performance reasons.

  This file can be found at:
  UNIX: /opt/pdweb/www-<instance>/docs/cgi-bin/chpwd
  Windows: C:\Program Files\Tivoli\PDWeb\www-<instance>\docs\cgi-bin\chpwd.exe

  To change the GSO resource credential password using the Web tool:
  1. Open an instance of your secure browser.
  2. Enter the following URL location:
     UNIX: https://webseal server/cgi-bin/chpwd
     Windows: https://webseal server/cgi-bin/chpwd.exe
     Where webseal server is the name assigned to your WebSEAL server. For
     Windows, you must type the .exe extension as part of the URL designation.
  3. Click on the name of the resource in the Resource Name column to select it.
  4. Type your user name in the User ID field.
  5. Type the password you want to change it to in the New Password field. Then,
     confirm it by typing it again in the Confirm New Password field.
  6. Click Update.

  When you click update, the update_pwd CGI program will be invoked to change
  the GSO resource credential password.

  Note: The update_pwd CGI program should not be accessed directly.

7.49 WebSEAL ADMIN GUIDE erroneously mentions "certstepup.html" (IY66932)

  The error in the TAM5.1 WebSEAL Admin. Guide (page 117 of 540, PDF)
  described by the customer should be corrected.  The table under the
  section titled "Custom HTML page descriptions" erroneously contains
  information about a static HTML page which doesn't exist in our product,
  "certstepup.html".

  The correct HTML page name that should go under the "Form" column of
  that table should be "certstepuphttp.html". This is the correct
  information that should be in the table mentioned above:

  Filename:  certstepuphttp.html
  --------

  Title: Attempt to Step-up to Certificate authentication failed.
  -----

  Description: An attempt to step-up to certificates over HTTP failed.
  -----------
               Use of HTTPS is required. Try re-accessing the page over
               HTTPS.

7.50 WebSEAL ADMIN GUIDE is missing the name of the Linux built-in
     switch user shared library (IY67398)

  The WebSEAL Admin Guide has a table under the "Configuring switch user
  authentication" section that lists the platform-specific names of the
  built-in switch user shared library but this table is missing the name
  of the Linux library.

  This is the correct information that should be included in the table
  mentioned above:

        Linux        libsuauthn.so

7.51 Document Generic HTTP Header Session Key Support (57810)

  *** IMPORTANT NOTE:
  This fixpack introduces a change to session key use for clients that
  authenticate using HTTP Headers.

  Before this fixpack, clients authenticating with HTTP
  Headers would always use the HTTP Header as a session
  key.

  After this fixpack, clients authenticating with HTTP
  Headers will use cookies to maintain sessions by default.

  To use the HTTP Header as the session key for clients that authenticate
  with HTTP headers as previously, two changes are necessary in the
  webseald.conf file:

  1) Add the following stanza at the end of the
     configuration file:

     [session-http-headers]
     # List any HTTP headers which will contain a session
     # key on a per-transport basis.  The same header can
     # be listed for both transports if desired.
     #
     # Format is one of:
     #   <header> = http
     #   <header> = https

     In this stanza, enter the name of the HTTP authentication
     header and the transport over which it is used.

     Example:
     This enables the 'entrust-client' HTTP header to be
     used as a session key for both transports.
       [session-http-headers]
       entrust-client = http
       entrust-client = https

  2) Add the following line in the [session] stanza:

     require-mpa = no


  As in previous releases, setting  'ssl-id-sessions = yes' and
  'use-same-session = no' will cause WebSEAL to use the SSL ID
  as the session key for clients connecting over https and not
  use any HTTP header session keys configured for use via the https
  transport.


7.52 The 'pdweb.sescache' statistics component is not documented
     correctly in the Problem Determination Guide (IY67758)

  The information contained in 'Table 30' of the Problem Determination
  Guide is incorrect. The descriptions used to document the
  'pdweb.sescache' statistics component and its information types
  should be updated as follows:

        Type                     Description
        ----                     -----------
        hit              The number of requests that resulted in a
                         session cache hit - that is, the user had
                         a session cache entry and it was
                         successfully referenced.

        miss             The number of requests that missed a
                         session cache hit.

        add              The number of entries that have been
                         added to the session cache.

        del              The number of entries that have been
                         deleted from the cache.

        inactive         The number of times entries have hit
                         the inactivity timeout.

        lifetime         The number of times entries have hit
                         the lifetime timeout.

        LRU expired      The number of times a "Least Recently
                         Used" cache entry is removed to make
                         room for a new entry (a subset of del).

7.53 Implementation of domain cookie name mangling for backward
     compatibility and clarification of domain cookie name mangling
     functionality in "-j" junctions (IY67835, IY85168, IY85168)

   An optional configuration item may be added to the [junction]
   option to reintroduce heritage Webseal domain cookie name mangling
   behavior.  The optional parameter is "mangle-domain-cookies".
   To enable the option, set the parameter to "yes" in the [junction]
   stanza in the webseal configuration file:

   [junction]
   mangle-domain-cookies = yes

   The option is disabled by default.  The option enables domain
   cookie name mangling on a server-wide basis and cannot be configured
   on a per-junction basis.

   If this parameter is not set, webseal does not mangle the name of
   domain cookies.  Valid domain cookies are passed through, and the
   path attribute is set to "/".  Invalid cookies with domain
   attributes which do not tail-match the fully qualified hostname
   or the webseal server will be discarded.  If the
   "allow-backend-domain-cookies" configuration parameter is set,
   the domain attribute is not removed from the cookie; otherwise,
   the domain attribute is removed.

   If "mangle-domain-cookies" is set to "yes", webseal mangles the
   names of domain cookies, and the path attribute is set to "/".
   Information about the junction is added to the cookie name
   and the cookie will only be associated with that junction.  If
   the "allow-backend-domain-cookies" configuration parameter is
   set to "yes", the domain attribute is not removed from the
   cookie; otherwise, the domain attribute is removed.  If the
   "mangle-path-into-cookie-name" configuration parameter is set to
   "yes", the backend path attribute information is also mangled
   into the cookie name.
   

7.54 Attributes in custom entitlement library not in creds (IY69063)

   The proper Title of this should be:
   How to get Custom Attribute(s) and their values via HTTP_HEADER

   Access Manager currently documents the same for attributes from Registry.

   When you develop a Custom Entitlement library and put custom attributes
   in the credential and like to retrieve those attributes as HTTP_HEADER,
   you have to follow this convention:

   All the attributes that needed to be passed as HTTP_HEADER, have to have
   "tagvalue_" prepended to their name in the credential.
   Example: for a custom attribute name "employee_id" with a value "12345",
   it needed to be stored in the credential as tagvalue_employee_id=12345.

   If you have a junction by the name "/jctA", then modify the junction object
   to add the custom attribute as extended attribute like the following:

   object modify /WebSEAL/<host-default>/jctA set attribute HTTP-Tag-Value employee_id=employeeid

   where "employee_id" is the custom attribute without "tagvalue_" prepended and
   "employeeid" will be used to construct the HTTP_EMPLOYEEID  header. So you can
   use any string you like instead of "employeeid". Use the same command to add
   all your custom attributes that you want to pass as HTTP_HEADER.

   Now, modify webseald-default.conf file to add the following:
   [aznapi-configuration]
      cred-attribute-entitlement-services = MY_CUSTOM_ATTR_SVC

   [aznapi-entitlement-services]
      MY_CUSTOM_ATTR_SVC = Your_Custom_library[& any other optional parameter]

   Provide full path of your Your_Custom_library if it is not in the standard lib directory.
   Re-start WebSEAL.

7.55 Configured number of threads more than system can support (IY70268)

   Setting the 'worker-threads = 450' in [server] stanza of the webseald.conf
   file in Solaris, resulted the following warning message:

   DPWWM1499W   The configured number of worker threads, 450, is greater
   than the system can support, 384.  It has automatically been reduced.

   When TAM 5.1 Performance Tuning Guide states the following: (in page 55 )
   "TCP/IP sockets are limited by the number of file descriptors in the
   operating system, based on the following formula:

   (maximum file descriptor - 65 ) / 2.

   The maximum file descriptor is 2,048 on both AIX and Windows, and 1,024
   on Solaris. This limits the maximum number of worker threads to 991 on
   both AIX and Windows, and to 479 on Solaris."

   Explanation:
   The reason for the above warning message is due to a limitations within
   the Solaris operating system and its use of file descriptors.
   Tivoli Access Manager 5.1 introduced a reserve file handles
   (on Solaris, default 256) parameter to ensure sufficient sockets to handle
   load/stress conditions.

   Since FD_SETSIZE on Solaris for 32-bit is defined as 1024, then there are
   only 1024 - 256 = 768 file descriptors available for webseald to use.
   Each worker thread uses 2 file descriptors,
   so max_worker_threads = 768 / 2 = 384 in Solaris operating system.

   However, the reserve file handles are tunable. This is done by adding a
   parameter to the [server] stanza of webseald.conf, which will disable the
   reserve file descriptors and allow the old thread maximum of 479.
   Of course, webseald will need to be recycled after making the change to
   webseald.conf.

   [server]
   ...
   reserve-file-descriptors = 0

   Be advised that setting the parameter to zero, leaves no reserve file
   descriptors for WebSEAL. In Solaris, this may cause WebSEAL sockets to
   consume all of the low numbered file descriptors, so if you choose to
   do this, please test/tune accordingly. This will not be an issue in TAM 600.

7.56 Statistics collected via pdweb.threads statistics does not equal the
   sum of the statistics collected via show <junction> command (IY70884)

   The statistics collected via pdweb.threads is the overall thread usage
   statistics and indicates more than the request traffic. It includes all
   threads associated with the webseald process. The threads statistics
   collected via the show <junction> command only reflect junction traffic
   threads. So if you sum up the thread statistics collected via the
   show <junction> command, this may not be equal to the statistics
   collected with the ´stats get pdweb.threads´command.

7.57 prompt_as_needed cert auth fails if images are in login page (IY69993)

   A new hidden config item will be added to 510 config file:
   [certificate]
   cert-prompt-max-tries = <int>

   The minimum and default value is 2, which configures webseal to
   act exactly as it did before. In order to solve this problem, admins
   need to add this config item, and set it to 5, or possibly more.

   The max value is 15.
   Startup will fail with the following message if a value greater than
   15 is configured:
   "Invalid certificate authentication configuration. Incompatible
   combination of accept-client-certs and ssl-id-sessions values."

   This is a temporary error message until the next fully translated
   version of the product.
   "Modified under defect 60137"

7.58 413 responses from backends expose internal rewind error (IY71685)

   The customer has a webseal server that sends a request to a backend which
   stops reading the request and returns a 413 (Request entity too large) error.
   WebSEAL gives up on the junctioned server, and tries to rewind the request
   in order to retry it on a replica server (on the same junction). WebSEAL can
   fail in rewinding the request if it is too large, causing an error message
   documented as internal to be returned the client. This error message is
   described in the Error Message Reference document on page 243, and is updated
   as follows:

   DPWWA1217E Cannot rewind client request
   Explanation: An error occurred when writing a request to a junction.
   WebSEAL was unable to dispatch the request to another junction server.
   Action: Retry the request.  If the problem continues to occur, attempt to
   discover why the request could not be written to the junction server.  Check
   WebSEAL and junction server log files for unusual error messages.  Try
   sending the request directly to the junction.
   Name: wand_s_jct_cant_rewind_request
   Number: 0x38cf04c1 (953091265)
   Severity: Error
   Component: wwa / wnd_s_jct

7.59 Webseal does not forward ERROR 503
   The customer upgraded from 4.1 to 5.1, and noticed that when a junctioned
   server returned an HTTP 503 error code that it was returned to the client as
   an HTTP 500. This was intentional behavior added in 5.1. There is now a
   descriptive error message returned (which describes the 503 error
   condition) with the HTTP 500 error. If this is not enough information to
   show what error occurred, there is a backward compatibility flag to enable the
   old behavior (sending the 503 error to the client):

   [junction]
   no-remote-jct-error-status-codes = yes

   These changes were introduced in internal defect 62065.

7.60 %BACK_NAME% will be filtered as "NONE" instead of "HOME" when a referrer
     header is not present (IY72614)
   In the TAM WebSEAL Administration guide, on page 89, the description of the
   %BACK_NAME% macro should be:
   The value "BACK" if a referer header is present in the request, or "none" if
   none.

   Instead of:
   The value "BACK" if a referer header is present in the request, or "HOME" if
   none.

7.61 WebSEAL Administration Guide correction (IY73286)
   The documented default value of the failover-update-cookie parameter is
   incorrect.  On p. 177 and on p. 425 of the "WebSEAL Administration Guide
   Version 5.1", it is stated that the default value of the
   failover-update-cookie parameter in the [failover] stanza is 60; however,
   this was changed for Access Manager 5.1.  In the 5.1 release, the default
   value set for this parameter when the webseal server is initially configured
   is "-1".

7.62 Custom CDAS return codes being logged but not displayed in browser
   (IY72745).
   Page 31 of the Web Security Developer Reference is updated from:
   Return user identity to WebSEAL The CDAS library is required to return the
   resulting client identity back to WebSEAL. The client identity is defined
   by the xauthn_identity_t data structure. This structure is returned by
   xauthn_authenticate().

   To:
   Return user identity and authentication status to WebSEAL The CDAS library is
   required to return the resulting client identity back to WebSEAL. The client
   identity is defined by the xauthn_identity_t data structure. This structure
   is returned by xauthn_authenticate(). Additionally, the  authentication
   status, must be returned in the error_status_t parameter to
   xauthn_authenticate. The status must be one of the statuses defined in
   pdxauthn.h This status is logged in msg__webseald.log. The status and
   message served to the browser are mapped from the status returned by the
   CDAS. The mappings are as follows, and all the mapped statuses and their
   associated messages are described in the Error Reference Document.

   Status returned from CDAS  ->  Status returned to browser
   XAUTHN_S_COMPLETE error_status_ok
   XAUTHN_S_FAILURE ivauthn_authentication_failure
   XAUTHN_S_OUT_OF_MEMORY ivauthn_out_of_memory
   XAUTHN_S_AUTHENTICATION_FAILURE ivauthn_authentication_failure
   XAUTHN_S_BAD_AUTHENTICATION_INFO ivauthn_bad_authentication_info
   XAUTHN_S_INVALID_USERNAME ivauthn_invalid_username
   XAUTHN_S_RETRY_LIMIT_REACHED ivauthn_retry_limit_reached
   XAUTHN_S_PASSWORD_EXPIRED ivauthn_password_expired
   XAUTHN_S_ACCOUNT_EXPIRED ivauthn_account_expired
   XAUTHN_S_LOGIN_POLICY_VIOLATION ivauthn_login_policy_violation
   XAUTHN_S_NEW_PIN ivauthn_new_pin
   XAUTHN_S_ACCOUNT_DISABLED ivauthn_account_disabled
   XAUTHN_S_NEXT_TOKEN ivauthn_next_token
   XAUTHN_S_MAPPING_FAILED ivauthn_mapping_failed
   XAUTHN_S_CERTIFICATE_AUTH_FAILURE ivauthn_certificate_auth_failure
   XAUTHN_S_HTTP_HEADER_AUTH_FAILURE ivauthn_http_header_auth_failure
   XAUTHN_S_IP_ADDR_AUTH_FAILED ivauthn_ip_addr_auth_failed
   XAUTHN_S_SU_INVALID_USERNAME ivauthn_su_invalid_username
   XAUTHN_S_SU_NO_PERMS ivauthn_su_no_perms
   XAUTHN_S_PASSWD_POLICY_VIOLATION ivauthn_passwd_policy_violation
   XAUTHN_S_PASSWD_TOO_SHORT ivauthn_passwd_too_short
   XAUTHN_S_PASSWD_HAS_SPACES ivauthn_passwd_has_spaces
   XAUTHN_S_PASSWD_TOO_MANY_REPEATED ivauthn_passwd_too_many_repeated
   XAUTHN_S_PASSWD_TOO_FEW_ALPHAS ivauthn_passwd_too_few_alphas
   XAUTHN_S_PASSWD_TOO_FEW_NONALPHAS ivauthn_passwd_too_few_nonalphas
   XAUTHN_S_PASSWD_ACCT_LOCKEDOUT ivauthn_passwd_acct_lockedout
   XAUTHN_S_POST_PWDCHG_FAILED ivauthn_post_pwdchg_failed
   All other statuses are mapped to ivauthn_unknown_error

7.63 Certificate login error page does not work as documented (IY74261)
   Page 152 of the WebSEAL Administration Guide describes when the
   certerror.html page is returned:
   WebSEAL provides a default HTML page containing an error message that is
   displayed when a user fails to successfully authenticate using client-side
   certificate authentication.

   The section should be supplemented with the following:
   Note that this page is not returned when a revoked certificate is presented.
   Because certificate revocation is handled in the SSL layer, when a revoked
   certificate is presented, the SSL connection is immediately closed,
   resulting in a browser error page.

7.64 When using IBM 4960 crypto card, UNIX-GROUP must be set to PKCS11 (IY74618)
   On page 37 of the WebSEAL Administration Guide, the following should be
   appended to the section titled 'Configure WebSEAL and GSKit to use the
   PKCS#11 shared library':

   It's also necessary to modify the configuration file to make the webseald
   process to run in group pkcs11:

   [server]
   unix-group = pkcs11

7.65 ECSSO works with request caching. (IY65436)

   ECSSO works with request caching.

   A new hidden configuration item has been added in the
   e-community-sso stanza:
   cache-requests-for-ecsso = <boolean>

   Adding this item and setting it to true will enable
   request caching for ECSSO, the default is false.

7.66 README: Idle timeout before actual login is attempted (IY70071)

   If reauth-for-inactive = true is set in webseald.conf., and a client requests
   a protected resource, but does not submit his authentication information
   until after the inactivity timeout has passed (by default 240 sec). The user
   will be immediately prompted with another login form.

   A hidden parameter has been added to webseald.conf:

   [session]
   login-reset-lifetime = FALSE

   If the parameter is set to true, not only will expired sessions be
   reactivated upon authentication, but the time until expiration will be reset
   in non-expired sessions also.

7.67 Many erroneous responses not logged in request log (IY72402)

   A new config flag has been added to enable more thorough request logging:

   [logging]
   log-invalid-requests = yes

   This is a hidden config item which will default to 'yes'.

   When it is set to 'no', then webseal will not log erroneous requests that
   exit early, including the cases for IY53140 and IY42080. When it is set
   to 'yes', webseal will log all these requests.

   In order for IY53140 and IY42080 to work now, log-invalid-requests must not
   be set to 'no.' Customers using these existing fixes should not need to
   modify their config files because the default value of this item is 'yes.'

7.68 Additional configuration is needed for IY65805 (reference IY75372)

   IY65805 is a backport of a security fix made in amweb600.
   When using reauth-for-inactive, WebSEAL needs to make an additional check to
   verify the user has reauthenticated to the proper authentication level
   (password, token-card, certificate), this is so that the user is not improperly
   granted access to objects protected by an auth-level POP.

   To pass this additional check, add the following entry to webseald-<instance-name>.conf:

   [failover-restore-attributes]
   AUTHENTICATION_LEVEL = preserve

7.69 Allow relative URL in redirect location - backward compatibility (IY74759)

   In order to enable this functionality, a new config option must be added to
   the config file:

   [server]
   redirect-using-relative = false

   This hidden config option defaults to false, which leaves webseal unchanged.
   When it's set to true, location headers in redirect responses will be sent
   as relative URLs.

7.70 Document POST body character encoding requirements for DynURL. (IY74052)
   On page 48 of the WebSEAL Administration Guide, the following passage
   introduces reserved character escaping in URL's:

      Browsers are limited to a defined character set that can legally 
      be used within a Uniform Resource Locator (URL). This range is defined 
      to be the printable characters in the ASCII character set (between 
      hex code 0x20 and 0x7e)

   This is a statement reflecting the dictates of RFC 2396. It is not 
   a general statement of WebSEAL's behaviors, which are more restrictive
   than 2396 for the security reasons described below.

   The Guide does not explicitly detail the requirement that WebSEAL
   restricts all requests that it applies authorization checks upon to 
   UTF8 or the WebSEAL host's locale setting. This means all backend 
   servers are bound by these settings. WebSEAL must enforce this 
   restriction so it may apply security policy on known authorization 
   objects. 

   Page 55 of the WebSEAL Administration Guide describes how to prevent
   "400 - Bad Request" errors when the query string of a request URL is
   in a character encoding WebSEAL does not understand. 

   The explanation neglects to inform that DynURL applies to POST bodies, 
   in addition to query strings. Both need to be in a character encoding 
   WebSEAL understands for it to be able to map character patterns to 
   authorization objects. 

   If WebSEAL is configured to use DynURL and is running in a non-UTF-8 
   environment, and the POST body contains UTF-8 characters, use the 
   configuration entry utf8-form-support-enabled to allow WebSEAL to 
   decode it properly. If the POST body contains characters that are neither
   UTF-8, nor in WebSEAL's local charset, WebSEAL will reject the POST body
   and DynURL cannot be used.

7.71 Incorrect action for DPWWA2080E message (IY75033)
   The documented corrective action for the message "DPWWA2080E The session 
   inactivity timestamp is missing from the failover cookie." is incorrect.
   It should read, "Set failover-require-activity-timestamp-validation to no."
   
   Note that the WebSEAL Administration Guide refers several times to a 
   "session inactivity timestamp" in a failover cookie.  There no such thing.
   The correct wording is "session activity timestamp" and the correct
   configuration option is "session-activity-timestamp".
   
7.72 SUSE SLES9 of zSeries is not supported (66818)
   TAM does not support SuSE SLES9 on zSeries. Previous Fixpack inadvertently
   mentioned that TAM supports SuSE SLES9 on zSeries.

7.73 Update to the supported MIT Kerberos5 versions on the Linux
     platforms. (IY77010)

   Problem:  Due to recent bug fixes within the Microsoft SPNEGO
   authentication protocol, the version of MIT Kerberos5 listed in our
   "Plug-in for Web Servers Integration Guide" (Chapter 3, page 73), can
   no longer be supported on the Linux platform.  Some vendors of Linux
   may include outdated versions of Kerberos5 which may require
   upgrading.

   Fix:  Please download and install a newer version of MIT Kerberos5.
   The required minimum level would be MIT Kerberos5 version 1.2.8, the
   recommended level would be MIT Kerberos5 version 1.4.2.  These may
   be down-loaded from MIT's website at the following location:

   http://web.mit.edu/kerberos

   The following steps are the recommended method to compile and install
   the upgraded Kerberos5 on your Linux based system:

   1. Build - After extracting the source code, cd into the kerberos
   base directory and run as root:
      ./configure --enable-static --without-krb4
      make
   If you have problems running any of the above commands, please check
   the included MIT documentation.

   2.  Install - The default installation would be the /usr/krb5/lib, 
   you can edit the Makefile to change this if needed, then run as root:
      make install
   Again, if you have problems running the above command, please check 
   the included MIT documentation.

   3.  Configure - All the kerberos code is now compiled and installed. 
   To modify your system to use the updated libraries (this includes
   TAM), run as root:
      ldconfig

   4.  Check - To check that the libraries are properly installed, run 
   as root:
      ldconfig -v | more
   You should see something in the output that looks like this:
      /usr/krb5/lib:
           libgssrpc.so.1 -> libgssrpc.so.1.4
           libgssapi_krb5.so.1 -> libgssapi_krb5.so.1.4
           libkrb5.so.1 -> libkrb5.so.1.4
           libk5profile.so.1 -> libk5profile.so.1.4
           libksvc.so.1 -> libksvc.so.1.4
           libkdb5.so.1 -> libkdb5.so.1.4
           libkadm5clnt.so.1 -> libkadm5clnt.so.1.4
   This example shows the output after installing MIT Kerberos5 1.4.2 in
   the default directory, your output may vary based on the exact 
   version/options you use.

   Note that after installing the upgrade, both the pdmgrd and webseald 
   processes will require restarting before they will use the new 
   libraries.  Failure to restart these processes may result in said 
   processes crashing.

7.74 WebSeal ADMIN GUIDE does not contain Linux instructions for
     installing SPNEGO.  (67132)

   Problem:  In the WebSeal Admin Guide, Chapter 9, under the heading
   "Windows desktop single sign-on configuration".  Step 3 begins the
   installation steps for the Kerberos runtime client on Unix, however
   there is no listing for Linux.

   Solution:  Please follow the steps provided for the Solaris platform
   when configuring Kerberos for Linux, for step 3 onward.  Do not
   follow the steps listed for AIX.

7.75 Customers with root users having shell other than ksh or sh may 
     face problems running the pdweb_start script(IY79257)

     If the root user has a shell other than ksh or sh, the user may
     encounter problems while trying to run the pdweb_start script.
     To resolve this, do the following:
     First check the pdweb_start script in /opt/pdweb/bin. The first 
     line in the script should read #!/bin/sh
     If this is not the case and there is another line with version
     information that starts with # @(#), please remove this line with
     the version information. The first line in the script should be
     #!/bin/sh

7.76 SUSE SLES9 does not install Korne Shell (ksh) by default (67370)

   Problem:  During TAM configuration, scripts may fail to run,
   stating that /bin/ksh was not fould.  The standard SLES 9, Yast
   based installation did not install the Korne Shell at /bin/ksh.

   Solution:  Please install the pdksh-5.2.14-685.[platform].rpm or
   above, where the [platform] matches that of the hardware you are
   installing TAM onto.  This rpm may be found on either the SLES 9
   installation media, or downloaded from the SUSE or Novel support
   web sites.
   
7.77 Config parameters limiting reposting aren't doc'd (IY79911)
   
   Three undocumented config parameters have been added to WebSEAL 5.1
   starting with FP17 to control the reposting of requests in various 
   ways so as to make WebSEAL 5.1's behavior more like WebSEAL 4.1.  
   These parameters are as follows:
   
   disable-referer-based-reposts
     This parameter will completely disable junction reposts after 404 
     errors, where the repost data is coming from the referer header 
     (if in use).  This parameter disables only referer based reposts.
   
   limit-cookie-based-reposts
     This parameter will limit the junction reposts after 404 errors, 
     where the repost data is coming from the junction cookie (if in 
     use).  This parameter disables/limits only cookie based reposts.
   
   dont-reprocess-jct-404s
     This parameter will stop all junction reposts, period.  This
     parameter stops all reposting.
   
   Future releases of WebSEAL will not support the first two options, 
   but will support dont-reprocess-jct-404s.

7.78 -J junction cookie script not XHTML 1.0 compliant (IY75809)

   The create option for scripting support junction (-j), inserts a
   script into outgoing HTML documents in a manner which breaks
   XHTML 1.0 compliance. The script tag must be lowercase to satisfy
   the standard's case-sensitivity, and the tag must provide a "type"
   attribute instead of a "language" attribute. A new pdadmin option
   was added to address this:

   pdadmin sec_master> server task <WebSEAL server> create \
                     -t <transport> -h <host> -j -J xhtml10 /jct

   When a junction is created with the -J xhtml10 option, the IV_JCT
   cookie generation script added to HTML documents will comply with
   XHTML 1.0:

   <script type="text/javascript">
   <!-- 
   document.cookie = "IV_JCT=%20jct; path=/";
   //-->
   </script>

   To fully comply with XHTML 1.0 or HTML 4.01 Strict document type
   definitions, two pdadmin options (-j and -J) must be used in
   conjunction.

   pdadmin sec_master> server task <WebSEAL server> create \
                    -t <transport> -h <host> -j -J xhtml10,inhead /jct

7.79 Pdadmin command for making authorization space root object
     for replicated fron-end webseal servers incomplete (IY82120)

   In the WebSEAL Administration Guide, Chapter 2, "WebSEAL Server
   Configuration" under the section "Replicated front-end WebSEAL servers",
   in step 2, an incomplete example is given about creating an object using
   pdadmin. The complete command should be like:

   pdadmin> object create /WebSEAL/newroot "Description" 5 \
	    ispolicyattachable yes

7.80 Handling CDSSO PD-ID and PD-REFERER query string arguments (IY82093)

   The following CDSSO information is pertinent to a CDSSO deployment where
   the destination resource is on a junctioned server (/jct in this example).

   In CDSSO, a /pkmscdsso request is redirected to the destination server. The
   redirect contains the destination URL and the authentication token.

   For example, the following initiating CDSSO request:

   http://ws1.test1.com/pkmscdsso?http://ws2.test2.com/jct/DocServlet/get?docID=453082

   is redirected to the destination server as:

   http://ws2.test2.com/jct/DocServlet/get?docID=453082&
   PD-REFERER=ws1.test1.com&PD-ID=<cdsso-token>

   The HTTP header trace reveals that this request is passed to the /docserv
   junctioned system as:

   GET /DocServlet/get?docID=453082&PD-REFERER=ws1.test1.com&PD-ID=<cdsso-token>

   When this GET request is received by the junctioned server, it is possible that
   some applications might expect only docID=453082 
   and could have difficulty resolving:
   &PD-REFERER=ws1.test1.com&PD-ID=<cdsso-token>

   Be aware that the PD-REFERER and PD-ID query string arguments are passed to
   junctioned servers when using the CDSSO.

7.81 Directory permission was changed after installing PDWebADK  (IY85268)

   After performing an installation of Tivoli Access Manager WebADK (PDWebADK) or one of its patches, 
   the user and group ownership of /opt/pdwebrte have been set to 'ROOTID' and 'SYSTEMGID' with '750' 
   file permission. This directory should have "755" permission. If you have installed Tivoli Access Manager WebADK 
   or one of its patches, on a Unix platform, you should check the /opt/pdwebrte for correct file permission.

   If you see file permission of '750', please use the following two commands as a work-around to correct the problem.
   You must run the following commands from the 'root' account, and from the root (/) directory.

   (To find the file permission)
   ls -l /opt | grep pdwebrte

   (To fix the permission)
   chmod -R 755 /opt/pdwebrte

   The above commands will modify the permission of /opt/pdwebrte and its sub directories.

7.82 New configuration option - allow-shift-jis-chars (IY82621)
   
   To enable the changes for IY82621 and allow shift-jis characters to be
   used within path names, the parameter "allow-shift-jis-chars" should be
   set to "yes" in the [server] stanza of the webseal configuration file:

   [server]
   allow-shift-jis-chars = yes

7.83 New configuration option - error-on-pipelined-request (IY83227)

   Webseal does not support Pipelined Requests.  According to the RFCs, any
   webserver not supporting pipelined requests, should detect them and respond
   with a 500 BAD REQUEST error.  Webseald has been modified to detect
   pipelined requests and will now produce an error when it is detected.
   To enable this behavior, the parameter "error-on-pipelined-request"
   should be set to "yes" in the [server] stanza of the webseal configuration
   file:
   
   [sessions]
   error-on-pipelined-request = 1

7.84 New configuration option - use-filename-for-pkmslogout (IY86806)

    If a request that results in a management page is made and the query string
    "filename=<whatever>" is present in the request, WebSEAL will return
    the file specified instead of the appropriate page listed under
    the [acnt-mgt] stanza of webseald.conf.

    If the file is invalid (filenames with path traversal are illegal,
    eg: "filename=/etc/passwd") WebSEAL falls back to the appropriate file listed
    in the [acnt-mgt] stanza of webseald.conf.

    If the file is not present, WebSEAL returns 500 server error.

    A configuration option "use-filename-for-pkmslogout" is added under the 
    [acnt-mgt] stanza. This option is added to provide backward compatibility.
    
    [acnt-mgt]
    use-filename-for-pkmslogout = [true|false]

    This option can be set to true if webseal should permit the filename
    query string to override the default acnt mgmt page. The default value for
    this option is false.
    
7.85 Document update - Name used when creating SPNEGO account  (IY90379)

    In the WebSEAL Administrator Guide page 237, in Step 1, second note: it states
    that only the short machine name may be used as the mapuser name.  You may 
    also use the FQDN of the webseald machine.  For example, with a webseald 
    system name of webseal.sub1.ibm.com, you may use either 'webseal' or the
    entire machine name, 'webseal.sub1.ibm.com' as the username.

7.86 WebSEAL sessions have inaccurate expiry time (IY90315)

    A new parameter should be set in the [session] stanza:

    max-timeout-flush-interval=60
         
    This parameter specifies the time interval in seconds between session cache updates. 

    If the customer needs to have more accurate session timeouts then they should add this 
    parameter to the config file. The same applies for failover-cookie timeout.

    Lower values of this parameter will have more accurate session timeout but this might 
    affect the performance as the frequency of session cache updates increases.

7.87 Error message reference used the wrong names for configuration 
     file settings (IY92997)
    
    The entry for DPWWA0317E should read:

    DPWWA0317E The request was too large to store in the session cache.

    The request size exceeded request-max-cache or the message body exceeded
    request-body-max-read, so the request could not be stored in the session cache. 
    
7.88 WEBSEAL IS RESETING THE REQUEST AND NOT CLOSING A PIPELINE (IY90982)

   COPING WITH PIPELINED REQUESTS FROM BROWSERS

   WebSEAL is currently unable to handle the processing of requests which are received 
   in a pipelined format. Often the browser will display an error, or the page will not
   correctly load if pipelining has been enabled. To cope with pipelined requests correctly, 
   an option has been added to WebSEAL which will allow for the detection of pipelined
   requests. Then, upon detection, WebSEAL will fulfill the first request, and follow 
   this by closing the connection. The browsers which currectly support pipelining, should
   detect this closed connection and resend the pipelined requests as individual requests.  
   This should be done automatically and the page will now load correctly.  

   NOTE: 
   WebSEAL still does not support pipelining, however, this may change in a future release.

   To enable the connection closing when a pipelined request is received, use the following 
   option in the webseald.conf file for the instance to be changed:

   Under the [server] stanza, add
   cope-with-pipelined-requests = yes

   Re-start this WebSEAL instance.

7.89 New configuration option - dynamic-addresses (IY96223)

   A new parameter may be set in the [junction] stanza:

   dynamic-addresses = yes.

   This parameter defaults to "no".  When enabled it causes WebSEAL to resolve the
   Junction Server host name to an IP address every time WebSEAL creates a connection
   to the Junction Server.  It would be prudent when using this option to either
   place all hosts in /etc/hosts or setup a caching DNS server on the local machine
   and point /etc/resolv.conf to it.  All Junction Servers are affected by this option.

7.90 CONTENT COMPRESSION RULES NEGLECTED (IZ00793)
   An agent type configured in the [compress-user-agents] stanza to not receive 
   pages compressed by WebSEAL can still be sent pages compressed by WebSEAL.  A
   new config parameter has been added to enable the fix to this defect.  Adding
   
       use-compress-user-agent-in-caching = yes
       
   to the [server] stanza of WebSEAL's conf file will cause the caching code to
   serve a compressed variant of a page to an agent only if the 
   [compress-user-agents] stanza allows compression for that type of agent.

7.91 Document additional verification of macro values (81389)

   TAMeB has been updated to perform additional verification of macro values
   before embedding macros in template pages. However, additional changes might
   be necessary in some customer environments depending on how TAMeB template
   pages have been customized.  If you have customized your TAMeB template
   pages, you should review your customizations to make sure they follow the
   guidelines in this section.

   Refer to the WebSEAL administration guide for background information on
   TAMeB template pages and macros.  The remainder of this section discusses
   how to safely embed macros in template pages.


   TYPES OF MACROS

   TAMeB template page macros fall in to two categories, URL macros and non-URL
   macros.  URL macros are used to represent URLs, such as the HTTP request URL
   and the referer URL.  Non-URL macros are used to represent other values,
   such as user names and error messages.

   The following macros are URL macros:

   %LOCATION%
   %URL%
   %REFERER%
   %BACK_URL%
   %HOSTNAME%
   %HTTP_BASE%
   %HTTPS_BASE%
   %REFERER_ENCODED%
   %URL_ENCODED%

   All other macros are non-URL macros.


   ENCODING OF MACROS

   TAMeB encodes macros prior to embedding the macros in HTML template pages.
   Encoding ensures that macro values are interpreted as text, and not as
   javascript or HTML meta characters.  URL macros are URI encoded.  For example,
   the '<' character in URLs is converted to "%3c".  Non-URL macros are encoded
   using HTML entities.  The '<' and '>' are encoded as "&lt;" and "&gt;".
   Other HTML metacharacters in non-URL macros are encoded using numeric
   character references.  For example, the double-quote character '"' becomes
   "&#34;".

   TAMeB encodes the following characters in URL macros:
     Less-than sign: <
     Greater-than sign: >
     Colon: :
     Apostrophe: '
     Quotation mark: "
     Backslash: \
     All values less than ASCII 0x20

   TAMeB encodes all of the above characters in non-URL macros, as well as:
      Ampersand: &

   TAMeB verifies that all URL macros, except the HOSTNAME macro, are either
   absolute or server relative http:// or https:// URLs.  TAMeB verifies that
   the HOSTNAME macro contains only alphanumeric ASCII characters, dots, and
   hyphens.
  


   USING MACROS IN TEMPLATE PAGES

   Caution must be employed when embedding macros in HTML template pages to
   avoid introducing cross-site-scripting vulnerabilities to your TAMeB
   deployment.

   URL macros may be safely used as HTML text.  To use a macro as HTML text,
   embed the macro between HTML tags.

   For example:
       <b>%URL%</b>

   URL macros may be safely used as HTML attribute values for HTML attributes,
   but only for attribute values that are intended for use with URLs.  When
   using macros as HTML attribute values, the macro must be surrounded by
   double or single-quotes.

   For example:
       <a href="%URL%">Clickable link</a>

   URL macros may be safely used as javascript string values, but must be
   surrounded by double or single-quotes.

   For example:
       var url = '%URL%';

   Non-URL macros may be safely used as HTML text.  To
   use a macro as HTML text, embed the macro between HTML
   tags.
  
   For example:
        <b>%USERNAME%</b>

   Non-URL macros may be safely used as HTML attribute values, but only for
   attribute values that are NOT intended for use with URLs.  When using
   macros as HTML attribute values, the macro must be surrounded by double
   or single-quotes.

   For example:
        <input type="text" name="user" value="%USERNAME%>

   Non-URL macros may be safely used as javascript string values, but must be
   surrounded by double or single-quotes.

   For example:
       var user = '%USERNAME%';


   CHOICE OF HTML TAGS AND ATTRIBUTES

   Both URL and non-URL macros can be safely used with most commonly used
   HTML tags.  However, there are certain HTML tags and attributes that use
   special syntax different from normal HTML tags.  For example, the
   contents of <style> tags are interpreted as cascading style sheets, rather
   than as normal HTML.  TAMeB macros are encoded for use with normal HTML
   tags and attributes, and should not be used inside HTML tags whose
   contents are not interpreted as HTML.

   There is typically no reason to include TAMeB macros in HTML tags whose
   contents do not follow normal HTML syntax.  If you are unsure of the
   syntax used by particular HTML tags, refer to your browser documentation
   and the W3C HTML specifications for additional information.

   Note also that non-URL macros such as %USERNAME% should not be used as
   HTML attribute values for attributes that are intended for URLs.  Using
   non-URL macros as URLs can introduce cross-site-scripting vulnerabilities
   in to your deployment.


   ACCESSING MACROS FROM JAVASCRIPT

   There are two mechanisms for accessing TAMeB macros from javascript.
   Macros can be used as javascript strings, or they can be accessed via the
   HTML DOM.

   To access a macro as a javascript string, simply use the macro between
   double or single quotes.

   For example:
      var username = "%USERNAME%";

   When using macros as javascript strings, be aware that the macro value may
   contain URI encodings or HTML entity encodings.  The javascript unescape()
   function may be used to remove URI encodings from macro values.  Use of
   the HTML DOM is recommended to remove HTML entity encodings.  For example,
   the following HTML code could be used to remove entity encodings from the
   %USERNAME% macro, the following HTML code could be used:

   <span id='user' style='visibility: hidden'>%USERNAME%</span>
   <script>
      var user = document.getElementById('user');
      if (user && user.firstChild) {
          var name = user.firstChild.nodeValue;
      }
   </script>

   The name variable will contain the contents of the %USERNAME% macro.  You
   can then use this variable as needed. However, be careful not to introduce
   DOM-based cross-site-scripting vulnerabilities in to your HTML template
   pages when using macro values.  DOM-based cross-site-scripting is described
   here:

   http://www.webappsec.org/projects/articles/071105.shtml

7.92 New configuration option - connection-request-limit (IZ07508)

   A new integer configuration parameter, "connection-request-limit" is added
   to the "server" stanza to allow configuration of the maximum number of
   transactions which are allowed on a persistent connection.  The default
   value for this parameter is set to the previously hardcoded value of 100:


   [sessions]
   connection-request-limit = 100

7.93 New configuration option - preserve-base-href2 (IZ10008)

   A new boolean configuration parameter, "preserve-base-href2" is added
   to the "server" stanza.  
   If both preserve-base-href and preserve-base-href2 are set to yes, 
   then WebSEAL will only perform the minimum filtering of the BASE HREF 
   tag necessary to insert the WebSEAL host and junction names.
   If preserve-base-href is no, preserve-base-href2 has no effect.  
   The default value for this parameter is no, which matches the previous
   behavior of WebSEAL:

   [server]
   preserve-base-href2 = no

7.94 Step-up to Basic Authentication is not supported (IZ17083)
    
    Appendix A of the WebSEAL Administration Guide implies in the section for 
    the [authentication-levels] stanza that step-up to basic authentication is
    supported; however, only forms authentication is supported when setting
    level = password. 
   

8.0 SOFTWARE LIMITATIONS
------------------------
8.1 Images in acct_locked.html are not displayed when using ba-auth (IY84076)
   
   When using basic authentication (ba-auth), any images added to the
   acct_locked.html file will not be displayed. 
   
   Possible workarounds:
   1. Use an authentication method other than ba-auth.
   2. Place those images on other web servers.

8.2 Auto-resending of POST requests are not supported with stateful junctions
    (IZ04849)

   Unless disabled via other options, WebSEAL will automatically repost a request
   to the back-end junction, after receiving a 404 (Not Found) error on the first 
   attempt.  If the junction being used has been configured with the '-s' (stateful)
   option AND the request being sent is of the POST type AND said request contains
   post body data -- that data will be stripped out during the second (reposting)
   of the request.

   This version of WebSEAL does not support the above scenario.  If you require
   the auto-reposting functionality in this version, then you can not use stateful
   junctions.

9.0 KNOWN PROBLEMS AND WORKAROUNDS, IF AVAILABLE
------------------------------------------------
The following problems are known to exist after installing this patch. Some
known problems are identified by internal tracking numbers.

9.1 WebSEAL installation wizard hangs (45569) (reference APAR IY52675)

  The WebSEAL installation wizard hangs when WebSEAL is configured to listen
  on a port already in use.

  Workaround: Ensure that the HTTP and HTTPS listening ports are not already
  in use by another service before running the WebSEAL installation wizard.
  The default listening ports are port 80 and 443. To see what ports are
  already in use, run:

  netstat -an

9.2 Install the WebSEAL language package prior to configuring WebSEAL (44829)

  HTML files of foreign languages are not copied to www-instance/lib/html if
  the WebSEAL language package is installed after WebSEAL is configured.

  WORKAROUND:
  Install the WebSEAL language package prior to installing WebSEAL. If the
  WebSEAL language package is installed after WebSEAL is configured, you must
  unconfigure WebSEAL and then configure it again for the HTML pages to be
  copied to the correct directory.


9.3 File Downloads getting truncated when no/short delay is involved (APAR IY48098)

  The significance of two webseald.conf parameters is changing and a third,
  optional, webseald.conf parameter is being added.

  The client-connect-timeout parameter is now used for timing-out only the
  initial read of a client connection after the accept() succeeds.

  The persist-con-timeout parameter is now used for timing-out only the initial
  read of a persistent client connection.

  A new, optional, parameter is being introduced, intra-connection-timeout.
  Its value, if non-zero, is used to time-out all other read/write operations
  on an SSL connection to the client.  The default value for this new parameter
  is the value of the client-connect-timeout parameter.

9.4 SWITCHUSER DOESN'T WORK FOR USERS OTHER THAN SEC_MASTER (IY47522)

  PROBLEM DESCRIPTION:
  Following the instruction from webseal admin manual to set up
  "switchuser (SU) for administrators" and ran in some problem. steps:

  1. add user into su-admins, make sure there are not in su-excluded
  2. modify webseald.conf to enable switch_user
  3. configure the switch user authentication mechanism
  4. restart webseal

  If user is authenticated and goes to

     https://<webseal>/switchuser.html

  they get a page not found, even though user is in su-admins group.
  However, sec_master can access the switchuser.html page.


  PROBLEM EXPLANATION:
  This problem is caused by a situation where in webseald.conf...

     USER-AND-GROUP-IN-SAME-SUFFIX=yes

  for performance boost reasons.

  Although the user is added to the su-admins group, the user's suffix

     dn: secAuthority=Default,cn=user123,o=ibm,c=us

  is not the same as the defined suffix for sec_master
  
     dn: secAuthority=Default,cn=SecurityMaster,secAuthority=Default

  Thus, when the search begins to find the added user under the admin
  suffix, the user is not found and the switchuser attempt fails.

  WORKAROUND:
  The workaround is to change webseald.conf to explicitly set

     USER-AND-GROUP-IN-SAME-SUFFIX=no

  This will allow a non-exclusive search of all suffixes for any user
  belonging to the su-admins group and will allow them to use switchuser in
  WebSEAL.



10.0 NOTICES
------------
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this
document in other countries. Consult your local IBM representative for
information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or
imply that only that IBM product, program, or service may be used. Any
functionally equivalent product, program, or service that does not infringe
any IBM intellectual property right may be used instead. However, it is the
user's responsibility to evaluate and verify the operation of any non-IBM
product, program, or service. IBM may have patents or pending patent
applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents.
You can send license inquiries, in writing, to:

IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.

For license inquiries regarding double-byte (DBCS) information, contact the
IBM Intellectual Property Department in your country or send inquiries, in
writing, to:

IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law: INTERNATIONAL
BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions; therefore, this statement may not
apply to you.

This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this
IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information that has been exchanged, should contact:

IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758
U.S.A.

Such information may be available, subject to appropriate terms and
conditions, including in some cases, payment of a fee.

The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer
Agreement, IBM International Program License Agreement or any equivalent
agreement between us.

Any performance data contained herein was determined in a controlled
environment. Therefore, the results obtained in other operating environments
may vary significantly. Some measurements may have been made on
development-level systems and there is no guarantee that these measurements
will be the same on generally available systems. Furthermore, some measurement
may have been estimated through extrapolation. Actual results may vary. Users
of this document should verify the applicable data for their specific
environment.

Information concerning non-IBM products was obtained from the suppliers of
those products, their published announcements or other publicly available
sources. IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.

All statements regarding IBM's future direction or intent are subject to
change or withdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include
the names of individuals, companies, brands, and products. All of these names
are fictitious and any similarity to the names and addresses used by an actual
business enterprise is entirely coincidental.



10.1 Trademarks

The following terms are trademarks or registered trademarks of International
Business Machines Corporation in the United States, other countries, or both:

AIX
IBM
IBM logo
iSeries
pSeries
S/390
Tivoli
Tivoli logo
xSeries
zSeries

Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc.
in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and
other countries.

Other company, product, and service names may be trademarks or service marks
of others.



End of IBM Tivoli Access Manager for e-business WebSEAL, Patch 5.1.0-TIV-AWS-FP0036 README
