PQ66974: GETCALLERPRINCIPAL() SHOULD JUST ALWAYS RETURN "UNAUTHENTICATED"

 A fix is available

4.0.5: WebSphere Application Server Version 4.0 Fix Pack 5 (Version 4.0.5)



APAR status
Closed as program error.

Error description
Customer sent the following:
We have a distributed log viewer servlet architecture, which
means each AppServer must have a Servlet to read log file and
present it to the end user.
.
So we must know how to invoke this servlet before it is
serviceable(choosable from a drop down list). In the servlet
init() method, we probe WebSphere servlet engine configuration
to obtain HTTP port number for the hosting AppServer. Then the
user can pick a LogViewer and invoke it based on this
information.
.
The available LogViewer Tracking EJB has to be invoked from the
init() method in this sense, so in the serlvet init() we will
perform following execution:
.
try
      {
         /** retrieve the collection of application server
adapters, retrieve configuration information from servlet engin
*/
         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 the
database */
         Collection logServers =
m_logServerManager.getLogServers();
         for (Iterator it = logServers.iterator();
it.hasNext(); )
         {
            LogServer logServer = (LogServer)it.next();
            if
(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 the
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 persistence
stateless session bean. createLogServer() is just an insert
statement, while getLogServerManager() is simple select
statement. As we have an abstract OR layer, I just provide the
functionality of these methods here.
.
In our EJB, we have logging system, which will always capture
user's caller information at the begining of the method and
push it down to the underneath logging system. So whenever
there is exception and it needs logging, the logging system can
always write down the caller infomation transparently.  Logging
system is based on Log4j.
.
createLogServer(Object value) {
  // this method internally will keep track caller info, it is
pushed
down
to the logging system, which is defined in a parent EJB class
  methodStart("createLogServer", value);
  try {
    // operations;
  } catch(Exception e) {
    // whenever we want to log the exception, we retrieve back
the
caller
info directly from logging system
    // so the api is ignorant of it is inside EJB or Servlet
    logging(e);
  } finally {
     // we will pop up the caller info from the logging system
     methodFinish();
  }
}
.
This model is applied to every single EJB in our system, and it
will fail in the methodStart() invokation for requests
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 theContext
   {
      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 Loggin
    Diagnostic Messages" part of the book "<i>Pattern Languages
of Program Design 3</i>" edited by Martin et al.
    <p>A Nested Diagnostic Context, or NDC in short, is an
instrument to distinguish interleaved log output from different
sources.
.
This problem applies to all EJBs that will track caller and
being invoked from init() method of servlets.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server 4.0 security    *
*                 users who use programmatic security.         *
****************************************************************
* PROBLEM DESCRIPTION: If the anonymous principal is           *
*                      propagated or the user identity is      *
*                      missing, getCallerPrincipal() returns   *
*                      inconsistant results.                   *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
getCallerPrincipal() returns different results in different
timing if the anonymous principal is propagated or caller
identity is missing.  EJB 1.2 spec define that
getCallerPrincipal() should always return container specific
unauthenticated principal.
Problem conclusion
getCallerPrincipal() should return "UNAUTHENTICATED", the
WebSphere specific unauthenticated principal, if caller
identity is missing or the anonymous principal is
propagated.
Temporary fix
send testing eFix to customer.
Comments
APAR information
APAR number PQ66974
Reported component name WEBSPHERE AE NT
Reported component ID 5630A2201
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-10-07
Closed date 2002-10-28
Last modified date 2002-10-28

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
SECURITY          

SRLS

Fix information
Fixed component name WEBSPHERE AE NT
Fixed component ID 5630A2201

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ66974
IBM Group: Software Group
Modified date: Oct 28, 2002