Fix (APAR):  WAS_Security_03-17-2003_4.0.5-4.0.4-4.0.3_AE_cumulative_Fix

Status:  Fix

Release:  4.0.5,4.0.4,4.0.3

Operating System:  All

Supersedes Fixes:  PQ61779, PQ62538, PQ62684, PQ63116, PQ63574
                    WAS_Security_09-13-2002_4.0.4-4.0.3_AE_cumulative_eFix
                    WAS_Security_10-07-2002_4.0.4-4.0.3_AE_cumulative_eFix
                    WAS_Security_10-31-2002_4.0.4-4.0.3_AE_cumulative_eFix,
                    WAS_Security_11-19-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix an
                    WAS_Security_01-06-2003_4.0.5-4.0.4_AE_cumulative_eFi
                    as well as any eFixes for APARs listed below




CMVC Defect:  See APAR list below

Byte size of APAR:  1413178

Date: 03/20/2003

Abstract:  Security cumulative fix.

Description/symptom of problem:  See APAR list below




Directions to apply fix:  



1) Create temporary "efix" directory to store the jar file
             AIX: /tmp/WebSphere/efi
   Solaris/Linux: /tmp/WebSphere/efi
         Windows: c:\temp\WebSphere\efi


2) Copy jar file to the director


3) Shutdown WebSpher


4) Run the jar file with the following command answering questions/prompts as they appear
   java -jar <jarfile name


5) Restart WebSphere


6) The temp directory may be removed but the jar file should be saved.  Do not remove
   any files created and stored in the <WASHOME>/WebSphere/AppServer/efix/<efix> directories
   These files are required if an efix is to be removed








Directions to remove fix:  



NOTE:  EFIXES MUST BE REMOVED IN THE ORDER THEY WERE APPLIED.  DO NOT REMOVE AN EFIX UNLES
       ALL EFIXES APPLIED AFTER IT HAVE FIRST BEEN REMOVED.  YOU MAY REAPPLY ANY REMOVED EFIX


Example:  If your system has efix1, efix2, and efix3 applied in that order and efix2 is to b
          removed, efix3 must be removed first, efix2 removed, and efix3 re-applied




1) Change directory to the efix location (<WASHOME>/WebSphere/AppServer/efix/<efix#>)


2) Shutdown WebSpere

3) Run the backup jar file with the following command
   java -jar <backup_efix#


4) Restart WebSphere

Directions to re-apply fix:  



Follow the instructions for applying an efix.  If the backup files still exist (from the
previous efix application), you will be prompted to overwrite.  Answer "yes" at the overwrite
prompts








Additional Information:  

-----------------------------------------------------------------

On 4.0.3,the cumulative system management fix dated 2/19/2003 or later, must be applied.
In addition, either PQ69951 or PQ70054 must be applied.
Any fix which contains the aforementioned APARs is allowable.

If the following exception is encountered after applying the fixes, apply the latest
JSSE fix:

java.net.SocketException: Socket close
       at java.net.PlainSocketImpl.socketSetOption(Native Method
       at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:210
       at java.net.Socket.setKeepAlive(Socket.java:619
       at ...


The administration server and all application servers and clients which use the
Websphere installation directory must be stopped for proper application of this eFix


Important note, if any of the following fixes have been applied this eFix may take an
exceptionally long time to install (possibly up to 15 minutes or more depending system
speed)


   PQ61779, PQ62538, PQ62684 or PQ6311


Some systems may encounter an error similar to the following while
applying this eFix. 


   2002/10/04 14:09:47  Command= /opt/WebSphere/AppServer/temp/FixSecurityJar.sh /opt/WebSphere/AppServe
   2002/10/04 14:09:48     RC=xx
   2002/10/04 14:09:48 Error 112 -- The return code of xxx is not equal to the expected return code of 0


If you have not applied any of the 4 cumulative security efixes
listed below on your system, then you can ignore these error
messages in the extractor log. They are harmless and should not
cause you any problems


   PQ61779, PQ62538, PQ62684 or PQ6311


If you have applied any of the above 4 cumulative security efixes
on your system and get these errors when applying a later
cumulative security efix, then this would be a valid error.


There are two resolutions to this error.  The first is to remove
this eFix and all previous eFixes in the opposite order they were
installed until all of the eFixes listed above have been removed
Then all other eFixes including this one can be reapplied.  The
error above will still occur during installation but it can be
ignored


The second is to follow the steps below. 


   For Windows, execute the following
   (Note use _AEs_ instead of _AE_ in commands below on AEs systems.


      cd \WebSphere\AppServe
      bin\setupCmdLine.ba
      %JAVA_HOME%\bin\jar -xvf WAS_Security_10-31-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar temp\FixSecurityJar.ja
      %JAVA_HOME%\bin\jar -xvf WAS_Security_10-31-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar temp\FixSecurityJar.ba
      temp\FixSecurityJar.bat %WAS_HOME
     
   For UNIX systems, execute the following
   (Note use _AEs_ instead of _AE_ in commands below on AEs systems.
  
      . bin/setupCmdLine.s
      $JAVA_HOME/bin/jar -xvf eFix/WAS_Security_10-31-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar temp/FixSecurityJar.ja
      $JAVA_HOME/bin/jar -xvf eFix/WAS_Security_10-31-2002_4.0.4-4.0.3-4.0.2_AE_cumulative_eFix.jar temp/FixSecurityJar.s
      . temp/FixSecurityJar.sh $WAS_HOME     




The following properties must be set for PQ56218 to be effective


In the admin.config file
com.ibm.CORBA.ListenerPort=200
com.ibm.CORBA.SSLPort=200
com.ibm.CORBA.LSDPort=900
com.ibm.CORBA.LSDSSLPort=900


In each of the Application servers system properties:
com.ibm.CORBA.ListenerPort=300
com.ibm.CORBA.SSLPort=300


Note, each port number must be unique and must not be in use by any other service
on the system




To enable PQ63020, set the following property in the admin.config
com.ibm.ejs.security.customregistry.useSecurityName=tru




Included APARS






 APAR: PQ59412 Version: 350
      Abstract:
      PERFORMANCE PROB WITH THE SSOAUTHENTICATO
     
      Error Description:
      Together with Dennis R we (Ranier D.) discovered a performanc
      problem with the SSOAuthenticator running websphere porta
      on WAS.  The specific details of the analysis are outlined i
      notes between Rainer and Dennis
      Local Fix:
      No local fix is known
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users      which have enabled 
      ecurity and are using   a Custom Login
     
      Problem Description: Performance improvement for            SSOAuthenticator.login()
     
      Recommendation:
      Problem Summary: A significant amount of time of SSOAuthenticator.login(
      execution is spent in getSecurityServer().  The result fro
      getSecurityServer() method has not been used since v3.0 and i
      no longer necessary
      Problem Conclusion: The call to this method has been removed
      Test Comments:
      Circumvention: non
      Temporary Fix: non
      Comments:






 APAR: PQ63457 Version: 400
      Abstract:
      ALLAUTHENTICATEDUSERS NOT WORKING FOR ROLE MAPPIN
      Error Description:
      Environment
      WebSphere Application Server (WAS) 4.0.
      
      Description
      Mapping an application role to the AllAuthenticatedUsers rol
      available by checkbox in the security center did not functio
      as prescribed...users were denied access to pages afte
      authenticated succeeded
      Local Fix:
      Non
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users      who have security e
      abled and are using     WebSphere Studio Application Develope
      (WSAD) to create and deploy EARs with       security role r
      ferences
      Problem Description: Users given access to a resource via   the special role "All Au
      henticated    Users" receive authorization failures
      Recommendation:
      Problem Summary: Users given access to a resource via the special role "Al
      Authenticated Users" receive authorization failures.  Th
      reason for this was that WAS erroneously creating empty acces
      ID for special authorization subjects "All Authenticated Users
      and "Everyone."  These special authorization subjects are no
      supposed to have access IDs which cause the name to be used a
      the access ID
      Problem Conclusion: Code was added at runtime to recreate the access ID as th
      name if the supplied ID is empty
      Test Comments:
      Circumvention: Edit the EAR with the AAT and remove the reference t
      "All Authenticated Users" and "Everyone," then save.  Edit i
      again and re-add the references
      Temporary Fix: Contained in security cumulative eFix PQ63457 or more recent
      Comments:






 APAR: PQ63243 Version: 400
      Abstract:
      SECJ0055A: AUTHENTICATION FAILED FOR WRONGUSER ON  WAS 4.0
      WINDOWS 200
      Error Description:
      Authorization fails when using a Custom Registry if th
      implementations of getUniqueUserId() and getUserSecurityName(
      do not return the same string
      Local Fix:
     
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users who have implemented a custo
      registry
      Problem Description: Authorization from ltpa token may fail if user security name i
      different     from user ID in custom registry
      Recommendation:
      Problem Summary: Custom registry allow that a User ID is different the user&apos;
      security name, and user ID and user name got mixed
      Problem Conclusion: Custom registry allow that a User ID is different the user&apos;
      security name, and access ID during authorization should b
      based on user ID
      Test Comments:
      Circumvention:
      Temporary Fix: A test fix was supplied and verified
      Comments:






 APAR: PQ63574 Version: 400
      Abstract:
      INTERMITTENT AUTHORIZATION FAILURES FOR AUTHENTICATED USERS THA
      BELONG TO A ROL
      Error Description:
      Intermittent authorization failures occur for authenticate
      users who are properly configured for a security role.  Th
      customer has discovered that the problem may not b
      intermittent, and may instead occur on the first web applicatio
      loaded when starting an application server.  The problem seem
      to occur because for the first web app loaded the user registr
      value is null on the call to addAuthorizationTable(), s
      fillMissingAccessIds() does not occur.  This results in th
      roles information not being available when performin
      authorizations for those roles
      
      This problem may be the same as the one reported in interna
      defect 139504
      Local Fix:
      The customer has worked around the problem by building 
      workaround into the WSAccessManager.  They inserted a fix int
      the constructor whose signature is "publi
      WSAccessManager(RegistryImpl registryimpl)".  The fix simpl
      inserts a call to fillAccessIds() to force the authorizatio
      information to be loaded
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y
      Problem Description: Intermitant authorization problems due to improper authorizatio
      table        initialization
      Recommendation:
      Problem Summary: Intermittent authorization problems due to imprope
      authorization table initialization.  The tables were no
      initialized properly due to the improper use of a boolea
      value which was used to indicate initialization state of th
      tables
      Problem Conclusion: The boolean value was used at times to indicate a single tabl
      had been initialized when it should only be used to indicat
      all tables had been initialized.  This was corrected
      Test Comments:
      Circumvention:
      Temporary Fix: Contained in security cumulative eFix PQ63457 or more recent
      Comments:






 APAR: PQ66162 Version: 400
      Abstract:
      SERVERSIDEAUTHENTICATOR DOESN&apos;T THROW EXCEPTIO
      Error Description:
      SSOAuthenticator - When use
      1. Authenticates userid and password
      2. Throws exception when authentication fails (works correctly
      3. Set HttpRequest and HttpResponse LPTA cookie so that the
      can b
      passed by servlet
      4. DOES NOT SET THE CONTEXT for SAS communication for ej
      layer.  S
      the ejb thinks the user is UNAUTHENTICATED and fails
      
      ServerSideAuthenticator - When use
      1. Authenticates userid and password
      2. DOES NOT Throws exception when authentication fails
      3. DOES NOT Set HttpRequest and HttpResponse LPTA cookie s
      that the
      can be passed by servlet
      4. Set context for for SAS communication for ejb layer
      
      So,  with this being the case,  i have to use 2 separate API t
      authenticate correctly and set the desired information to enabl
      J2E
      security framework.  Right now I call ServerSideAuthenticato
      first the
      SSOAuthenticator.  Seems kind of expensive to me and confusing
      
      Customer requests a fix for ServerSideAuthenticator for WAS 4.0
      on AIX
      
      Whe
      ServerSideAuthentication fails to authenticate,  it returns 
      null credential.  Not basic credentials.  Second,  a client ma
      use ServerSideAuthenitcate for authentication purpose only
      They may never go to a secure resource (like ejb)  after that
      Or my ejb may not be secure....I know that the ejb containe
      will through the error because the user is UNAUTHENTICATED
      This is not new to us developers,  however
      WAS is relying on the Ejb Serve
      Container (security mechanism) to throw the error for simple WA
      authentication...Not authorization...this is not correct
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users who uses ServerSideAuthentic
      tor to perform          authentication
     
      Problem Description: ServerSideAuthenticator should throw   LoginFailed when login f
      ils
      Recommendation:
      Problem Summary: ServerSideAuthenticator should thro
      org.omg.SecurityLevel2.LoginFailed exception when th
      login fails and the force_authn flag is true instead o
      returing a null credential
      Problem Conclusion: ServerSideAuthenticator will now thro
      org.omg.SecurityLevel2.LoginFailed exception when login fails
      Test Comments:
      Circumvention:
      Temporary Fix: Availabl
      Comments:






 APAR: PQ67823 Version: 350
      Abstract:
      FIRST ATTRIBUTE IN DN IS NOT SEARCHABLE EVEN IT SHOULD BE ALWAY
      SEARCHABL
      Error Description:
      The problem with using bluepages occurs since the firs
      attribute in DN is not searchable even it should be alway
      searchable.  What we are proposing to deal with this kind o
      directory defects  is to search DN after RDN query fails.  Thi
      way, I do not break current  working functionalities, and mak
      some improperly structured directory working with som
      limitations
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       users with LDAP as 
      user registry when     the LDAP schema has an attribute which 
      s   not searchable in the DN
      Problem Description: Security can not query relative DN     from LDAP with if any at
      ributes of theDN are not searchable
      Recommendation: Properly configure Ldap to make attributes  in DN searchable
      This is not a WebSphere defect, and we 
      ry  give customers with improperly configured   ldap some lever
      ges. The support of this    kind of ldap is limited, and som
      functionalities such as SSO with non        WebSphere a
      plication may loss. The         long term solution for this kin
      of         problem is to fix the ldap server to make   attribu
      es in DN searchable
      Problem Summary: If the first attrribute of the DN is not searchable
      WebSphere is unable to query relative DN to perform nam
      normalization.  This may be caused by multiple reasons
      Secureway 3.2.2, 3.1.1 and possibly other versions have 
      defect which makes this attribute unsearchable.  Some OEM LDA
      servers may also have this defect.  Also, configuratio
      errors can cuase this issue.  Some LDAP servers may nee
      to be configured to make specific attributes searchable
      Some LDAP servers are configured to require a Bind DN befor
      certain attributes can be searched as well
      Problem Conclusion: If Relative DN is non-searchable, WebSphere will query D
      itself and use this result.  However, if the Relative D
      search fails, and the full DN search is used, SSO may no
      function with WebSeal or Domino.  If this problem occurs
      the only resolution is to make the Relative DN searchable
      Test Comments:
      Circumvention: Properly configure the ldap server, and make first attribut
      in DN searchable
      Temporary Fix: test internall
      Comments:






 APAR: PQ67828 Version: 400
      Abstract:
      FIRST ATTRIBUTE IN DN IS NOT SEARCHABLE EVEN IT SHOULD BE ALWAY
      SEARCHABL
      Error Description:
     
      Local Fix:
     
     
      Logically Dependent Apars: 
      Users Affected:
      Problem Description:
      Recommendation:
      Problem Summary:
      Problem Conclusion:
      Test Comments:
      Circumvention:
      Temporary Fix:
      Comments:






 APAR: PQ68063 Version: 400
      Abstract:
      HANG WHEN CONFIGURING SSL FOR LDAP WITH VERSION 4.0.3 AND OCT. 
      2002 CUMULATIVE SECURITY EFIX APPLIE
      Error Description:
      After installing the Oct. 7, 2002 cumulative security efix on 
      4.0.3 system, the customer hangs when trying to configure SS
      between WebSphere and the LDAP server.  If the customer remove
      the efix, the customer does not hang when configuring SSL fo
      LDAP.  There were no error messages in the trace files
      This error was reported on a Solaris 8 machine
      Local Fix:
      No local fix is available for this hang error
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server who have       enabled security an
      configured LDAP over   SSL
     
      Problem Description: Failure to configure SSL between       WebSphere and LDAP
     
      Recommendation:
      Problem Summary: WebSphere fails to reload the SSL configuration from th
      repository during security configuration.  This prevent
      the Security Center GUI from accessing LDAP to validate 
      user during LDAP configuraion which ultimately causes th
      new configuration to fail on update
      Problem Conclusion: The SSL Configuration is now reloaded from the repository i
      configuration is changed
      Test Comments:
      Circumvention: Enable security without configure LDAP over SSL. Restart server
      and configure LDAP over SSL
      Temporary Fix: provided testing and tracing module to customer
      Comments:






 APAR: PQ69036 Version: 400
      Abstract:
      APPLYING 11/19 CUMULATIVE SECURITY EFIX ON WAS 4.0.4 CAUSE
      SECJ0129A AUTHORIZATION FAILURE THAT DIDN&apos;T OCCUR BEFORE EFI
      Error Description:
      Environnment
      WebSphere Application Server (WAS) 4.0.4 A
      LDAP serve
      
      Description
      After applying the 11/19/2002 cumulative security eFix
      customer starts getting the following exception in the stdou
      file that didn&apos;t occur before the cumulative security efix wa
      applied
      
      12/5/02 10:29:02:301 CST  6e93ebd8 WebCollaborat A SECJ0129A
      Authorization failed for <user> while invoking POST o
      default_host:<url>, Authorization failed, No
      granted any of the required roles: <existing role
      Local Fix:
      Remove the cumulative security eFi
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users who have enabled security an
      use LDAP for the user  registry
     
      Problem Description: Authorization failure (403) received   after security cache tim
      out is        exceeded
      Recommendation:
      Problem Summary: After the cache timeout is exceeded, authorization failure
      (403) could occur.  The reason is while creating ne
      credentials, the group type was not properly appended t
      the group name which cuased the authorization code to fai
      in finding the proper group name in security roles
      Problem Conclusion: The group type is now properly appended to the group name
     
      A fix for this APAR will be contained in any securit
      cumulative eFix dated after the closure date of this APAR
      Test Comments:
      Circumvention:
      Temporary Fix: A test fix was provided
      Comments:






 APAR: PQ69643 Version: 400
      Abstract:
      AUTHORIZATION (403) FAILURES FORWARDING FROM AN UNPROTECTE
      SERVLET OR JSP TO A PROTECTED ONE
      Error Description:
      Authorization (403) failures when forwarding from a
      unprotected servlet or JSP to a protected one
      This issue can also be seen if the contect root is no
      protected but the default page is protected as a forwar
      is implicit in this scenario
      Local Fix:
      Protect the initially requested page
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users      who have enabled se
      urity and are           using RequestDispatcher.forward() t
      forward from an unprotected servlet         or JSP to a pro
      ected one
      Problem Description: Authorization failure (403) is         received
     
      Recommendation:
      Problem Summary: An authorization failure is received when usin
      RequestDispatcher.forward() to forward from an unprotecte
      servlet or JSP to a protected one
      Problem Conclusion: The servlet 2.3 specification, section 12.2, specifies that th
      security model does not apply when using a RequestDispatcher
      Therefore, the recommended resolution to this issue is t
      protect the URI which is invoking RequestDispatcher.forward()
      This prepares the application for migration to WebSphere 5.X
     
      If this is not possible then setting the following property o
      each application server will yield a challenge when forwardin
      from an unprotected URI to a protected one
     
      com.ibm.ws.security.RequestDispatcherChallenge=tru
     
      Code implementing this property will be contained in an
      security cumulative eFix dated after the closure date of thi
      APAR as well as the cumulative eFix dated 01-06-2003
     
      Internal defect number 155475
      Test Comments:
      Circumvention: Protect the URI which is invoking RequestDispatcher.forward()
      Temporary Fix:
      Comments:






 APAR: PQ61779 Version: 400
 APAR: PQ59667 Version: 350
      Abstract:
      AUTHORIZATION FAILS WITH AN EXTERNALLY CREATED LTPA TOKEN
      Error Description:
     
      Local Fix:
     
     
      Logically Dependent Apars: 
      Users Affected:
      Problem Description:
      Recommendation:
      Problem Summary:
      Problem Conclusion:
      Test Comments:
      Circumvention:
      Temporary Fix:
      Comments:






 APAR: PQ59684 Version: 400
      Abstract:
      WITH SECURITY ON, AND PASSING THE SECURITY CHALLENGE, TH
      RETURN URL IS NOT CORRECT WHEN THE SERVLET IS IN A SUBDIRECTOR
      Error Description:
      The customer requests the following URL
      http://mburati02:9080/bowstreet5/webengine/factory/admin/Factor
      Admi
      After successfully logging in, it incorrectly redirects to th
      following mangled URL
      http://mburati02:9080/bowstreet5/webengine/factory/admin/Factor
      Admin/factory/admin/FactoryAdmi
      Local Fix:
      Make sure that the requested servlet is accessible from th
      context root of the webapp
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server developers     using Form Login ba
      ed security
      Problem Description: Form login redirection fails when      security is enabled
     
      Recommendation:
      Problem Summary: When Form Login based security is enabled, the originall
      requested url is not properly sent to the client if the for
      login page is located in a directory different tha
      the originally requested url
      Problem Conclusion: Modified the storing of the originally requested url t
      properly handle whether the redirect should be relativ
      to the context root of the web module or the web server
      Test Comments:
      Circumvention:
      Temporary Fix: //wasdoc0/apars/pq59684/4.0.2_4.0.
      Comments:






 APAR: PQ59959 Version: 350
      Abstract:
      LTPATOKEN COOKIE NOT CREATED FOR THE CERTIFICATIO
      AUTHENTICATION CAS
      Error Description:
      Customer has a setup with WAS 3.5.3 where they use Trus
      Association and users come via TA as well as without goin
      through it.  Customer notices significant performanc
      degradation in the case when TA is not used.  That seems to b
      because customer uses certificate authentication and we do no
      cache certificates
      Local Fix:
      non
     
     
     
     
     
     
     
     
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       users of client cer
      ificate authentication
      Problem Description: Ltpa Token cookie not returned for     client certificate authe
      tication
      Recommendation: This is a performance APAR. If you are      using client certif
      cate, and you also      enable SSO, apply this eFix for bette
      performance
      Problem Summary: While using client certificate authentication, if SSO i
      enabled, Ltpa cookie is expected (could be verified fro
      browser). However, ltpa cookie was never returned. Whenever 
      new request is made, the user is reauthenticated via th
      user&apos;s certificate instead of being validated by an Ltp
      Token.  The former operation requires user registry call
      which can be very time consuming where the latter does not
      Problem Conclusion: The expected Ltpa cookie is now returned for clien
      certificate authentication
      Test Comments:
      Circumvention:
      Temporary Fix: PQ59959-356.ja
      Comments: a testing eFix for 3.5.6 has been send to customer






 APAR: PQ60862 Version: 400
      Abstract:
      WAS 4.0.2 EXPECTS CONFIG FILE TO BE SPECIFIED IN TRUSTEDSERVERS
      PROPERTIES EVEN IF THE TA INTERCEPTOR DOES NOT HAVE ADD PROP
      Error Description:
      In WAS 4.0.2 It seems like the trust Association properties ar
      stored in WCCM. IN earlier version i.e 3.5.X th
      trustedservers.properties was stored in a config file
      Local Fix:
      There is no need to store the Trust Association properties i
      WCCM, so we will continue to read the properies fro
      trustedservers.properties file as we were doing in ASV35
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users      implementing a Trus
      Association Interceptorand not subclassin
      WebSphereBaseTrustAssociationInterceptor    and implementin
      the init() function
      Problem Description: WAS4.0.2 expects Config file to be     specified in trustedServ
      rs.properties even though the TAI does not have any  additiona
      properties
      Recommendation:
      Problem Summary: The problem is that only those Trust Association Interceptor
      that have additional properties need to specify an additiona
      file in trustedservers.properties. In WAS 4.0.2 the Trus
      Association properties are stored in WCCM. This was done i
      such a way that it became necessary to specify an additiona
      file even though the TAI did not have any additional propertie
      to specify. In earlier versions i.e 3.5.X all the propertie
      for Trust Association were read from a file
      Problem Conclusion: There is no need to store the Trust Association properties i
      WCCM. The problem has been resolved by reading the Trus
      Association properties from a file exactly the same manno
      as WebSphere 3.5.6
      Test Comments:
      Circumvention: The customer can simply put any file name for config file i
      trustedservers.properties file. The customer will need to writ
      an init() method that does nothing. The fix for this proble
      is in CMVC now and is part of ptf 4 on ASV40X
      Temporary Fix: ZE FIX ERROR PQ62438 02/06/27                    PQ60862_test.j
      
      Comments:






 APAR: PQ60895 Version: 400
      Abstract:
      WASSEC - AUTHENTICATION INFORMATION NOT RETURNED TO THE BROWSE
      IF A PROTECTED URI IS NOT ACCESSED BEFORE J_SECURITY_CHECK POST
      Error Description:
      If authentication information is posted to j_security_chec
      before a protected URI is accessed, the browser does no
      receive authentication information and therefore subsequen
      requests of protected resources fail.  Failure stack in app sv
      stdout (excerpt)
      ExtendedMessage: Servlet Error: : java.lang.NullPointerExceptio
      a
      com.ibm.servlet.personalization.sessiontracking.SessionContext.
      sProtoc
      lSwitch(SessionContext.java:1884
      a
      com.ibm.servlet.personalization.sessiontracking.SessionContext.
      houldEn
      odeURL(SessionContext.java:1834
      a
      com.ibm.servlet.engine.srt.SRTSessionAPISupport.encodeURL(SRTSe
      sionAPI
      upport.java:137
      a
      com.ibm.servlet.engine.srt.SRTServletResponse.encodeURL(SRTServ
      etRespo
      se.java:220
      a
      com.ibm.servlet.engine.webapp.HttpServletResponseProxy.encodeUR
      (HttpSe
      vletResponseProxy.java:51
      a
      com.ibm.ws.security.web.FormLoginServlet.formLogin(FormLoginSer
      let.jav
      :388
      a
      com.ibm.ws.security.web.FormLoginServlet.doPost(FormLoginServle
      .java:1
      0
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:760
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853
      a
      com.ibm.servlet.engine.webapp.StrictServletInstance.doService(S
      rvletMa
      ager.java:827
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users      using Form Login
     
      Problem Description: The browser failed to receive          authentication informati
      n when the    Form Login page was directly accessed
      Recommendation:
      Problem Summary: The browser failed to receive authentication information whe
      the Form Login page was directly accessed instead of bein
      redirected to the page by attempting to access a protected URI
      Problem Conclusion:
      Test Comments:
      Circumvention:
      Temporary Fix: Test fix supplied on 5/22/2002
      Comments:






 APAR: PQ61020 Version: 350
      Abstract:
      WAS 3.5.6 TRUST ASSOCIATION DOESN&apos;T ALLOW OTHER TYPES O
      AUTHENTICATION TO WOR
      Error Description:
      Environment
      WebSphere Application Server 3.5.
      
      Description
      Customer was using WAS 3.5.3, and when trust association i
      enabled, they are still able to authentication via other method
      (basic, certificate, etc.). After upgrading to WAS 3.5.6
      enabling trust association caused any authentication to b
      treated as if it is coming from WebSeal. As a result
      authentication done via basic, certificate, etc. fail becaus
      they don&apos;t contain the header information that the trus
      association interceptor expects
      Local Fix:
      None
     
     
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users who      enable Trust Associ
      tion with WebSeal
      Problem Description: After Trust Association is enabled withWebSeal, authentication 
      ails if the   request is not via WebSeal
      Recommendation:
      Problem Summary: After Trust Association is enabled with WebSeal
      authentication fails if the request is not from WebSeal
      If the request header contains a &apos;via&apos; tag (even i
      this tag has no value), authentication functioned as expected
      However, if the &apos;via&apos; tag was missing, then authenticatio
      fails
      Problem Conclusion: The WebSeal Trust Association interceptor now checks if th
      &apos;via&apos; tag value is not present and treats this condition th
      same as if the &apos;via&apos; tag was not present in the reques
      header
      Test Comments:
      Circumvention:
      Temporary Fix: send a testing eFix to custome
      Comments:






 APAR: PQ62519 Version: 400
 APAR: PQ61868 Version: 350
      Abstract:
      TRUST ASSOCIATION MUCH SLOWER THAN BASIC AUTHENTICATIO
      Error Description:
      Customer is hitting URI being served and secured by WAS wit
      more than 100 users within a 2 minute period using WebSeal an
      Trust Association. They get an average response time of about 5
      seconds. However, this time is only 10 seconds when using Basi
      Authentication without Trust Association
      
      The security traces seem to show that several seconds are spen
      in the LTPA Token Validation cache for every hit
      Local Fix:
      Non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security users who uses Trust Asso
      iation as the           authentication mechanism
     
      Problem Description: Trust association authentication is    much slower than other a
      thentication
      Recommendation:
      Problem Summary: Trust association is much slower due to the same securit
      credential being created twice
      Problem Conclusion: The first credential is now cached so the same crdentia
      can be retrieved from cache to improve performance
      Test Comments:
      Circumvention:
      Temporary Fix: A test fix was supplied
      Comments:






 APAR: PQ61912 Version: 350
 APAR: PQ62438 Version: 400
      Abstract:
      UNABLE TO LOGIN TO WEBSPHERE PORTAL SERVER WITH A USER I
      BELONGING TO A DBCS IN ACTIVE DIRECTORY
      Error Description:
      Customer running WebSphere Application Server 3.5.4 with Activ
      Directory as LDAP. Logging in to WebSphere Portal Server fail
      when login ID is a user in a double byte character set (DBCS
      Organizational Unit (when OU is in Japanese). Customer is abl
      t
      login if the user belongs to an OU that is in English or othe
      single byte character set
      Local Fix:
      No known workaround. This is a problem in both WebSpher
      Security code and Portal Server code. This APAR is for th
      WebSphere Security portion
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       users which have us
      d double byte           characters in security names
     
      Problem Description: Authorization fails when a login user  name contains double byt
      characters
      Recommendation:
      Problem Summary: If a user tries to login WebSphere with a name containin
      double byte characters, the user receives authorizatio
      failure error messages
      Problem Conclusion: The problem is caused by incorrect internal data conversio
      of double byte characters to byte arrays
      Test Comments:
      Circumvention:
      Temporary Fix: A test fix was supplied
      Comments:






 APAR: PQ62260 Version: 400
      Abstract:
      OUT OF MEMORY CONDITION WHEN WAS R403 IS UNDER HEAVY LOAD WIT
      SECURITY ENABLE
      Error Description:
      Customer using a CustomRegistry and running a load test with 10
      stress clients that do the following
      - authenticate using a Trust Association & the custom registr
      - fetch a single JSP pag
      - pause 10 second
      - leave the site. NO LOGOU
      - repea
      The clients use userids out of a possible population of abou
      10,000 userids. Thus, over a reasonable period of time, WAS wil
      see 10,000 unique userids
      The admin server, over a long period of time, logs out of memor
      errors.  In this case, it took 4 hours
      Local Fix:
      none
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y using LTPA            authentication
     
      Problem Description: Slow performance and high CPU usage    during security cache cl
      aning cycles  and possible OutOfMemoryExceptions
      Recommendation:
      Problem Summary: Slow performance and high CPU usage during security cach
      cleaning cycles and possible OutOfMemoryExceptions.  Thes
      issues are seen on servers with a large number of differen
      users (12000 on the reported system) accessing the syste
      within the security cache timeout period.  The performanc
      problem was a result of the cache cleaning algorithm whic
      evaluated each cache entry as to whether or not it needed t
      remain in the cache.  The out of memory condition was 
      result of the algorithms failure to remove cache entries
      Problem Conclusion: The cache cleaning algorithm was changed to evaluate all cach
      entries inserted into the cache within a similar time perio
      (one half the security cache timeout) at the same time.  Th
      new algorithm guarantees that the vast majority of entrie
      will stay in the cache for the minimum of the security cach
      time out.  There is now the potential for a small number o
      cache entries to be flushed from the cache early or for 
      cache miss to occur when there should have been a hit.  Thi
      is negligible in comparison to the amount of time saved i
      cache cleaning, however
      Test Comments:
      Circumvention:
      Temporary Fix:
      Comments:






 APAR: PQ62459 Version: 400
      Abstract:
      TRUST ASSOCIATION DOESN&apos;T EXECUTE CLEANUP() WHEN IT IS UNLOADE
      Error Description:
      Environment
      WebSphere Application Server 4.0.2 A
      
      Description
      Customer discovered that when using Trust Association, th
      cleanup() method call is never called. It is expected to b
      called when the Trust Association Interceptor is unloaded
      Local Fix:
      A workaround is to implement a finalize() class in the Trus
      Association Interceptor class. For example
      
      protected void finalize(
      
      cleanup(
      
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       users using Trust A
      sociation as an         authentication mechanism
     
      Problem Description: The cleanup() method in the trust      association interceptor 
      s not         invoked
      Recommendation:
      Problem Summary: The cleanup() method in trust association interceptor is no
      invoked when application server is stopped
      Problem Conclusion: Placed cleanup() call for trust association interceptors i
      in code executed during application server shutdown
      Test Comments:
      Circumvention:
      Temporary Fix: provided test eFix
      Comments:






 APAR: PQ62577 Version: 400
      Abstract:
      WILD CARD CHARACTERS ARE NOT TREATED PROPERLY
      Error Description:
      Wild card characters are not treated properly in the user nam
      at login time. for example
      User ID  Adm
      Password natara
      can get you into WAS
      Can reproduce this on DOMINO LDAP or Secureway directory
      Local Fix:
      none
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users who use  LDAP user registry 
      n authentication
      Problem Description: Wild card characters in a user name    are not treated properly
     
      Recommendation:
      Problem Summary: An "*" represent any character in LDAP if not escaped
      WebSphere did not escape any "*" in a user&apos;s name
      It is important to note that unless the user has only on
      match in the registry when the "*" is treated as a wil
      card, the user will be refused authentication.  The user
      password must still be correct as well
      Problem Conclusion: WebSphere security will escape "*" if user name contains "*
      in our Ldap registry implementation, and ldap filter wil
      check a value with the character "*", rather than treat "*" a
      any character
      Test Comments:
      Circumvention:
      Temporary Fix: provided testing eFi
      Comments:






 APAR: PQ62684 Version: 400
      Abstract:
      CREATE ACCESSID AT RUNTIME IF THEY HAVE NOT BEEN CREATED
      Error Description:
      Customer is adding to Role Group Roles using WSCP, WSCP did no
      create and AccessID in the process.  The results ar
      authorization exceptions when using the group
      Local Fix:
      Manually add Roles to Group Roles through the AAT tool but thi
      is too manual a process due to the large volume of users an
      nodes etc
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users      adding groups to Ro
      es via WSCP
      Problem Description: Authorization failures for members of  groups that were added t
      a Role via   WSCP
      Recommendation:
      Problem Summary: Authorization failures for members of groups that were added t
      a Role via WSCP.  The problem stemmed from the fact that WSC
      was not inserting an access ID for the group, which is use
      internally by WebSphere for authorization, into the Role
      Problem Conclusion: The security runtime now creates an access ID if it is missing
      Test Comments:
      Circumvention: Use the AAT or the Administration Console
      Temporary Fix: testing eFix was send to customer
      Comments:






 APAR: PQ63020 Version: 400
      Abstract:
      ADD FUNCTIONALITY TO TOGGLE GETREMOTEUSER() TO RETURN ACTUA
      USER ID INSTEAD OF THE DISPLAY NAME WHEN USING CUSTOM REGISTR
      Error Description:
      Environment
      WebSphere Application Server 4.0.3 A
      
      Description
      Customer is implementing LTPA custom user registry. When the
      perform getRemoteUser() or getPrincipalName() mathods, they ge
      the display name (as a result of getUserDisplayName() metho
      call) instead of the actual user ID, and there seems to be n
      alternative to acquire the user ID when the getUserDisplayName(
      is implemented to return other than the user ID. The develope
      suggests creating a configuration item to toggle getRemoteUser(
      to return the user ID instead of the display name
      Local Fix:
      Non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users who use  custom registry aut
      entication
      Problem Description: Wehn using a custom registry, the API  getRemoteUser() returns 
      isplay name   rather than security name
      Recommendation: Apply this eFix, or use the display name    as the same as the 
      ecurity name
      Problem Summary: When using a custom registry implementation, security returne
      the user&apos;s display name for getRemoteUser() an
      getPrincipalName() instead of the user&apos;s security name
      Problem Conclusion: If getRemoteUser() and getPrincipalName() are required t
      return the user&apos;s security name, a system property has bee
      added to enable this
     
      com.ibm.ejs.security.customregistry.useSecurityName=tru
      Test Comments:
      Circumvention:
      Temporary Fix: test eFix provided
      Comments:






 APAR: PQ68148 Version: 400
 APAR: PQ65884 Version: 350
      Abstract:
      REQUESTDISPATCH.FORWARD() TO A PROTECTED SERVLET FAIL
      Error Description:
      
      Failing on security when doing requestdispatch.forward() to 
      protected servlet (and now failing) from the "baseLogon" serve
      that calls SSOAuthenticator. After calling SSOAuthenticator
      the request thread should have a security context establishe
      and should not fail on the requestdispatch.forward() call
      Local Fix:
      Test efix PMR81595-356-test-0829 fixed the customer&apos;s problem
      Need official efix
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y
      Problem Description: Users may not be properly challenged   while accessing secured 
      esources
      Recommendation:
      Problem Summary: Authenticated user may get challenged again, o
      unauthenticated user may not be challenged as authenticatio
      was not properly flaged.  This scenario is only likely t
      occur if a servlet forwards or dispatches to anothe
      secured servlet
      Problem Conclusion: The flag used to determine authentication was not use
      correctly.  The flag has now been removed as it i
      redundant
      Test Comments:
      Circumvention:
      Temporary Fix: test eFix has been send to custome
      Comments:






 APAR: PQ66136 Version: 400
      Abstract:
      SSO (SINGLE SIGNON) FROM WEBSPHERE APPLICATION SERVER (WAS) T
      DOMINO SERVER FAILS WHEN THE USER NAME CONTAINS DBC
      Error Description:
      With user info( such as first name or last name
      in DBCS chinese characters, after login t
      the WPS or WAS successfuly, then when access th
      domino web server, domino will challege the use
      with a login page with  error ms
      "Your session with the server has expired or is invalid"
      But when SSO from one WPS server to the other WPS serve
      or SSO from one WAS server to the other WAS was fine
      when the user info totally in english charcters (SBCS)
      the SSO from WAS or WPS to domino is fine, and so d
      from domino to WAS/WPS is fine.   The problem only happen
      when user info has chinese field ( uid is in english, bu
      first name or last name is in chinese DBCS chars )
      
      WAS Change Team (L3) supplied an efix and it fixed the problem
      
      The root cause for this defect is that WebSphere and Domin
      calculate digital signature differently if user nam
      contains dbcs. While converting user name to byte array t
      calculate digital signature,websphere treated every characte
      as single byte character. With this fix, Websphere is no
      using UTF8 to calculate digital signature
      Local Fix:
      request a copy of the efix from WAS C/T
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       customers who use d
      uble byte characters    in user&apos;s security name
     
      Problem Description: SSO between WebSphere and non          WebSphere products(such 
      s Domino)     fails if user security name contains   double byt
      characters
      Recommendation:
      Problem Summary: SSO between websphere and non WebSphere products fails i
      security name contains double byte character. The root caus
      is was a difference in algorithms used to create digita
      signatures
      Problem Conclusion: Change WebSphere security to follow UTF8 conversion rule t
      calculate digital signature. First using UTF8 rule to conver
      user name to a byte array, then caclulate digital signatur
      from the byte array
      Test Comments:
      Circumvention:
      Temporary Fix: provide test eFi
      Comments:






 APAR: PQ66082 Version: 350
      Abstract:
      SSO FAILS FOR DBCS USERNAME FOR WAS 3.5.
      Error Description:
      Customer found their WPS/Domino could perform SSO while uid i
      in English characters, but could not do SSO while uid is i
      DBCS Chinese
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       users whose securit
      name contains double   byte character
     
      Problem Description: SSO fails if security name contains    double byte characters
     
      Recommendation:
      Problem Summary: SSO fails for security names containing double byte character
      due to incorrect LTPA Token. The first problem is that doubl
      byte character was treated as single byte character durin
      encryption and decryption. The second problem is digita
      signature is incorrectly calculated by assuming all character
      are single bytes. So user data and digital signature ar
      incorrectly mapped
      Problem Conclusion: Use UTF8 rule while converting user data to byte array, an
      also using UTF8 to reverse byte array to string
      Test Comments:
      Circumvention:
      Temporary Fix: send testing eFi
      Comments:






 APAR: PQ66190 Version: 400
      Abstract:
      PROPFILEPASSWORDENCODER COMMAND CAUSES PROPERTY FILES&apos; OWNERSHI
      AND PERMISSIONS TO CHANGE TO THAT OF THE USER RUNNING THE SCRIP
      Error Description:
      Environment
      WebSphere Application Server 4.0.3 AE for Solari
      
      Description
      Running the PropFilePasswordEncoder.sh command causes th
      user/group ownership and permissions to change to the defaul
      settings for the user running the script
      Local Fix:
      Change ownership and permissions back after running the command
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users of   PropFilePasswordEnc
      der scrip
      Problem Description: PropFilePasswordEncoder command causes property files&apos; ownershi
      to chang
      Recommendation:
      Problem Summary: After running PropFilePasswordEncoder script, the user an
      group ownership and the file permissions of those file
      changed to the default settings for the user running th
      PropFilePasswordEncoder script
      Problem Conclusion: The way of how backup files are generated is modified, s
      the original property files can keep their original fil
      permissions
      Test Comments:
      Circumvention:
      Temporary Fix: Availabl
      Comments:






 APAR: PQ66857 Version: 400
      Abstract:
      GETSSOCOOKIEVALUE WHICH WAS (IN WAS 4.0.3 AND 4.0.2) LOCATED I
      CLASS SSOAUTHENTICATOR, WAS REMOVED. CUSTOMERS WANT IT BACK
      Error Description:
      Customer was asking the method getSSOCookieValue which wa
      (in WAS 4.0.3 and  prior releases) located in clas
      SSOAuthenticator, has "vanished" from WAS 4.0.4. I checked th
      class shipped with WAS 4.0.4 and there is no getSSOCookieValu
      method.  Did find external documentation for this API. Customer
      are using it, please add it back in
      Local Fix:
      none
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users      who have a servlet 
      hich invokes            SSOAuthenticator.getSSOCookieValue(
     
      Problem Description: SSOAuthenticator.getSSOCookieValue()   was removed
     
      Recommendation:
      Problem Summary: SSOAuthenticator.getSSOCookieValue() was removed.  This wa
      legacy 3.0.2 code which should not have been in use.  Thi
      method was never really intended for customer use.  However
      it is documented externally and was still functional until i
      was removed.  It was removed due to performance issues tha
      initialization related to it causes
      Problem Conclusion: SSOAuthenticator.getSSOCookieValue() was re-added an
      initialization specific to this method was moved to a code pat
      that only impacts users of this method
      Test Comments:
      Circumvention:
      Temporary Fix: Testfix is available
      Comments:






 APAR: PQ66923 Version: 400
      Abstract:
      USING ONE COMMON PROXY ID FOR ALL SESSIONS CAUSES SESSIO
      TIMEOUT FOR ALL SESSIONS WHEN ONE SESSION LTPATOKEN TIMESOUT
      Error Description:
      Customer&apos;s concern are as follows:ls :D: 1597969914 ,.java:1155
      .SAS0130E: Client credentials were not valid.  Restart thee 
      Session timeout for one session throws away the LTPAToken and5)
      customer is not able to determine which session got timedout.Fi
      Hence does not know which session to re-authenticate.e cliented
      and/or server to ensure that you are using new credentials. esp
      Once credentials are marked invalid, they cannot become valided
      again.02 10:02:24:131 EDT  1736f98c SystemOut     U    1>n
      .2002-09-23 10:02:24.109 ,  ServerID: 289231329 ,14 ,tendedServ
      Local Fix:
      Changed LTPAToken Timeout to 24 hours so the token expire
      around midnight
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users with     security enabled
     
      Problem Description: Invalid credentials were not properly  removed from the cache
     
      Recommendation: apply the eFix
      Problem Summary: Invalid credentials were not removed from the cache. Symptom
      include server credentials failing to refresh or users no
      being able to aceess protected resources
      Problem Conclusion: Remove all expired security cache
      Test Comments:
      Circumvention:
      Temporary Fix: testing eFix is provided
      Comments:






 APAR: PQ66974 Version: 400
      Abstract:
      GETCALLERPRINCIPAL() SHOULD JUST ALWAYS RETURN "UNAUTHENTICATED
      Error Description:
      Customer sent the following
      We have a distributed log viewer servlet architecture, whic
      means each AppServer must have a Servlet to read log file an
      present it to the end user
      
      So we must know how to invoke this servlet before it i
      serviceable(choosable from a drop down list). In the servle
      init() method, we probe WebSphere servlet engine configuratio
      to obtain HTTP port number for the hosting AppServer. Then th
      user can pick a LogViewer and invoke it based on thi
      information
      
      The available LogViewer Tracking EJB has to be invoked from th
      init() method in this sense, so in the serlvet init() we wil
      perform following execution
      
      tr
      
      /** retrieve the collection of application serve
      adapters, retrieve configuration information from servlet engi
      *
      String adapterName 
      SystemProperties.get("LOGSERVER_ADAPTER")
      LogServerAdapter adapter 
      
      (LogServerAdapter)Class.forName(adapterName).newInstance()
      
      LogServer myLogServer = adapter.getLocalLogServer()
      m_logServerManager 
      CoreManagerFactory.getLogServerManager()
      /** first, see if the log server is already in th
      database *
      Collection logServers 
      m_logServerManager.getLogServers()
      for (Iterator it = logServers.iterator()
      it.hasNext(); 
      
      LogServer logServer = (LogServer)it.next()
      i
      (myLogServer.getHost().equalsIgnoreCase(logServer.getHost()) &
      myLogServer.getPort() =
      logServer.getPort()
      
      m_logServerID = logServer.getID()
      break
      
      
      if (m_logServerID == null
      
      /** did not find my log server in th
      database, create a new record *
      m_logServerID 
      m_logServerManager.createLogServer(myLogServer)
      
      
      catch (Exception e
      
      m_cat.l7dError(CoreEjbBundleKey.DEFAULT, e)
      
      
      And in our LogServerManager EJB, it is plain DB persistenc
      stateless session bean. createLogServer() is just an inser
      statement, while getLogServerManager() is simple selec
      statement. As we have an abstract OR layer, I just provide th
      functionality of these methods here
      
      In our EJB, we have logging system, which will always captur
      user&apos;s caller information at the begining of the method an
      push it down to the underneath logging system. So wheneve
      there is exception and it needs logging, the logging system ca
      always write down the caller infomation transparently.  Loggin
      system is based on Log4j
      
      createLogServer(Object value) 
      // this method internally will keep track caller info, it i
      pushe
      dow
      to the logging system, which is defined in a parent EJB clas
      methodStart("createLogServer", value)
      try 
      // operations
      } catch(Exception e) 
      // whenever we want to log the exception, we retrieve bac
      th
      calle
      info directly from logging syste
      // so the api is ignorant of it is inside EJB or Servle
      logging(e)
      } finally 
      // we will pop up the caller info from the logging syste
      methodFinish()
      
      
      
      This model is applied to every single EJB in our system, and i
      will fail in the methodStart() invokation for request
      initiated from init() of a servlet
      
      private void methodStart(String methodName, Object   params
      
      m_strCurrentMethod = methodName
      m_params = params
      
      if (m_sessionContext != null
      NDC.push(m_sessionContext)
      
      Category cat = getCategory()
      if (cat != null && cat.isDebugEnabled()
      
      StringBuffer buf = new StringBuffer(100)
      buf.append("ENTER: ")
      buf.append(getMethodNameWithParams())
      cat.debug(new String(buf))
      
      
      
      In the NDC.push()
      public   static   void push( javax.ejb.EJBContext theContex
      
      push( theContext.getCallerPrincipal() )
      
      
      NDC class is used for
      The NDC class implements <i>nested diagnostic contexts</i
      as defined by Neil Harrison in the article "Patterns for Loggi
      Diagnostic Messages" part of the book "<i>Pattern Language
      of Program Design 3</i>" edited by Martin et al
      <p>A Nested Diagnostic Context, or NDC in short, is a
      instrument to distinguish interleaved log output from differen
      sources
      
      This problem applies to all EJBs that will track caller an
      being invoked from init() method of servlets
      Local Fix:
      Non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server 4.0 security   users who use progr
      mmatic security
      Problem Description: If the anonymous principal is          propagated or the user i
      entity is     missing, getCallerPrincipal() returns  inconsista
      t results
      Recommendation:
      Problem Summary: getCallerPrincipal() returns different results in differen
      timing if the anonymous principal is propagated or calle
      identity is missing.  EJB 1.2 spec define tha
      getCallerPrincipal() should always return container specifi
      unauthenticated principal
      Problem Conclusion: getCallerPrincipal() should return "UNAUTHENTICATED", th
      WebSphere specific unauthenticated principal, if calle
      identity is missing or the anonymous principal i
      propagated
      Test Comments:
      Circumvention:
      Temporary Fix: send testing eFix to customer
      Comments:






 APAR: PQ67062 Version: 400
      Abstract:
      DO NOT RE-VALIDATE GROUP DN IF DN COMES FROM LDA
      Error Description:
      In Ldap, group memberships for each user are stored an
      retrieved as valid Distinguish Name in Ldap.  After findin
      user&apos;s group memberships, there is no necessary to re-validat
      each group  against Ldap server.  By not re-validating eac
      group, there are tw
      benefits, one ha
      performance improvement in particular i.e if a user belongs t
      too many groups, WAS does not have validate against each group
      The other is not to validate groups to which user belongs bu
      not used by WebSphere security
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       users using LDAP re
      istry
      Problem Description: WebSphere performs unnecessary group   Distinguish Name validat
      on
      Recommendation:
      Problem Summary: WebSphere revalidates group DN returned from LDAP.  In LDAP
      group memberships for each user are strored and retrieved a
      valid Distinguish Names.  After findind a user&apos;s grou
      memberships, it is not necessary to re-validate each grou
      against the LDAP server.  By not re-validating each group
      there are two benefits, one has performance improvement i
      particular if a user belongs to too many groups, the othe
      is not to validate groups to which user belongs but not use
      by WebSphere security
      Problem Conclusion: Group DNs returned from LDAP are now not validated
      Test Comments:
      Circumvention:
      Temporary Fix: provide both working-around, and testing eFix to customer
      Comments:






 APAR: PQ67391 Version: 400
      Abstract:
      SECURITY COMPONENT WON&apos;T TAKE FULL LDAP NAME
      Error Description:
      We have developed an application that requires Group/Rol
      Mappings. Th
      Groups are contained in the LDAP directory and are referenced b
      DN o
      type: "cn=GroupName, o=infoscore,c=de". We can install th
      applicatio
      in the Admin Console GUI and setup the mappings, using th
      User/Rol
      Mappings dialog
      
      In our application 3 Roles are defined, which are mapped to th
      following group
      
      Role                           Users/Group
      
      ISSAdmin                       cn=AdminISSGroup
      o=infoscore,c=d
      VendorAdmin                    cn=AdminGroup,ou=IBD
      o=infoscore,c=d
      cn=AdminGroup,ou=ICD
      o=infoscore,c=d
      ISSAdminBatch                  cn=AdminISSBatchGroup
      o=infoscore,c=d
      
      Once the roles have been setup in the AdminConsole, I can the
      see th
      mappings in the WSCP as follows
      
      wscp> SecurityRoleAssignment getGroupRoleMappin
      /EnterpriseApp:admin
      {ISSAdmin cn=AdminISSGroup, o=infoscore,c=de} {VendorAdmi
      cn=AdminGroup,ou=IBD, o=infoscore,c=de} {VendorAdmi
      cn=AdminGroup,ou=ICD, o=infoscore,c=de} {ISSAdminBatc
      cn=AdminISSBatchGroup, o=infoscore,c=de
      
      However, when we try to set up the mappings using WSCP, it doe
      no
      work. Here is an example of how we attempt to set up one of th
      mapping
      in WSCP
      
      wscp> SecurityRoleAssignment addGroupRoleMappin
      /EnterpriseApp:admin
      -grouproles {ISSAdmin cn=AdminISSGroup, o=infoscore,c=de
      WSCP0038E: Invalid attribute format : ISSAdmin cn=AdminISSGroup
      o=infoscore,c=d
      
      The installation procedure for our production system require
      that w
      use the WSCP, so that this task can be scripted.  Therefore, i
      i
      essential that we are able to setup our User/Role mappings i
      WSCP
      
      This was the problem as described by customer
      
      I then suggested customer to issue the command as follows
      
      wscp> SecurityRoleAssignment  addGroupRoleMappin
      /EnterpriseApp:admin
      -grouproles {ISSAdmin {cn=AdminISSGroup, o=infoscore,c=de}
      
      and install apar PQ60772, since the apar description seemed t
      matc
      the issue
      
      It was after installing this apar that customer got a differen
      error
      
      From customer
      
      Installing PQ60772 hasn&apos;t solved the problem. I am now getting 
      different error
      
      wscp> SecurityRoleAssignment  addGroupRoleMappin
      /EnterpriseApp:admin
      -grouproles {ISSAdmin {cn=AdminISSGroup, o=infoscore,c=de}
      java.lang.NullPointerExceptio
      a
      com.ibm.xmi.xmi2.impl.XMI2WriterImpl.writeFeatures(XMI2WriterIm
      l.java:
      07
      
      With regards to the use of short names, customer must use ful
      names
      
      From customer
      
      Unfortunately for us, we must use the full DN. Standard LDA
      configuration does not include a short name for groups. I
      particular
      in one of the examples I showed you, the use of short name
      would no
      solve the problem. In order to distinguish both of the group
      (AdminGroup) in this example we must use the full DN
      
      {VendorAdmin cn=AdminGroup,ou=IBD, o=infoscore,c=de
      {VendorAdmin cn=AdminGroup,ou=ICD, o=infoscore,c=de
      Local Fix:
      Use shortname, but which is unacceptable for this customer
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       users who use WSCP 
      o assign group DN to    role
     
      Problem Description: WSCP fails to assign group DNs to a    security role
     
      Recommendation:
      Problem Summary: WSCP cannot assign groups to security roles if the give
      group name is DN(distinguished name) instead of singl
      attribute value
      Problem Conclusion: Modify Ldap registry implementation in security to accept bot
      DN and short name as groups search pattern. Originally
      only short name was acceptable search pattern
      Test Comments:
      Circumvention: use short name
      Temporary Fix: provide testing eFix. Waiting for feedback
      Comments:






 APAR: PQ67473 Version: 400
      Abstract:
      % SIGN IN THE USER CREDENTIALS IS CORRUPTED WHEN PASSE
      THROUGHTHE GETUSERPRINCIPAL CLAS
      Error Description:
      custom tion Description Form based security usin
      er uses is a \242 (cent sign).  When passed to getUserPrincipal
      .ustomer programmatically checks security wit
      user name goes in as user<delim>company, and comes back from th
      .etUserPrincipal API.  For business reasons, customer uses 
      method as user<extra character><delim>company. This worked unde
      .egistry to store usernames as <username><delim><company
      weblogic :) and they want it to work the same under websphere
      Problem Summary The security check passes OK, but the delim th
      Local Fix:
      Non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users with     security enabled
     
      Problem Description: Unicode character in the principal namegets changed after logi
      with          SSOAuthenticator
     
     
      Recommendation:
      Problem Summary: When using unicode characters in the principal name, th
      principal name gets changed with an extra character in fron
      of the unicode character when getUserPrincipal().getName(
      is called after login
      Problem Conclusion: Inconsistent encoding was used when we convert bytecode t
      string and back.  UTF8 should be used
      Test Comments:
      Circumvention:
      Temporary Fix: availabl
      Comments:






 APAR: PQ67679 Version: 400
      Abstract:
      WASSEC - ADDS TAI CAPABILITY TO PQ6302
      Error Description:
      Customer installed Websphere PTF4 to WAS 4.03.  Found out tha
      function fixed by previous efix PQ63020 was unavailable.  Th
      cause of the failure appears to be TAI
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security       users who use progr
      mmatic security with    Trust Association and Custom Registry
     
      Problem Description: Wehn using a custom registry with      trust association, the A
      I             getRemoteUser() returns display name   rather tha
      security name
      Recommendation: Apply this eFix, or use the display name    as the same as the 
      ecurity name
      Problem Summary: When using a Custom Registry implementation, security return
      the user&apos;s display name for getRemoteUser() an
      getPrincipalName() instead of the user&apos;s security name
      Problem Conclusion: If getRemoteUser() and getPrincipalName() are required t
      return the user&apos;s security name, a system property has bee
      added to enable this
      com.ibm.ejs.security.customregistry.useSecurityName=tru
      Test Comments:
      Circumvention: make display name the same as security nam
      Temporary Fix: testing eFix provide
      Comments:






 APAR: PQ67926 Version: 400
      Abstract:
      CANNOT START THE ADMIN SERVER WITH A USER ASSIGNED TO ADMIN ROL
      Error Description:
      Problem Reported
      Cannot start the admin server with a user assigned to Admi
      Role
      
      performed the following steps
      
      1.uninstalled WA
      2.dropped and recreated the admin databas
      3.deleted /usr/WebSphere/AppServe
      4.installed WAS 4.
      5.installed PTF 
      6.started WA
      7.configured Security to use IBM bluepages as LDAP serve
      
      8.stopped WA
      9.started WA
      10.Added user cdsharp@us.ibm.com to admin rol
      11.stopped WA
      12.installed PTF 
      13.started WA
      14.Admin. Server failed to start. Generated secuirty relate
      errors i
      tracefile
      15.edited sas.server.props file. Se
      com.ibm.CORBA.securityEnabled=fals
      16.connected to the admin repository database and se
      securityenabled =
      17.(db2 "update ejsadmin.securitycfg_table set securityenable
      =0"
      restarted WA
      18.Admin. Server starte
      19.connected to server with admin client and used the securit
      center t
      remove the cdsharp entry from the admin role
      20.enabled securit
      21.stopped WA
      22.admin. server started with no error
      connected to server with admin. client (received logon prompt
      Local Fix:
      Workaround
      
      Disable security in DB
      Start adminserver and admin consol
      Remove all users from admin rol
      Re-enable securit
      Shut down and restart WA
      Adminserver should come up
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y and have invalid      users listed in the Administrative Role
     
      Problem Description: If an ID which is not valid in the     user registry is referen
      ed in the     Administrative Role, the               Administra
      ion Server will not         initialize
     
      Recommendation:
      Problem Summary: If an ID which is not valid in the user registry is reference
      in the Administrative Role, the Administration Server will no
      initialize.  The problem stems from the user registry returnin
      a null instead of returning a valid access ID.  Errors simila
      to the following will be encountered
     
      11/18/02 15:12:24:621 CST  6097e07e Initializer   X SECJ0007E
      Error during security initialization. Exception null a
      location: java.lang.NullPointerExceptio
      at com.ibm.ejs.models.base.bindings.applicationbnd
      impl.SubjectImpl.equals(SubjectImpl.java:30
      at com.ibm.etools.emf.ref.impl.OwnedListImpl
      indexOf(OwnedListImpl.java(Compiled Code)
      at com.ibm.etools.emf.ref.impl.OwnedListImpl
      duplicate(OwnedListImpl.java(Compiled Code)
      at com.ibm.etools.emf.ref.impl.OwnedListImpl
      duplicate(OwnedListImpl.java(Compiled Code)
      at com.ibm.etools.emf.ref.impl.OwnedListImpl
      add(OwnedListImpl.java:48
      at com.ibm.ejs.models.base.bindings.applicationbnd.gen
      impl.UserGenImpl$User_List.add(UserGenImpl.java:31
      at com.ibm.ejs.security.Initializer
      bindServerIdToAdminApp(Initializer.java:503
      at com.ibm.ejs.security.Initializer
      initialize(Initializer.java:220
      at com.ibm.ejs.security.Initializer
      serverStarted(Initializer.java:136
      at com.ibm.ws.runtime.Server
      fireServerStarted(Server.java:2018
      at com.ibm.ws.runtime.Server
      fireServerStarted(Server.java:2011
      at com.ibm.ejs.sm.server.AdminServer
      initializeRuntime0(AdminServer.java:1144
      at com.ibm.ws.runtime.Server
      initializeRuntime(Server.java:884
      at com.ibm.ejs.sm.server.AdminServer
      main(AdminServer.java:392
      at java.lang.reflect.Method.invoke(Native Method
      at com.ibm.ws.bootstrap.WSLauncher
      main(WSLauncher.java:158
      
      11/18/02 15:12:24:711 CST  6097e07e Initializer   X SECJ0007E
      Error during security initialization. Exception null a
      location: java.lang.NullPointerExceptio
      at com.ibm.ejs.models.base.bindings.applicationbnd
      impl.SubjectImpl.equals(SubjectImpl.java:30
      at com.ibm.etools.emf.ref.impl.OwnedListImpl
      indexOf(OwnedListImpl.java(Compiled Code)
      at com.ibm.etools.emf.ref.impl.OwnedListImpl
      duplicate(OwnedListImpl.java(Compiled Code)
      at com.ibm.etools.emf.ref.impl.OwnedListImpl
      duplicate(OwnedListImpl.java(Compiled Code)
      at com.ibm.etools.emf.ref.impl.OwnedListImpl
      add(OwnedListImpl.java:48
      at com.ibm.ejs.models.base.bindings.applicationbnd.gen
      impl.UserGenImpl$User_List.add(UserGenImpl.java:31
      at com.ibm.ejs.security.Initializer
      bindServerIdToAdminApp(Initializer.java:503
      at com.ibm.ejs.security.Initializer
      initialize(Initializer.java:220
      at com.ibm.ejs.security.Initializer
      serverStarted(Initializer.java:136
      at com.ibm.ws.runtime.Server
      fireServerStarted(Server.java:2018
      at com.ibm.ws.runtime.Server
      fireServerStarted(Server.java:2011
      at com.ibm.ejs.sm.server.AdminServer
      initializeRuntime0(AdminServer.java:1144
      at com.ibm.ws.runtime.Server
      initializeRuntime(Server.java:884
      at com.ibm.ejs.sm.server.AdminServer
      main(AdminServer.java:392
      at java.lang.reflect.Method.invoke(Native Method
      at com.ibm.ws.bootstrap.WSLauncher
      main(WSLauncher.java:158
      
      11/18/02 15:12:24:751 CST  6097e07e AdminServer   X WSVR0009E
      Error occurred during startu
      java.lang.RuntimeExceptio
      at com.ibm.ejs.security.Initializer
      serverStarted(Initializer.java:142
      at com.ibm.ws.runtime.Server
      fireServerStarted(Server.java:2018
      at com.ibm.ws.runtime.Server
      fireServerStarted(Server.java:2011
      at com.ibm.ejs.sm.server.AdminServer
      initializeRuntime0(AdminServer.java:1144
      at com.ibm.ws.runtime.Server
      initializeRuntime(Server.java:884
      at com.ibm.ejs.sm.server.AdminServer
      main(AdminServer.java:392
      at java.lang.reflect.Method.invoke(Native Method
      at com.ibm.ws.bootstrap.WSLauncher
      main(WSLauncher.java:158
     
      Problem Conclusion: Null access IDs are now checked and ignored
      Test Comments:
      Circumvention: Temporarily disable security, remove invalid IDs from th
      Administrative Role then restart then restart.  Re-enabl
      security then restart again
      Temporary Fix: provided testing eFix to customer
      Comments:






 APAR: PQ68882 Version: 400
      Abstract:
      CANNOT HAVE , AND () IN ADMIN CONSOLE USER NAM
      Error Description:
      The customer cannot use user names that contain the comm
      character  ,  and parentheses  ()  in the DN as admin consol
      users.  The trace file contains the error message &apos;Invalid LDA
      user&apos;
      Local Fix:
      There is no workaround for users whose DN contains a comma an
      parentheses characters
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security users who has used a comm
      (, ASII 44) or open    parenthese (ASII 40) or close parenthes
      (ASII 41) in a user&apos;s security name
      Problem Description: If a user name or attributes in a DN   (if LDAP is the user reg
      stry) contain comma or open parenthese or close      parenthese
      authorization for the DN   may fail
     
      Recommendation:
      Problem Summary: If user name or attribute in DN (if using LDAP registry
      contain comma or open parenthese or close parenthese, use
      name was improperly truncated as security use thos
      characters as delimiter, which result
      authorization error
     
      If a Custom Registry is in use, this also applies to name
      returned by the following methods
      List getUsers(
      List getUsers(String pattern
      String getUserDisplayName(String userName
      String getUniqueUserId(String userName
      List getUniqueUserIds(String uniqueGroupId
      String getUserSecurityName(String uniqueUserId
      Problem Conclusion: Comma&apos;s and parenthesis were used internally as delimeters
      The use of parenthesis as delimiters has been removed
      Commas are now treated properly by escaping them
     
      A fix for this APAR will be contained in any securit
      cumulative eFix dated after the closure date of this APAR
      Test Comments:
      Circumvention:
      Temporary Fix: A test fix was provided
      Comments:






 APAR: PQ68922 Version: 400
      Abstract:
      WAS IS HAVING PROBLEMS AUTHENTICATING WITH IDA
      Error Description:
      Environment
      WebSphere Application Server (WAS) 4.0.1 through 4.0.4 (an
      possibly 4.0.5
      iPlanet LDAP server with iDA
      
      Description
      iDAR has a defect which causes WAS to fail authenticatin
      using the JNDI interface
      Local Fix:
      Non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users who have enabled security an
      are using LDAP as the  user registry
     
      Problem Description: Intermittant errors encountered in     user authentication
     
      Recommendation:
      Problem Summary: Intermittant errors encountered in user authentication.  Th
      errors were caused by an LDAP search periodicall
      returning the error "could not decode search request"
      One possible cause for this specific error is the searc
      request returning attributes which do not conform with LDA
      standard defined in RFC 2251
      Problem Conclusion: The specifc search Wesphre was performaing did not require an
      attributes to be returned.  WebSphere was using an empt
      string per the JNDI specifications to request no attribute
      be returned.  The LDAP specifications require the string b
      set to "1.1" if attributes should not be returned.  The Su
      JNDI LDAP service provider does not properly handle thi
      scenario.  WebSphere code was changed to conform with the LDA
      specifications instead of the JNDI specifications since LDA
      service provider does not handle this scenario properly
     
      A fix for this APAR will be contained in any securit
      cumulative eFix dated after the closure date of this APAR
      Test Comments:
      Circumvention:
      Temporary Fix: provide testing fi
      Comments:






 APAR: PQ71416 Version: 400
      Abstract:
      workaround for search() metho
      Error Description:
      Fixing the search() method due to what jndi method is returning
      Local Fix:
      search(
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server securit
      users who have Distinguished Names (DNs
      containing the character &apos;#&apos; on thei
      LDAP server
      Problem Description: If a DN contains the special characte
      #, the user may not be authenticated o
      authorized properly
      Recommendation:
      Problem Summary:
      If a LDAP entry DN contains the special character &apos;#&apos;, a JND
      search does not return relative name, it returns LDAP URL
      WebSphere still treats the return value as relative name. Also
      if an attribute value in DN starts with &apos;#&apos;, the &apos;#&apos; should b
      escaped
      Problem Conclusion: WebSphere will now parse LDAP SearchResult accordingly, eithe
      as a relative name or  aLDAP URL, and generate a correct D
      for the entry.  WebSphere also will escape &apos;#&apos; characters i
      the &apos;#&apos; occurs at the beginging of a String attribute value
      Test Comments:
      Circumvention: Do not start string attribute value in DN with #
      Temporary Fix: provide test fix
      Comments:




 APAR: PQ72357 Version: 400
      Abstract:
      403 FORBIDDEN ERRORS 20% OF THE TIM
      Error Description:
      
      When accessing the /wps/portal page, 403 (forbidden) errors ar
      sometimes returned.  In a 62 hour test run, the 403 erro
      occurred aproximately 20% of the time
     
      Users Affected: WebSphere Application Server users who hav
      enabled security and have secured at leas
      one URI
      Problem Description: Authorization fails without bein
      challenged
      Recommendation:
      Problem Summary:
      When multiple concurrent requests are received by the We
      container for protected URIs, authorization failures ma
      occur without any challenge
      Problem Conclusion: A timing issue existed with the use of an instance variable
      The variable was changed to a method variable which insure
      that two simultaneous threads do not update the variabl
      concurrently
      

 APAR: PQ56218 Version: 400
      Abstract:
      PMI DOES NOT RECOVER WHEN WEBSPHERE APP SERVER IS RESTARTED WHE
      SECURITY ENABLE
      Error Description:
      ** Brief Description: Customer has a java PMI clien
      (Performance Monitoring Infrastructure)programmin
      interface provided by IBM. -- It logs int
      WAS fine the first time but when you stop and restart WA
      with security on it does not log back in.  Getting erro
      Cannot create PmiService bean obj; nested exception is
      java.rmi.RemoteException: CORBA INTERNAL 0 N
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users whichhave enabled securi
      y
      Problem Description: Java clients fail to log into WebSphereApplication Server afte
      the server    is restarted with security enabled
      Recommendation:
      Problem Summary: After the Java client logged into the WebSphere Applicatio
      Server, if the server restarts for any reason, then the Jav
      Client cannot login again with security enabled.  The clien
      will get the java.rmi.RemoteException:  CORBA INTERNAL 
      Problem Conclusion: When the client receives a request reject message, the clien
      now checks the credential associated with the request.  If th
      credential is a dummy credential, then the client trie
      to re-establish the secure association with the server again
      Test Comments:
      Circumvention:
      Temporary Fix: PQ56218_eFix_AEServer.ja
      Comments:






 APAR: PQ58764 Version: 400
      Abstract:
      CORBA EXCEPTION ERRO
      Error Description:
      The customer stated when java client his the applicatio
      server he is getting the following error into th
      client stdout file: CORBA exception errors... faile
      mutual authentication handshake... session does not exis
      in the session table. He also noticed jsa150e-unable t
      find session in the session table errors.                    De
      ect 12042
      Local Fix:
      No fix or workaround available yet
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users whichhave enabled securi
      y
      Problem Description: CORBA exception errors with failed     mutual authentication me
      sag
      Recommendation:
      Problem Summary: Client gets CORBA exception errors, failed mutua
      authentication handshake after 45 minutes of attempting t
      complete the request.  The following CORBA exception occurs
      "org.omg.CORBA.NO_PERMISSION:  Failed mutual authenticatio
      handshake.  Session does not exist in the session table.
      Problem Conclusion: The server now passes back the security context alon
      with the exception, so the client can react accordingly
      Test Comments:
      Circumvention:
      Temporary Fix: PQ58764_401_test.ja
      Comments:






 APAR: PQ57182 Version: 350
      Abstract:
      UNABLE TO VALIDATE CREDENTIALS FROM LTPA TOKEN
      Error Description:
      Worker#49       curityLevel2.LoginFailed caught. LoginFailed.0
      class org.omg.SecurityLevel2.LoginFailed exception was caught
      .essage: nul
      org.omg.SecurityLevel2.LoginFaile
      
      .3:39:43.312 com.tivoli.tsm.authentication.LoginHelpe
      13:39:43.427 com.tivoli.tsm.authentication.DefaultAuthenticato
      .ogin(login(byte   ltpaCookie) Worker#4
      LTPASingleSignOn(HttpServletRequest, HttpServletResponse).12.0
      Local Fix:
      Need a efix for WAS 3.5.4. This has been fixed in 4.0.X cod
      base
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users of   security
     
      Problem Description: Unable to validate credential token    for LTP
     
      Recommendation:
      Problem Summary: Ltpa credential token fails authentication when SSO i
      configured.  Invalid credential exception message woul
      appear
      Problem Conclusion: This problem is solved by improving the synchronization o
      the authentication process
      Test Comments:
      Circumvention:
      Temporary Fix: PQ57182_354_test.ja
      Comments:






 APAR: PQ59447 Version: 400
 APAR: PQ59150 Version: 350
      Abstract:
      USERS & GROUPS WHOSE NAME/STRING IS MORE THAN 127 BYTES LON
      WILL GET "JAVA.LANG.NEGATIVEARRAYSIZEEXCEPTION" EXCEPTION
      Error Description:
      Users who belong to more than 127 groups or belong to a grou
      whose name is greater then 127 bytes long will fai
      authorization.  A "NegativeArraySizeException" message will b
      evident in traces and possibly be visable on a web client
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users      using security and 
      dding users to groups   with names greater than 127 bytes long 
      r   adding users to more than 127 groups.       All WebSphere A
      plication Server users      using security and adding users to 
      roups   with names greater than 127 bytes long or   adding user
      to more than 127 groups
      Problem Description: Users encounter an authentication      failure for Java client
      or an Error   500 for web clients
      Recommendation:
      Problem Summary: Users encounter an authentication failure for Java clients o
      an Error 500 for web clients.  The problem is 
      NegativeArraySizeException occurs in SecurityAttributeLis
      due to the conversion of byte values into integers befor
      bitwsie operations were performed.  Negative byte value
      were sign extended yeilding a negative value for the fina
      integer after bitwise operations completed
      Problem Conclusion: Sign extended bits were masked off before the bitwise operatio
      was performed
      Test Comments:
      Circumvention: Limit users to 127 groups and to groups with less then 12
      bytes in their name
      Temporary Fix: PQ59150-3.5.5-3.5.6.ja
      Comments:






 APAR: PQ62632 Version: 350
      Abstract:
      WHEN A HIGH NUMBER OF APPLICATION SERVERS ARE RUNNING (15 O
      HIGHER) AND WAS SECURITY ENABLED, THE SECBOOTSTRAP IS CORRUPTE
      Error Description:
      Environment
      WebSphere Application Server 3.5.5 AE for AI
      
      Description
      When WAS security is enabled and a high number of app server
      are running (16 or more), the secbootstrap file gets corrupte
      after stopping an application server resulting in the followin
      message in the tracefile
      
      I/O Error while processing the security bootstrap repository
      
      This problem is less intermittent the more application server
      are running. In one case, running 35 application servers cause
      this problem to occur readily when stopping an app server
      Local Fix:
      None
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users with     security enabled
     
      Problem Description: secbootstrap file gets corrupted while stopping application ser
      er
      Recommendation:
      Problem Summary: secbootstrap file gets corrupted while stopping applicatio
      servers if too many application servers are deployed in 
      single node. (35 application servers were configured o
      the reported system). The problem was caused i
      deregistering ports from secbootstrap
      Problem Conclusion: The deregister to secootstrap seems not work properly
      Test Comments:
      Circumvention:
      Temporary Fix: testing eFix has been send to custome
      Comments: send a testing eFix to customer






 APAR: PQ63062 Version: 400
      Abstract:
      RESTART OF WCS IN WAS 4.0.3 CAUSES "ILLEGAL USE OF 1P
      RESOURCE IN TRANSACTION" WHEN SECURITY IS ENABLE
      Error Description:
      Environment
      WebSphere Application Server 4.0.3 A
      WebSphere Commerce Suit
      
      Description
      In WAS 4.0.3 AE with security enabled, restarting the WC
      app server causes the following message to appear in admi
      console
      
      6/18/02 17:18:35:857 EDT  6d938229 ConnectO      W Illegal us
      of 1PC resource in transactio
      javax.transaction.TransactionRolledbackException: CORB
      TRANSACTION_ROLLEDBACK 0 No; nested exception is
      org.omg.CORBA.TRANSACTION_ROLLEDBACK
      com.ibm.websphere.csi.CSITransactionRolledbackException
      at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:194
      at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:67
      
      This problem does not occur in WAS 4.0.2 AE, and it doen&apos;
      occur when WAS 4.0.3 security is disabled
      Local Fix:
      None
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y
      Problem Description: "Illegal use of 1PC resource in        transaction" errors rece
      ved during    WebSphere Commerce Suite               initializa
      ion
      Recommendation:
      Problem Summary: "Illegal use of 1PC resource in transaction" errors receive
      during WebSphere Commerce Suite initialization.  This issu
      may be seen on initialization or during runtime of an
      application server if EJBs which use data sources have bee
      deployed
     
      The problem was caused by new EJB calls which were made
      necessarily, in a non-standard manner which implicitl
      involved the calls in any existing transactions
      Problem Conclusion: The problem was resolved by explicitly suspending and resumin
      any existing transaction
      Test Comments:
      Circumvention: Use a Two Phase Commit driver for the data source
      Temporary Fix: A test fix was supplied
      Comments:






 APAR: PQ63116 Version: 400
      Abstract:
      PROBLEM:  WHEN THE ADMINISTRATION SERVER IS STOPPED AN
      RESTARTED, VARIOUS CLIENTS GET AUTHENTICATION ERRORS
      Error Description:
      Problem:  When the administration server is stopped an
      restarted, WebSphere SeriousEvent, PMI, and WSCP clients ge
      Authentication errors
      
      Information specific to WAS 4.0.2: This was working fine wit
      eFix PQ56218.  When later cumulative eFix PQ62538 was applied
      this is broken
      Local Fix:
      none
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users wit
      security enable
      Problem Description: When the administration server i
      stopped and restarted, WebSpher
      clients get authentication errors
      Recommendation:
      Problem Summary:
      In the scenario where clients make a persistent connection wit
      the server, clients get Authentication errors when th
      administration server is restarted without restarting th
      clients
     
      Following exception will occur
     
      Exception stack trace: javax.naming.NoPermissionException
      NO_PERMISSION exception caught
      Root exception is org.omg.CORBA.NO_PERMISSION
      com.ibm.CORBA.iiop.ExceptionInterceptorsCalle
      minor code: 0 completed: Mayb
      Problem Conclusion: Both the client and the server exception handling mechanism i
      improved to handle the broken connections between the clien
      and the server
      Test Comments:
      Circumvention:
      Temporary Fix: PQ63116_eFix.ja
      Comments:






 APAR: PQ65687 Version: 400
      Abstract:
      SECURITY EXCEPTIONS AFTER SERVER REBOOT
      Error Description:
      We are currently having intermittent problems with the IBM WA
      Admi
      service not starting, especially after server reboots.     Thi
      generates the following  entry in sas_server.log
      
      1>  2002-07-24 14:23:16.772 ,  ServerID: 12221999 
      SecurityTaggedComponentAssistorImpl.register , Thread Hash
      67337841
      Thread P=596272:O=0:CT,5,main 
      
      JSAS0026E: Exception connecting object to the ORB.  Chec
      th
      sas.server.props file to ensure that the SSL keyStore an
      trustStor
      properties are set properly.  If the problem persists, contac
      suppor
      for assistance
      
      We did apply the following  fix found from the IBM Webspher
      suppor
      site but the problem still recurs.  Solutio
      
      Put the following parameters in separate lines in the <WA
      root>/bin/admin.config and set them to unique unused ports o
      th
      machine and restart WAS
      
      com.ibm.CORBA.SSLPort=<unique port #
      com.ibm.CORBA.LSDSSLPort=<uniquie port #
      
      Problem occurs on WAS AE 4.03 and 4.04
      Local Fix:
      no workaround availabl
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Users that have enabled       security and restar
      their adminstration    server while their application servers 
      re  up and running
      Problem Description: If application server is up and        running while the admins
      ration server is restarted, then application server  continues 
      o uses a stale IOR without  loading the newly created one
     
      Recommendation:
      Problem Summary: If the WebSphere Application Servers are up and running whil
      the Admin Server is rebooted; then the Application server
      continue to use the stale IOR for the Adminstration Serve
      instead of getting the new IOR for the Adminstration Server
      With the stale IOR, the Application Servers ge
      OBJECT_NOT_EXIST exceptions
      Problem Conclusion: To resolve this problem, the bootstrap repository is read t
      load the new IORs for the server that was restarted. The logi
      is to read the bootstrap repository to get the IORs up t
      three times and ping the server with the new IOR. After thre
      times, if the server does not respond to the new IOR, the
      OBJECT_NOT_EXIST exception is thrown
      Test Comments:
      Circumvention:
      Temporary Fix:
      Comments:






 APAR: PQ66004 Version: 400
      Abstract:
      MULTIPLE SECURITY LOG ENTRIES FOR ONE INVALID USERID/PASSWORD
      Error Description:
      Upon entering a wrong password for a given userid, the followin
      log statements are written to appserver-out.log. Apart from th
      fact, that times the same message seems unnecessary, it shoul
      the application&apos;s decision whether to write or not to write suc
      message regarding invalid logins. Otherwise, a very simpl
      denial of service attack could logins. Otherwise, a very simpl
      denial of service attack could be convinced with bogus logi
      attempts keeping the machine busy logging these messages
      8/26/02 13:17:39:080 CEST  37b2205d SystemOut     U    5
      2002-08-2
      13:17:39.08 ,  ServerID: 375334458 
      LoginHelperImpl.request_login_controlled 
      8/26/02 13:17:39:090 CEST  37b2205d SystemOut     
      JSAS0240E
      Login failed.  Verify the userid/password is correct.  Check th
      properties file to ensure the login source is valid.  If thi
      erro
      occurs on the server, check the server properties to ensure th
      principalName has a valid realm and userid
      8/26/02 13:17:39:110 CEST  37b2205d SystemOut     U    6
      2002-08-2
      13:17:39.11 ,  ServerID: 375334458 
      CredentialsImpl.get_mapped_credentials 
      8/26/02 13:17:39:120 CEST  37b2205d SystemOut     
      JSAS0240E
      Login failed.  Verify the userid/password is correct.  Check th
      properties file to ensure the login source is valid.  If thi
      erro
      occurs on the server, check the server properties to ensure th
      principalName has a valid realm and userid
      8/26/02 13:17:39:451 CEST  37b2205d SystemOut     U    8
      2002-08-2
      13:17:39.451 ,  ServerID: 375334458 
      CredentialsImpl.get_mapped_credentials 
      8/26/02 13:17:39:481 CEST  37b2205d SystemOut     
      JSAS0240E
      Login failed.  Verify the userid/password is correct.  Check th
      properties file to ensure the login source is valid.  If thi
      erro
      occurs on the server, check the server properties to ensure th
      principalName has a valid realm and userid
      Action Planned: Sending to entitlement, then to WAS for custome
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users who have security enabled
     
      Problem Description: Multiple security log entries for one  invalid login
     
      Recommendation:
      Problem Summary: Upon entering a wrong password for a given userid, th
      following  3 log statements are written to appserver-out.log
      It&apos;s unnecessary to have 3 login error messages
     
      8/26/02 13:17:39:080 CEST  37b2205d SystemOut     U    5
      2002-08-26 13:17:39.08 ,  ServerID: 375334458 
     
      LoginHelperImpl.request_login_controlled 
     
      8/26/02 13:17:39:090 CEST  37b2205d SystemOut     
      JSAS0240E:   Login failed.  Verify the userid/password i
      correct
      Check the properties file to ensure the login source is valid
      If this error occurs on the server, check the server propertie
      to ensure the principalName has a valid realm and userid
     
      8/26/02 13:17:39:110 CEST  37b2205d SystemOut     U    6
      2002-08-26 13:17:39.11 ,  ServerID: 375334458 
     
     
      CredentialsImpl.get_mapped_credentials 
     
      8/26/02 13:17:39:120 CEST  37b2205d SystemOut     
      JSAS0240E
      Login failed.  Verify the userid/password is correct.  Chec
      the properties file to ensure the login source is valid
      If this error occurs on the server, check the server propertie
      to ensure the principalName has a valid realm and userid
     
      8/26/02 13:17:39:451 CEST  37b2205d SystemOut     U    8
      2002-08-26 13:17:39.451 ,  ServerID: 375334458 
     
      CredentialsImpl.get_mapped_credentials 
     
      8/26/02 13:17:39:481 CEST  37b2205d SystemOut     
      JSAS0240E:   Login failed.  Verify the userid/password i
      correct
      Check the properties file to ensure the login source is valid
      If this error occurs on the server, check the server propertie
      to ensure the principalName has a valid realm and userid
      Problem Conclusion: 2 unnecessary messages are removed.  Only one message will b
      logged
      Test Comments:
      Circumvention:
      Temporary Fix: PQ66004_eFix_test.ja
      Comments:






 APAR: PQ66449 Version: 400
      Abstract:
      AUTH PRINCIPAL NULLS OUT AND CAUSES AUTHORIZATION FAILURE
      Error Description:
      Note from Tom D. at the WC
      
      Trace and this note on wasdoc0
      
      - error occurs on thread 5f824
      - prior authentication checks on this thread have succeede
      - the failure occurs at 13:06:5
      - sequence of events
      - EJSSecurityCollaborator.preInvok
      - received and invoke creds are both non-nul
      - SetUnauthenticatedCredIfNeeded returns false, meaning tha
      the creds ar
      authorize
      - SecurityCollaborator.performAuthorization is calle
      - since invokedCred is non-null, curReceived will be set t
      the value o
      invokedCre
      - ejbCheckAuthorization is called with curReceive
      - WSCheckAccessManager.checkAccess is called.  One of the arg
      is a ne
      WSPrincipal, which is constructed with the receivedCred
      - in checkAccess, creds is initialized to null.  If th
      principal i
      non-null, then getCredentials will be called on th
      principal object
      - isGrantedAnyRole is called with the creds object.  If th
      creds object i
      null, or creds.isUnauthenticated is true, then the erro
      occurs.  Sinc
      there is one error message for two possible conditions, w
      do not kno
      which one triggered the error.  creds can be null if:  1
      the principa
      passed to checkAccess is null.  Then creds will not be set
      2) the cal
      to getCredentials on the principal passed in returns null
      - not sure where the code is for isUnauthenticated, so I d
      not know wha
      conditions would cause this call to return true
      * but, upon return to checkAccess from isGrantedAnyRole, 
      message i
      printed with the value of principal.toString(), which i
      UNATHENTICATED
      So if the principal is UNAUTHENTICATED, then the call t
      getCredential
      will probably produce null
      
      QUESTIONS
      - why does the same thread seem to be able to create ejbs an
      have th
      authentication checks succeed, and then later fail on 
      subsequent creat
      check
      - from looking at two different traces, it does not appear as i
      the failur
      only occurs on one ejb.  So that could rule out 
      config/deployment issue
      - does an UNAUTHENTICATED invokeCreds object somehow ge
      associated with th
      call?  invokedCred is set by a call t
      current.get_credentials()
      
      At this point, I&apos;m thinking that the call t
      current.get_credentials() in performAuthorization is perhap
      not returning the proper credentials, and this leads to th
      client appearing as unauthenticated.  But I still do not hav
      enough evidence to back this up
      Local Fix:
      No workaround available
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users with     security enabled an
      LocalOS as user        registry
     
      Problem Description: The authentication principal is lost   which causes authorizati
      n failure
      Recommendation:
      Problem Summary: Authentication principal becomes unauthenticated when a vali
      uid/password is used
     
      Actual Exception
      ================
      securityName: /UNAUTHENTICATED;accessID: UNAUTHENTICATED is no
      granted any of the required roles: XXXX
      9/24/02 9:23:37:698 EDT    261218 SecurityColla 
      Authorization failed accessing EJ
      com.ibm.ws.security.core.AccessException
      securityName: /UNAUTHENTICATED;accessID: UNAUTHENTICATED is no
      granted any of the required roles
      Problem Conclusion: LocalOS credentials were not mapped correctly to the OS use
      registry when a web request qas received.  LocalO
      credentials are now correctly mapped
      Test Comments:
      Circumvention:
      Temporary Fix: availabl
      Comments:






 APAR: PQ67119 Version: 350
      Abstract:
      WEBPSHERE 356 APPSERVER WILL NOT START WHEN SECURITY I
      ENABLED ON AN ADMIN AGENT SERVER
      Error Description:
      Upgraded Two Websphere 3.5.4 nodes to Websphere 3.5.6 wit
      security enabled. One node is using a Websphere admin agen
      thur a firewall to connect to the main Websphere node runnin
      the admin server. Various problems either starting a
      application  server on the node running the admin agent and/o
      connectin the admin server node from the admin agent node
      .Running an adminejstrace, it will show that admin server neve
      completes the method: activeObjectInvocation.  This method i
      called from AdminAgentImpl on the admin agent node to updat
      ActiveSecurityConfig on the admin server node.This will cause 
      deadlock condition within the security code
      Local Fix:
      pmr05680_test.ja
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server users of       Administration Agen
      with security enabled
      Problem Description: WebSphere AppServer will not start whensecurity is enabled on a
      adminstrationagent server
      Recommendation:
      Problem Summary: On WebSphere 356, when one node is using administation agen
      to connect to main WAS node&apos;s admin server with both securit
      and auto-start is enabled, the AppServer would failed t
      start.  In the thread dump trace, following thread lock wil
      show
     
      sys_mon_t:0x00239ac0 infl_mon_t: 0x00000000
      com.ibm.ISecurityLocalObjectBaseL13Impl.VaultImpl@8E0130
      8E0138: (Flat locked) owner "Pooled ORB request dispatc
      WorkerThread" (0xa33b7a0) 1 entr
      Waiting to be notified
      "WebServer-Plugin-Cfg-Thread" (0xac43ca8
      sys_mon_t:0x0ab3c658 infl_mon_t: 0x00000000
      com.ibm.ISecurityLocalObjectBasicAuthImpl.SecurityContextImp
      @9BD940/9BD948: (Flat locked) owne
      "WebServer-Plugin-Cfg-Thread
      (0xac43ca8) 1 entr
      Waiting to be notified
      "Pooled ORB request dispatch WorkerThread" (0xa33b7a0
      Problem Conclusion: This is caused by over synchronization in the security componen
      Redundant synchronization code will be removed from securit
      component
      Test Comments:
      Circumvention:
      Temporary Fix: availabl
      Comments:






 APAR: PQ68078 Version: 400
      Abstract:
      WEBSPHERE SECURITY SAS THROWS NULLPOINTEREXCEPTION WHE
      CREDENTIALS EXPIR
      Error Description:
      Customer sees NullPointerException thrown when the credentia
      expires in the sas.server.log file.  Error in log shows
      2>  2002-10-08 20:27:25.491 ,  ServerID: 657623458 
      SecureAssociationInterceptorImpl.server_system_exception 
      Severity code = 0, Error code = 0, Log Exception
      java.lang.NullPointerExceptio
      a
      com.ibm.ISecurityLocalObjectBaseL13Impl.SecureAssociationInterc
      ptorImpl.server_system_exception(SecureAssociationInterceptorIm
      l.java:1824
      at com.ibm.CORBA.iiop.RIs.iterateServerException(RIs.java:739
      a
      com.ibm.CORBA.iiop.RIs.iterateServerExceptionYesYesNoNo(RIs.jav
      :758
      a
      com.ibm.CORBA.iiop.ServerResponseImpl.interceptAndWriteHeaderFi
      st(ServerResponseImpl.java:405
      a
      com.ibm.CORBA.iiop.ServerResponseImpl.write_string(ServerRespon
      eImpl.java:643
      a
      com.ibm.rmi.util.Utility.writeSystemException(Utility.java:1168
      a
      com.ibm.CORBA.iiop.ServerRequestImpl.createSystemExceptionRespo
      se(ServerRequestImpl.java:316
      a
      com.ibm.CORBA.iiop.ServerRequestImpl.createUnknownExceptionResp
      nse(ServerRequestImpl.java:238
      a
      com.ibm.CORBA.iiop.ExtendedServerDelegate.dispatch(ExtendedServ
      rDelegate.java:585
      at com.ibm.CORBA.iiop.ORB.process(ORB.java:2377
      at com.ibm.CORBA.iiop.OrbWorker.run(OrbWorker.java:186
      a
      com.ibm.ejs.oa.pool.ThreadPool$PooledWorker.run(ThreadPool.java
      104
      at com.ibm.ws.util.CachedThread.run(ThreadPool.java:137
      Local Fix:
      none
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y and use LTPA as the   authentication mechanism
     
      Problem Description: NullPointerException thrown when on    credential expiration
     
      Recommendation:
      Problem Summary: NullPointerException thrown when the credential expires
      Error in log shows
      2>  2002-10-08 20:27:25.491 ,  ServerID: 657623458 
      SecureAssociationInterceptorImpl.server_system_exception 
      Severity code = 0, Error code = 0, Log Exception
      java.lang.NullPointerExceptio
      a
      com.ibm.ISecurityLocalObjectBaseL13Impl.SecureAssociationInterc
      ptorImpl.server_system_exception(SecureAssociationInterceptorIm
      l.java:1824
      at com.ibm.CORBA.iiop.RIs.iterateServerException(RIs.java:739
      a
      com.ibm.CORBA.iiop.RIs.iterateServerExceptionYesYesNoNo(RIs.jav
      :758
      a
      com.ibm.CORBA.iiop.ServerResponseImpl.interceptAndWriteHeaderFi
      st(ServerResponseImpl.java:405
      a
      com.ibm.CORBA.iiop.ServerResponseImpl.write_string(ServerRespon
      eImpl.java:643
      a
      com.ibm.rmi.util.Utility.writeSystemException(Utility.java:1168
      a
      com.ibm.CORBA.iiop.ServerRequestImpl.createSystemExceptionRespo
      se(ServerRequestImpl.java:316
      a
      com.ibm.CORBA.iiop.ServerRequestImpl.createUnknownExceptionResp
      nse(ServerRequestImpl.java:238
      a
      com.ibm.CORBA.iiop.ExtendedServerDelegate.dispatch(ExtendedServ
      rDelegate.java:585
      at com.ibm.CORBA.iiop.ORB.process(ORB.java:2377
      at com.ibm.CORBA.iiop.OrbWorker.run(OrbWorker.java:186
      a
      com.ibm.ejs.oa.pool.ThreadPool$PooledWorker.run(ThreadPool.java
      104
      at com.ibm.ws.util.CachedThread.run(ThreadPool.java:137
      Problem Conclusion: Null condition is now checked when processing system_exceptions
     
      A fix for this APAR will be contained in any security cumulativ
      eFix dated after the closure date of this APAR
      Test Comments:
      Circumvention:
      Temporary Fix: Availabl
      Comments:






 APAR: PQ69078 Version: 400
      Abstract:
      PERFORMANCE DEGRADATION AFTER APPLYING SECURITY CUMULATIVE EFI
      FROM 10-0
      Error Description:
      Customer says that they experience degradation in performanc
      after applying WAS Security cumulative efix dated 10-07-02
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y and have deployed     web applications with protected resourc
      s
      Problem Description: Performance degradation in web         applications
     
      Recommendation:
      Problem Summary: Performance degradation in web applications caused by th
      unnecessary creation of the special credentia
      "UNAUTHENTICATED" with each web request to a protecte
      resource
      Problem Conclusion: The UNAUTHENTICATED credential is now cached after it i
      created the first time
      Test Comments:
      Circumvention:
      Temporary Fix: Testfix submitted to Portal Server
      Comments:






 APAR: PQ69188 Version: 400
      Abstract:
      UNEXPECTED LOGIN PROMPT WHEN CLICKING ON ADMIN CONSOLE
      Error Description:
      We set the Security timeout to 300 and the LTPA token timeou
      to 10mn
      When the LTPA Token timeout expired, a popup window i
      displayed asking us to login again and a message is sent in th
      tracefile in order to warn us that the credential have expired
      We expected this behaviour and we were happy
      Then we entered the userid/password, we hit "enter". It seem
      that we are logged in
      
      Then we click on the console and we saw a new popup windo
      asking u
      to login again, but this time without any messages in th
      tracefile
      We entered the userid/password and we were able to go throug
      th
      websphere topology inside the console
      We don&apos;t think that prompting the second time when clickin
      on the console is correct
      Steps taken
      - wait 10m
      - popup windo
      - Login/password (msg in tracefile) and hit ente
      - hit somewhere in the console and you got a second popu
      windo
      - Login/password (no msg in tracefile) and hit ente
      - wait 10m
      - popup windo
      - Login/password (msg in tracefile) and hit ente
      - wait 10m
      - popup windo
      - Login/password (msg in tracefile) and hit ente
      
      By "message in tracefile", we mean JSAS0435E and CNTR0019
      messages are generated
      Local Fix:
      No workaround is known at this time
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y and use the           Administration Console with th
      Authentication Mechanism set to LTPA
      Problem Description: Admin Console displays unexpected      login prompt after login
     
      Recommendation:
      Problem Summary: When the LTPA Token timeout expired, a login window i
      displayed to login again and a message is sent in th
      tracefile in order to warn that the credential have expired
      After username and password is entered, the console appear
      to be logged in.  However, when the console is clicked agai
      to access resources, another login windows is displayed
      Problem Conclusion: This is caused by the expired credential not being cleane
      properly.  The expired credential is now being removed afte
      expiration
      Test Comments:
      Circumvention:
      Temporary Fix: avaliabl
      Comments:






 APAR: PQ70121 Version: 400
      Abstract:
      JAVA.LANG.NULLPOINTEREXCEPTION ERROR ON WAS 4.04 AFTE
      CUMULATIVE SECURITY EFIX INSTALLED
      Error Description:
      Customer installed WAS 4.04 on AIX 4.3.3.  Then install
      cumulative security efix dated 01-06-2003.  Database is ORacle
      After starting admin server, sees in the tracefile
      1/21/03 9:18:20:458 CST  1c37f64b EJBEngine     I WSVR0037I
      Starting EJB jar: Task
      java.lang.NullPointerExceptio
      a
      com.ibm.ISecurityLocalObjectBaseL13Impl.VaultImpl.get_default_c
      edentials(VaultImpl.java(Compiled Code)
      a
      com.ibm.ISecurityLocalObjectBaseL13Impl.CurrentImpl.get_credent
      als(CurrentImpl.java(Compiled Code)
      a
      com.ibm.ISecurityLocalObjectBaseL13Impl.CurrentImpl.get_credent
      als(CurrentImpl.java:313
      a
      com.ibm.ISecurityLocalObjectBaseL13Impl.CurrentImpl.get_credent
      als(CurrentImpl.java:299
      a
      com.ibm.ejs.security.SecurityContext.enable(SecurityContext.jav
      :151
      a
      com.ibm.ws.wlm.admin.config.ServerGroupRefresh$RefreshThread.ru
      (ServerGroupRefresh.java:330
      1/21/03 9:18:26:868 CST  1c37f64b Server        A WSVR0023I
      Server __adminServer open for e-busines
      
      This error does not appear to affect function of the admi
      server security
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y
      Problem Description: java.lang.NullPointerException in      tracefile during server 
      tartup after  security cumulative fix installed
      Recommendation:
      Problem Summary: java.lang.NullPointerException occured during the serve
      startup
     
      Exception as follows
     
      java.lang.NullPointerExceptio
      at com.ibm.ISecurityLocalObjectBaseL13Impl.VaultImpl
      get_default_credentials(VaultImpl.java(Compiled Code)
      at com.ibm.ISecurityLocalObjectBaseL13Impl.CurrentImpl
      get_credentials(CurrentImpl.java(Compiled Code)
      at com.ibm.ISecurityLocalObjectBaseL13Impl.CurrentImpl
      get_credentials(CurrentImpl.java:313
      at com.ibm.ISecurityLocalObjectBaseL13Impl.CurrentImpl
      get_credentials(CurrentImpl.java:299
      at com.ibm.ejs.security.SecurityContext
      enable(SecurityContext.java:151
      Problem Conclusion: java.lang.NullPointerException occured during the serve
      startup.  The null value caused the server credential cache t
      throw the java.lang.NullPointerException during the startup
      However, this exception should not cause any functional loss
     
      A fix for this APAR will be contained in any securit
      cumulative eFix dated after the closure date of this APAR
      Test Comments:
      Circumvention:
      Temporary Fix: availabl
      Comments:






 APAR: PQ70596 Version: 400
      Abstract:
      ADMIN SERVER USES OLD APP SERVER SSLPORT WHEN APP SERVER I
      RESTARTE
      Error Description:
      Environment
      WebSphere Application Server (WAS) 4.0.
      
      Description
      With WAS security enabled after an app server is stoppe
      and started, the admin server continues to try to connect t
      the app server&apos;s old SSLPort instead of the new ramdoml
      created SSLPort resulting in following messages in th
      admin server&apos;s tracefile
      
      1/20/03 19:25:59:890 CET  4ed74147 ActiveServerP A ADMS0032I
      Started server: SEC_01 (pid 12686
      1/20/03 19:26:31:145 CET  4ed74147 SystemOut     
      1>  2003-01-20 19:26:31.134 ,  ServerID: 1917109904 
      VaultImpl.init_security_context 
      1/20/03 19:26:31:146 CET  4ed74147 SystemOut     
      JSAS0070E: Unable to complete secure association at th
      client
      Retry the client program after a few minutes wait.  I
      th
      problem still persists, contact support for assistance
      1/20/03 19:26:31:564 CET  4ed74147 SystemOut     
      3>  2003-01-20 19:26:31.563 ,  ServerID: 1917109904 
      VaultImpl.init_security_context 
      1/20/03 19:26:31:565 CET  4ed74147 SystemOut     
      JSAS0070E: Unable to complete secure association at th
      client
      Retry the client program after a few minutes wait.  I
      th
      problem still persists, contact support for assistance
      1/20/03 19:26:31:570 CET  4ed74147 ActiveEJBServ W ADSM0104W
      Failed t
      initialize a server: SEC_01 CORBA COMM_FAILURE 1 No
      nested exception is
      org.omg.CORBA.COMM_FAILURE:   minor code: 1  completed: N
      Local Fix:
      Set the app server&apos;s SSL port to a static valu
     
      Logically Dependent Apars: 
      Users Affected: All WebSphere Application Server users who  have enabled securi
      y
      Problem Description: WebSphere Application Server is unable to reconnect after appli
      ation server  is stopped and restarted
      Recommendation:
      Problem Summary: After an application server is stopped and started, th
      adminstration server continues to try to connect to th
      application server&apos;s old SSLPort instead of the new ramdoml
      created SSLPort resulting in following messages in the admi
      server&apos;s tracefile
      
      1/20/03 19:25:59:890 CET  4ed74147 ActiveServerP A ADMS0032I
      Started server: SEC_01 (pid 12686
      1/20/03 19:26:31:145 CET  4ed74147 SystemOut     
      1>  2003-01-20 19:26:31.134 ,  ServerID: 1917109904 
      VaultImpl.init_security_context 
      1/20/03 19:26:31:146 CET  4ed74147 SystemOut     
      JSAS0070E: Unable to complete secure association at th
      client
      Retry the client program after a few minutes wait.  I
      th
      problem still persists, contact support for assistance
      Problem Conclusion: The adminserver now reregisters application server&apos;s ne
      ssl port and then makes new connection to the new applicatio
      server&apos;s new port
      Test Comments:
      Circumvention:
      Temporary Fix: availabl
      Comments:






 APAR: PQ71310 Version: 400
      Abstract:
      getUserPrincipal() getname() returns wrong name rather than log
      ed in username accessing from another domai
      Error Description:
      Customer logs in to the administration console using th
      administration username and passwor
      The Custom realm is called and accept the administratio
      username and password
      Then log to the Web Application using a web username an
      password (username and password are different to administratio
      username and password): The Custom realm is called and accep
      the authentication
      The Web Application (a servlet) cal
      getUserPrincipal().getName(
      from the HttpServletRequest
      The Web application receives the administration user identity
      Later calls to getUserPrincipal().getName() from th
      HttpServletRequest return the correct logged user
      Local Fix:
      non
     
      Logically Dependent Apars: 
      Users Affected: WebSphere Application Server security user
      who have deployed servlets and EJBs i
      different realms
      Problem Description: getName() in getUserPrincipal(
      may not return the right securit
      name during an EJB call
      Recommendation:
      Problem Summary:
      getName() in getUserPrincipal() may return wrong securit
      name after servlet accesses an EJB in a different securit
      domain
      Problem Conclusion: When a servlet accesses EJB in a different realm, security wil
      try to map the invocation credential to the target realm. I
      the credential mapping fails, the original credential is no
      returned rather than returning the default credential
      Test Comments:
      Circumvention:
      Temporary Fix: provided test fi
      Comments:






 APAR: PQ72041 Version: 350
 APAR: PQ71397 Version: 400
      Abstract:
      Admin server is trying to use expired tokens from cache - inval
      d tokens
      Error Description:
     
      Local Fix:
     
     
      Logically Dependent Apars: 
      Users Affected:
      Problem Description:
      Recommendation:
      Problem Summary:
      Problem Conclusion:
      Test Comments:
      Circumvention:
      Temporary Fix:
      Comments:






 APAR: PQ71308 Version: 400
      Abstract:
      WAS is using invalid tokens from server cache instead of new on
      Error Description:
      After an ltpa token expires and the user tries to access 
      secured resource they get re-directed to the login page(a
      expected). After entering their user name and password agai
      they get an "Invalid Credential" exception and cannot ge
      access
     
      If they were to wait a period of time, say 5-10 mins, they hav
      no trouble getting back in
      Local Fix:
      Increase LTPA timeou
     
      Logically Dependent Apars: 
      Users Affected:
      Problem Description:
      Recommendation:
      Problem Summary:
      Problem Conclusion:
      Test Comments:
      Circumvention:
      Temporary Fix:
      Comments: duplicated APAR