Errors after enabling security
What kind of error are you seeing?
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.
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.
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. Please 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.
- 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
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 application server which contains the samples. Select MDBSamples and
click uninstall.
Error message: SECJ0237E: One or more
vital LTPAServerObject configuration attributes are null or not available after
enabling security and starting the application server.
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:
- Click System Administration > Console users > LTPA
- Enter a password, which can be anything.
- Enter the same password in Confirm Password.
- Click Apply.
- Click Generate Keys.
- Click on Save.
The
exception AccessControlException, is reported in the error log file
The
problem is related to the Java 2 Security feature of WebSphere Application
Server, 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
\WebSphere\AppServer\installedApps\maeda\adminconsole.ear\adminconsole.war\
WEB-INF\validation.xml read)
For an explanation of Java 2 security, how and why to enable or disable
it, how it relates to policy files, and how to edit policy files, see the Java 2 security topic in
the information center navigation. The topic explains that Java 2 security
is not only used by this product, 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 WebSphere Application Server.
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 SYSPRINT or SYSOUT log file which reports the details
of the syntax error. For example: SECJ0189E: Caught ParserException while
creating template for application policy \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.
- 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:
\WebSphere\AppServer\logs\server1\SystemOut_02.08.20_11.19.53.log :
access denied (java.io.FilePermission
\WebSphere\AppServer\logs\server1\SystemOut_02.08.20_11.19.53.log delete)
Code:
com.ibm.ejs.ras.RasTestHelper$7 in
{
file:/WebSphere/AppServer/installedApps/maeda/JrasFVTApp.ear/RasLib.jar}
Stack Trace:
java.security.AccessControlException: access denied (java.io.FilePermission
\WebSphere\AppServer\logs\server1\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:/WebSphere/AppServer/lib/securityimpl.jar
ClassLoader: com.ibm.ws.bootstrap.ExtClassLoader
Permissions granted to CodeSource
(
file:/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.
Read Java 2 Security in
the information center navigation carefully to determine in which policy file
or ra.xml file that permission should be specified.
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:
- Verify that your user ID and password are correct.
- Verify that the user ID exists in the registry.
- Verify that the base distinguished name (DN) is correct.
- Verify that the user filter is correct.
- 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.
- Verify that the host name and LDAP type are correct.
Consult with the administrator of the user registry if the problem persists.

Troubleshooting by task: What are you trying to do?

Access problems after enabling security
Searchable topic ID:
rtrb_secprobs2
Last updated: Jun 21, 2007 9:56:50 PM CDT
WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rtrb_secprobs2.html