Errors after enabling security

 

Common Errors

1. Authentication error accessing a Web page

2. Authorization error accessing a Web page

3. Error Message: SECJ0314E... Current Java 2 security policy reported a potential violation

4. MSGS0508E: The JMS Server security service was unable to authenticate user ID: error displayed in SystemOut.log when starting an appserver

5. Error Message: SECJ0237E... One or more vital LTPAServerObject configuration attributes are null or not available after enabling security and starting the appserver.

6. An AccessControlException is reported in the SystemOut.log.

7. Error Message: SECJ0336E... Authentication failed for user {0} because of the following exception {1}

 

Authentication error accessing a Web page

Possible causes for authentication errors include...

• Incorrect user name or passwords. Check the user name and password and make sure they are correct.

• Security configuration error : User registry type is not set correctly. Check the user registry property in global security settings in the administrative console. Verify that it is the intended user registry.

• Internal program error. If the client application is a Java standalone program, this program might not gather or send credential information correctly.

If the user registry configuration, user ID, and password appear correct, use the WAS trace to determine the cause of the problem. To enable security trace, use the com.ibm.ws.security.*=all=enabled trace specification.

 

Authorization error accessing a Web page

If a user who should have access to a resource does not, there is probably a missing configuration step. Review the steps for securing and granting access to resources.

Specifically...

• Check required roles for the accessed Web resource.

• Check the authorization table to make sure that the user, or the groups to which the user belongs, is assigned to one of the required roles.

• View required roles for the Web resource in the deployment descriptor of the Web resource.

• View the authorization table for the application that contains the Web resource, using the administrative console.

• Test with a user who is granted the required roles, to see if the user can access the problem resources.

• If the problem user is required to have one or more of the required roles, use the administrative console to assign that user to required roles. Then stop and restart the application.

If the user is granted required roles, but still fails to access the secured resources, enable security trace, using com.ibm.ws.security.*=all=enabled as the trace specification. Collect trace information for further resolution.

 

Error Message: SECJ0314E: Current Java 2 security policy reported a potential violation on server

If you find errors on your server similar to

Error Message: SECJ0314E: Current Java 2 Security policy reported a potential violation of Java 2 Security Permission. Refer to Problem Determination Guide for further information.
{0}Permission\:{1}Code\:{2}{3}Stack Trace\:{4}Code Base Location\:{5}

The Java security manager checkPermission() method has reported an exception, SecurityException.

The reported exception might be critical to the secure system. Turn on security trace to determine the potential code that might have violated the security policy. Once the violating code is determined, verify if the attempted operation is permitted with respect to Java 2 Security, by examining all applicable Java 2 security policy files and the application code.

A more detailed report is enabled by either configuring RAS trace into debug mode, or specifying a Java property.

• Check the trace enabling section for instructions on how to configure RAS trace into debug mode, or

• Specify the following property in the Application Servers > server name > ProcessDefinition > Java Virtual Machine panel from the administrative console in the Generic JVM arguments panel...

  • Add the run-time flag java.security.debug

  • Valid values:

    access	Print all debug information including: required permission, code, stack, and code base location.
    stack	Print debug information including: required permission, code, and stack.
    failure	Print debug information including: required permission and code.

For a review of Java security policies and what they mean , see the Java 2 Security documentation at http://java.sun.com/j2se/1.3/docs/guide/security/index.html .

Tip: If the application is running with a Java Mail API, this message might be benign. You can update the installed Enterprise Application root/META-INF/was.policy file to grant the following permissions to the application:

• permission java.io.FilePermission "${user.home}${/}.mailcap", "read";

• permission java.io.FilePermission "${user.home}${/}.mime.types", "read";

• permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";

• permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

 

Error message: MSGS0508E: The JMS Server security service was unable to authenticate user ID:" error displayed in SystemOut.log when starting an appserver

This error can result from installing the JMS messaging API sample and then enabling security. You can follow the instructions in the Configure and Run page of the corresponding JMS sample documentation to configure the sample to work with WebSphere Application Server security.

You can verify the installation of the message-driven bean sample by launching the installation program, selecting Custom, and browsing the components which are already installed in the Select the features you like to install panel. The JMS sample is shown as Message-Driven Bean Sample, under Embedded Messaging.

You can also verify this installation by using the administrative console to open the properties of the appserver which contains the samples. Select MDBSamples and click uninstall.

If the problem persists, review the section Messaging (JMS) component troubleshooting tips

 

Error message: SECJ0237E: One or more vital LTPAServerObject configuration attributes are null or not available after enabling security and starting the appserver.

This error message can result from selecting LTPA as the authentication mechanism, but not generating the LTPA keys. The LTPA keys encrypt the LTPA token.

To resolve this problem...

1. Click System Administration > Console users > LTPA

2. Enter a password, which can be anything.

3. Enter the same password in Confirm Password.

4. Click Apply.

5. Click Generate Keys.

6. Click on Save.

 

The exception AccessControlException, is reported in the SystemOut.log

The problem is related to the Java 2 Security feature of WAS, the API-level security framework that is implemented in WebSphere Application Server Version 5. An exception similar to the following example displays. The error message and number can vary.

E SRVE0020E: [Servlet Error]-[validator]: Failed to load servlet: 
java.security.AccessControlException: 
access denied  java.io.FilePermission(
C:\WebSphere\AppServer\installedApps\maeda\adminconsole.ear\adminconsole.war\ 
WEB-INF\validation.xml read) 

Java 2 security is not only used by WAS, but developers can also implement it for their business applications. Administrators might need to involve developers, if this exception is thrown when a client tries to access a resource hosted by WAS.

Possible causes of these errors include...

• Syntax errors in a policy file.

• Syntax errors in permission specifications in the ra.xml file bundled in a .rar file. This case applies to resource adapters that support connector access to CICS or other resources.

• An application is missing the specified permission in a policy file, or in permission specifications in an ra.xml file bundled in a .rar file

• The class path is not set correctly, preventing the permissions for the resource.xml file for SPI from being correctly created.

• A library called by an application, or the application, is missing a doPrivileged block to support access to a resource.

• Permission is specified in the wrong policy file.

To resolve these problems...

• Check all of the related policy files to verify that the permission shown in the exception, for example java.io.FilePermission, is specified.

• Look for a related ParserException in the SystemOut.log file which reports the details of the syntax error. For example: SECJ0189E... Caught ParserException while creating template for application policy C:\WAS\config\cells\xxx\nodes\xxx\app.policy . The exception is com.ibm.ws.security.util.ParserException: line 18: expected ';', found 'grant'

• Look for a message similar to: SECJ0325W: The permission permission specified in the policy file is unresolved.

• Check the call stack to determine which method does not have the permission. Identify the class path of this method. If it is hard to identify the method, enable the Java2 security Report.

  • Configuring RAS trace by specifying com.ibm.ws.security.core.*=all=enabled, or specifying a Java property.java.security.debug property. Valid values for the java.security.debug property are...

    access	Print all debug information including: required permission, code, stack, and code base location.
    stack	Print debug information including: required permission, code, and stack.
    failure	Print debug information including: required permission and code.

  • The report shows...

    Permission	the missing permission.
    Code	which method has the problem.
    Stack Trace	where the access violation occurred.
    CodeBaseLocation	the detail of each stack frame.

    Usually, Permission and Code are enough to identify the problem. The following example illustrates a report

    Permission: 
    C:\WebSphere\AppServer\logs\server\SystemOut_02.08.20_11.19.53.log
     : 
    access denied  java.io.FilePermission(
    C:\WebSphere\AppServer\logs\server\SystemOut_02.08.20_11.19.53.log
     delete) 
    
    Code: 
     com.ibm.ejs.ras.RasTestHelper$7  in  
    {file:/C:/WebSphere/AppServer/installedApps/maeda/JrasFVTApp.ear/RasLib.jar
    } 
    
    Stack Trace: 
    
    java.security.AccessControlException: access denied  java.io.FilePermission(
    C:\WebSphere\AppServer\logs\server\SystemOut_02.08.20_11.19.53.log delete
    ) 
            at java.security.AccessControlContext.checkPermission
                                  (AccessControlContext.java(Compiled Code)) 
            at java.security.AccessController.checkPermission
                                  (AccessController.java(Compiled Code))
            at java.lang.SecurityManager.checkPermission
                                  (SecurityManager.java(Compiled Code)) 
                                   . 
    Code Base Location: 
    
    com.ibm.ws.security.core.SecurityManager : 
    file:/C:/WebSphere/AppServer/lib/securityimpl.jar
    
      ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader 
      Permissions granted to CodeSource 
    (file:/C:/WebSphere/AppServer/lib/securityimpl.jar <no certificates>
    
      { 
         java.util.PropertyPermission(java.vendor read); 
         java.util.PropertyPermission(java.specification.version read); 
         java.util.PropertyPermission(line.separator read); 
         java.util.PropertyPermission(java.class.version read); 
         java.util.PropertyPermission(java.specification.name read); 
         java.util.PropertyPermission(java.vendor.url read); 
         java.util.PropertyPermission(java.vm.version read); 
         java.util.PropertyPermission(os.name read); 
         java.util.PropertyPermission(os.arch read); 
       } 
       ( This list continues.)
    
    

• If the method is SPI, check the resources.xml file to ensure that the class path is correct.

• To confirm that all of the policy files are loaded correctly, or what permission each class path is granted, enable the trace with com.ibm.ws.security.policy.*=all=enabled. All loaded permissions are listed in the trace.log file. Search for the app.policy, was.policy and ra.xml files. To check the permission list for a class path, search for Effective Policy for classpath.

• If there are any syntax errors in the policy file or ra.xml file, correct them with the policytool. Avoid editing the policy manually, because syntax errors can result.

• If a permission is listed as Unresolved, it does not take effect. Verify that the specified permission name is correct.

• If the class path specified in the resource.xml file is not correct, correct it.

• If a required permission does not exist in either the policy files or the ra.xml file, examine the application code to see if you need to add this permission. If so, add it to the proper policy file or ra.xml file.

• If the permission should not be granted outside of the specific method that is accessing this resource, modify the code needs to use a doPrivileged block.

• If this permission does exist in a policy file or a ra.xml file and they were loaded correctly, but the class path still does not have the permission in its list, the location of the permission might not be correct.

Tip: If the application is running with the Java Mail API, you can update the installed Enterprise Application root/META-INF/was.policy file to grant the following permissions to the application:

• permission java.io.FilePermission "${user.home}${/}.mailcap", "read";

• permission java.io.FilePermission "${user.home}${/}.mime.types", "read";

• permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";

• permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";

 

Error Message: SECJ0336E: Authentication failed for user {0} because of the following exception {1}

This error message results if the user ID indicated is not found in the LDAP user registry. To resolve this problem...

1. Verify that your user ID and password are correct.

2. Verify that the user ID exists in the registry.

3. Verify that the base distinguished name (DN) is correct.

4. Verify that the user filter is correct.

5. Verify that the bind DN and the password for the bind DN are correct. If the bind DN and password are not specified, add the missing information and retry.

6. Verify that the host name and LDAP type are correct.

Consult with the administrator of the user registry if the problem persists.

 

See Also

1. Troubleshooting by component: What is not working?
2. Access problems after enabling security
3. Troubleshooting the security component.
4. Obtaining help from IBM

 

---