Use this information if you are experiencing errors after
security is enabled.
New feature: This topic
references one or more of the application server log files. Beginning
in WebSphere Application Server Version 8.0 you can configure the
server to use the High Performance Extensible Logging (HPEL) log and
trace infrastructure instead of using
SystemOut.log ,
SystemErr.log,
trace.log, and
activity.log files or native z/OS logging
facilities. If you are using HPEL, you can access all of your log
and trace information using the LogViewer command-line tool from your
server profile bin directory. See the information about using HPEL
to troubleshoot applications for more information on using HPEL.
newfeat
What kind of error are you seeing?
For general
tips on diagnosing and resolving security-related problems, see the
topic Troubleshooting
the security component.
IBM
® Support has documents and tools that can
save you time gathering information needed to resolve problems as
described in
Troubleshooting help from IBM. Before opening
a problem report, see the Support page:
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 that they are correct.
- Security configuration error : User registry type is not set
correctly. Check the user registry property in administrative security settings in the administrative
console. Verify that the user registry property is the intended user
registry.
- Internal program error. If the client application is a Java stand-alone program, this program
might not gather or send credential information correctly.
If the user
registry configuration, user ID, and password appear correct, use
the WebSphere® Application Server 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 is supposed to have
access to a resource does not, a configuration step is probably missing.
Review Authorizing access to administrative roles.
Specifically:
- Check the 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 user is required to have one or more of the required roles,
use the administrative console to assign that user to required roles,
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.
Authentication fails when code pages
differ between the client and the server
When a client uses
a code page that is different from the server, and non-US-ASCII characters
are used for the user ID and password during basic authentication,
the login does not succeed. The HTTP header does not include the
encoding method information that is necessary to translate the encoded
data, so the server does not know how to decode the information correctly.
Use a login form that relies on POST parameters, which are in
the HTML body text. The encoding for the text is sent by the browser
and so is capable of being decoded properly.
Note: Web services customers
are not able to use form login to resolve this problem. Users must
ensure there is consistency in the code pages between the client and
the server.
Error Message: CWSCJ0314E: Current
Java 2 security policy reported a potential violation on server
If
you find errors on your server similar to:
Error Message: CWSCJ0314E: 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 a
SecurityException exception .
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
Tracing and logging configuration article for instructions on how
to configure Reliability Availability Serviceability (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 java.security.debug run-time flag
- 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, 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
application programming interface (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: CWMSG0508E: The
JMS Server security service was unable to authenticate user ID:" error
displayed in SystemOut.log when starting an application server
This
error can result from installing the Java Message
Service (JMS) 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 that contains the samples. Select MDBSamples and
click uninstall.
Error message: CWSCJ0237E: 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 Lightweight
Third Party Authentication (LTPA) as the authentication mechanism,
but not generating the LTPA keys. The LTPA keys encrypt the LTPA
token.
To resolve this problem:
- Click Security > Global security > Authentication >
Authentication mechanisms and expiration> LTPA
- Enter a password, which can be anything.
- Enter the same password in Confirm Password.
- Click Apply.
- Click Generate Keys.
- Click Save.
The AccessControlException exception,
is reported in the SystemOut.log
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. An exception
similar to the following example displays. The error message and number
can vary.
CWSRV0020E: [Servlet Error]-[validator]: Failed to load servlet:
java.security.AccessControlException: access denied
(java.io.FilePermission
app_server_root/systemApps/isclite.ear/isclite.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 created when a client
tries to access a resource that is 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
that is 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 ra.xml file
bundled in a .rar file.
- The class path is not set correctly, preventing the permissions
for the resource.xml file for Service Provider
Programming Interface (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:
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: CWSCJ0336E: Authentication
failed for user {0} because of the following exception {1}
This
error message results if the user ID that is indicated is not found
in the Lightweight Directory Access Protocol (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.
Error Message: An unexpected exception
occurred initializing the security collaborator.java.lang.SecurityException:
AuthConfigFactory error: java.lang.ClassNotFoundException: org.apache.geronimo.components.jaspi.AuthConfigFactoryImpl
This
error message occurs when your java.security file is missing an entry
for the JASPI Provider. The default location for the java.security
file is
install_dir/properties. Edit the java.security
file and add the following lines to it:.
#
# The fully qualified class name of the default JASPI factory implementation class.
#
authconfigprovider.factory=com.ibm.ws.security.jaspi.ProviderRegistry
Note: This
error only appears if you explicitly set your configuration to use
this class. Otherwise, you might see error message SECJ8032W below.
Error Message: SECJ8032W: AuthConfigFactory
is undefined, using the default JASPI factory implementation class
This
error message occurs if the JASPI factory implementation is not defined.
The default JASPI factory implementation has been set in the server
runtime. However, JASPI might not function for a client.
To
resolve, set the fully qualified class name of the default JASPI factory
implementation class as the value for the property authconfigprovider.factory
in the java.security file as in below:
#
# The fully qualified class name of the default JASPI factory implementation class.
#
authconfigprovider.factory=com.ibm.ws.security.jaspi.ProviderRegistry
Error Message: SECJ0352E: Could
not get the users matching the pattern {0} because of the following
exception {1}
This authentication failure message displays
when an external user account repository is corrupted or unavailable,
and
WebSphere Application Server is unable
to authenticate the user name in the repository. Generally, authentication
error messages are followed by additional information that indicates
the nature or root cause of the problem, such as:
Make sure the users matching the pattern exist in the registry. Contact your service representative if the problem persists.
This
additional information might not provide a clear user action if the
user account repository is corrupted or the user loses connectivity
between
WebSphere Application Server and
an external user account repository. The external user account repository,
which is referred to as a repository in this document, might be a
Lightweight Directory Access Protocol (LDAP) product.
To resolve
this problem, you might need to re-install the repository and verify
that it installs successfully by testing the connection.
CAUTION:
Proceed with the following steps only if you have ensured
that all WebSphere Application Server-related
configuration settings are accurate.
Complete the following
steps to resolve the issue:
- Restart both the repository and WebSphere Application Server.
- Test the connection to the repository. If the connection attempt
still fails, it might be necessary to re-install the repository.
- If diagnostics are provided with the repository, run them to avoid
having to re-install the repository.
Attention: If the
previous steps do not fix the problem, you might need to re-install
the repository. Before proceeding, generate a complete list of all
the configured users and groups; you will need to re-populate these
fields after the re-installation.
- If necessary, re-install the corrupted repository.
- Populate the users and groups from your list into the newly installed
repository.
- Restart both the repository and WebSphere Application Server.
- In the administrative console, navigate to Security > Global
security, and select the appropriate user account repository.
For example, select Standalone LDAP registry if you are using
a stand-alone Lightweight Directory Access Protocol repository.
- Click Test connection to ensure that WebSphere Application Server can connect to
the repository.
Validation
of LTPA token failed due to invalid keys or token type
If
the security context deserialization of an LTPA token fails with a
WSSecurityException containing this message: Validation of
LTPA token failed due to invalid keys or token type, set the
com.ibm.websphere.security.recoverContextWithNewKeys property to true.
Generate keys error when using the
Profile Management tool to create a new profile
When you
create a new profile using either the Profile Management tool or the
command-line manageprofiles utility, an error message displays that
indicates either partial success or failure. The error message, which
is located in the install_dir/logs/manageprofiles/profile_name_create.log
file, might point to an error in either the generateKeysforSingleProfile
task or the generateKeysForCellProfile task.
The Profile Creation
tool and the manageprofiles utility invoke several tasks. The generateKeysForSingleProfile
task is invoked when you create a stand-alone application server or
a deployment manager profile. The generateKeysForCellProfile task
is invoked when you create a cell profile. Both of these tasks are
the first tasks to invoke the wsadmin commands. Although the log indicates
an error in one of these tasks, the error might actually result from
a wsadmin command failure and not an error in the security tasks.
To
determine the actual cause of the problem, review the information
that is provided in the following log files:
- install_dir/logs/manageprofiles/profile_name_create.log
file indicates the error code of the failure
- install_dir/logs/manageprofiles/profile_name/keyGeneration.log
file
- install_dir/logs/manageprofiles/profile_name/wsadminListener.log
file
Some security roles are not immediately
available for a secured application where LDAP has Tivoli Access Manager enabled
In
some instances, some security roles might not be immediately available
when you deploy a secured application where LDAP has Tivoli Access Manager enabled.
You might
see an error such as the following:
"Exception: java.lang.OutOfMemoryError"
You
might be able to address this issue by doing the following:
- Allocate more memory to the minimum and maximum java heap size.
- In the administrative console, select Servers/server types/WebSphere
Application servers --> server1.
- Select Server Infrastructure/Java and Process Management/Process
Definition.
- Select Java Virtual Machine.
- Set the initial heap size to 512 MB and the maximum heap size
to 1024 MB.
- Select OK and then Save.
- Restart WebSphere Application Server.
- While WebSphere Application
Sever is stopped, add some performance tuning properties for embedded Tivoli Access Manager.
- In the config/cells/CELLNAME directory, edit
the amwas.amjacc.template.properties file by
adding the following properties to it:
com.tivoli.pd.as.jacc.DBRefresh=0
com.tivoli.pd.as.jacc.AuthTableRemoteMode=yes
com.tivoli.pd.as.rbpf.NoUncheckedRoles=true
This helps
when embedded Tivoli Access
Manager is re-configured
- Because embedded Tivoli Access
Manager is already configured, you can update the generated configuration
files with the above properties. For each WebSphere Application Server instance in the
ND (dmgr, NAs and servers), go to the profiles/NAME/etc/tam directory
and do the following.
For each file that ends in amjacc.properties,
add the 3 properties above:
com.tivoli.pd.as.jacc.DBRefresh=0
com.tivoli.pd.as.jacc.AuthTableRemoteMode=yes
com.tivoli.pd.as.rbpf.NoUncheckedRoles=true
For
each file that ends in pdperm.properties, update the appsvr-dbrefresh
property to be:
appsvr-dbrefresh=0
For
each file that ends in authztable.pdperm.properties, update the appsvr-mode
property to be:
appsvr-mode=remote
- Restart the cell.
After setting
domain realm to not trusted, global security settings cannot be used
If
you add a trusted domain realm and later on decide to set this realm
to "Not Trusted" from the administrative console, an empty inboundTrustedAuthenticationRealm
entry might be generated in the domain- security.xml file. This empty
inbound or outbound trusted realm definition in the domain-security.xml
file blocks this domain from using global security settings.
To
resolve this issue, do the following:
- Remove the current domain.
- Create a new domain.
- Do not add the incorrect realm as "Trusted".
When the
global security realm names are updated, the realm names of the application
security domain are also updated with the same realm names
In WebSphere Application Server
Version 8.0, you can configure a unique instance of a federated repository
at the domain level in a multiple security domain environment in addition
to having an instance at the global level. However, if the federated
repositories user registry is configured at the global level, or if
the realm names are changed at the global level after configuring
security domains, the realm names for all security domains using federated
repositories are also updated. This causes all of the domains using
federated repository to use the federated repository that is defined
at the global level.
To resolve this issue, update security
domains using federated repository with the original realm name after
you create federated repositories or change realm names at the global
level. The problem can be avoided if a federated repository at the
global level is configured before you configure a federated repository
in a security domain.
When the
session security feature is turned on, errors might occur when multiple
users login and then logout using the same user ID
When
the session security feature is turned on (which is the default in WebSphere Application Server
Version 8.0), and multiple sessions are using the same user ID, when
a user logs out of one session, another session might receive the
following error when a different user who has logged in with the same
user ID logs out:
SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:{<user>}
To resolve this issue, ensure that the previous
user is logged out before another user logs in using the same user
ID.
Avoid trouble: This issue might also occur in
some instances when the session security feature is not turned on.
If so, the resolution is the same: ensure that the previous user is
logged out before another user logs in using the same user ID.
gotcha