Fix (APAR):  WAS_Security_03-17-2003_4.0.5-4.0.4-4.0.3_AEs_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_AEs_cumulative_eFix
                    WAS_Security_10-07-2002_4.0.4-4.0.3_AEs_cumulative_eFix
                    WAS_Security_10-31-2002_4.0.4-4.0.3_AEs_cumulative_eFix,
                    WAS_Security_11-19-2002_4.0.4-4.0.3-4.0.2_AEs_cumulative_eFix an
                    WAS_Security_01-06-2003_4.0.5-4.0.4_AEs_cumulative_eFi
                    as well as any eFixes for APARs listed below




CMVC Defect:  See APAR list below

Byte size of APAR:  1368514

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/efix
   Solaris/Linux: /tmp/WebSphere/efix
         Windows: c:\temp\WebSphere\efix

2) Copy jar file to the director


3) Shutdown WebSphere

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 WebSphere


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, either PQ69951 or PQ70054 must be applied.  Any fix which contains
one of the aforementioned APARs is allowable.

If the following excption is encountered after applying the fixes, apply the lates
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 th
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 remov
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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