Troubleshoot: Security

Use these resources to determine the cause of problems that occur when using WebSphere Application Server security.

• Check the application server standard output and standard error log files. For information on the log files and where they are located, see WebSphere Application Server log files.

• When troubleshooting security-related problems, these questions are very helpful and should be considered:

  Does the problem occur when security is disabled?
  This is a good litmus test to determine that a problem is security related. However, just because a problem only occurs when security is enabled does not always make it a security problem. More troubleshooting is necessary to ensure the problem is really security-related.

  Did security appear to initialize properly?
  A lot of security code is visited during initialization. So you likely see problems there first if the problem is configuration related. The following sequence of messages generated in the SystemOut.log indicate normal code initialization of an application server. This varies based on the configuration, but the messages are similar:

  SASRas        A JSAS0001I: Security configuration initialized. 
  SASRas        A JSAS0002I: Authentication protocol: CSIV2/IBM 
  SASRas        A JSAS0003I: Authentication mechanism: SWAM 
  SASRas        A JSAS0004I: Principal name: BIRKT20/pbirk 
  SASRas        A JSAS0005I: SecurityCurrent registered. 
  SASRas        A JSAS0006I: Security connection interceptor initialized. 
  SASRas        A JSAS0007I: Client request interceptor registered. 
  SASRas        A JSAS0008I: Server request interceptor registered. 
  SASRas        A JSAS0009I: IOR interceptor registered. 
  NameServerImp I NMSV0720I: Do Security service listener registration. 
  SecurityCompo A SECJ0242A: Security service is starting 
  UserRegistryI A SECJ0136I: 
   Custom Registry:com.ibm.ws.security.registry.nt.NTLocalDomainRegistryImpl 
   has been initialized 
  SecurityCompo A SECJ0202A: Admin application initialized successfully 
  SecurityCompo A SECJ0203A: Naming application initialized successfully 
  SecurityCompo A SECJ0204A: Rolebased authorizer initialized successfully 
  SecurityCompo A SECJ0205A: Security Admin mBean registered successfully 
  SecurityCompo A SECJ0243A: Security service started successfully 
  SecurityCompo A SECJ0210A: Security enabled true 

  Is there a stack trace or exception printed in the SystemOut.log?
  A single stack trace can tell a lot about the problem. What code initiated the code that failed? What is the failing component? Which class did the failure actually come from?

  Is this a distributed security problem or a local security problem?

  • If the problem is local, that is the code involved does not make a remote method invocation, then troubleshooting is isolated to a single process. It is important to know when a problem is local versus distributed since the behavior of the Object Request Broker (ORB), among other components, is different between the two.
  • Once a remote method invocation takes place, an entirely different security code path is entered. When you know that the problem involves two or more servers, the techniques of troubleshooting change. You need to check the log files of all servers involved. If possible, make sure the timestamps on all machines match as closely as possible so that you can find the request and reply pair from two different processes.

  Is the problem related to authentication or authorization?
  Most security problems fall under one of these two categories. Authentication is the process of determining who the caller is. Authorization is the process of validating that the caller has the proper authority to invoke the requested method. When authentication fails, typically this is related to either the authentication protocol, authentication mechanism or user registry. When authorization fails, this is usually related to the application bindings from assembly and/or deployment and to the caller's identity who is accessing the method and the roles required by the method.

  Is this a Web or EJB request?
  Web requests have a completely different code path than EJB requests. Also, there are different security features for Web requests than for EJB requests, requiring a completely different body of knowledge to resolve. For example, when using the LTPA authentication mechanism, the Single SignOn feature is available for Web requests but not for EJB requests. Web requests involve HTTP header information not required by EJB requests due to the protocol differences. Also, the Web container (or servlet engine) is involved in the entire process. Any of these components could be involved in the problem and all should be considered during troubleshooting, based on the type of request and where the failure occurs.
  Secure EJB requests heavily involve the ORB and Naming components since they flow over the RMI/IIOP protocol. In addition, when work flow management (WLM) is enabled, other behavior changes in the code can be observed. All of these components interact closely for security to work properly in this environment.

  Does the problem seem to be related to SSL?
  The Secure Socket Layer (SSL) is just that, a totally distinct, separate layer of security. Troubleshooting SSL problems are usually separate from troubleshooting authentication and/or authorization problems. There are many things to consider. Usually, SSL problems are first time setup problems because the configuration can be difficult.
  Each client must contain the server's signer certificate. During mutual authentication, each server must contain the client's signer certificate. Also, there can be protocol differences (SSLv3 vs. TLS), and listener port problems related to stale IORs (for example, IORs from a server reflecting the port prior to the server restarting).

  Is the problem related to Java 2 Security?
  Java 2 Security is a new feature in WebSphere Application Server V5.0. It is a new programming model that is very pervasive and has a huge impact on application development. It is disabled by default, but is enabled automatically when Global Security is enabled. However, you can disable or enable it independently of Global Security.
  There are implications if Java 2 Security is enabled, deployers or administrators are required to make sure that all the applications are granted the required permissions, otherwise, applications may fail to run. For example, you may see a message similar to this in you SystemOut.log: java.security.AccessControlException: access denied (java.security.SecurityPermission printIdentity) For information on using and trouble shooting Java 2 Security, see Java 2 security.

• Read the release notes. WebSphere Application Server Release Notes (http://publib.boulder.ibm.com/was400/docs/relnotes502.html) .

• Check the WebSphere Application Server FAQ database .

• Refer to the WebSphere Application Server for iSeries newsgroup .
  This iSeries Technical Support Web-based forum is dedicated to WebSphere Application Server for iSeries.

• Contact IBM support. For more information, see Get support for WebSphere Application Server.