Access problems after enabling security

 

What kind of error are you seeing?

1. Unable to access the administrative console or use wsadmin.sh after enabling security

2. Unable to access a Web page after enabling security

3. Authentication error accessing a Web page

4. Authorization error accessing a Web page

5. The client cannot access an enterprise bean after enabling security

6. The client never gets prompted when accessing a secured enterprise bean

7. Unable to stop an appserver, node manager, or node after enabling security

8. AccessControlException is reported in SystemOut.log.

9. After enabling single signon, I cannot log on to the administrative console.

10. Troubleshooting the security component.

11. Obtaining help from IBM.

 

Unable to access the administrative console or use wsadmin.sh after enabling security

• If you cannot access the administrative console, or view and update certain objects, look in the SystemOut log of the appserver which hosts the administrative console page for a related error message.

• You might not have authorized your ID for administrative tasks. This problem is indicated by errors such as...

  • RoleBasedAuth SECJ0305A: Role based authorization check failed for security name server/myUserId, accessId servername while invoking method getProcessType on resource Server and module Server.

  • ADMN0022E: Access denied for the getProcessType operation on Server MBean

  • WASX7246E: Cannot establish "SOAP" connection to host "hostname" because of an authentication failure. Please ensure that user and password are correct on the command line or in a properties file.

  To grant an ID administrative authority, from the administrative console, click...

  System Administration | Console Users

  ...and validate that the ID is a member. If it is not, add the ID with at least monitor access privileges, for read-only access.

• Check that the enable_trusted_application flag is set to true...

  Administrative Console | Security | Global Security | Custom Properties | Enable Trusted Application

 

Unable to access a Web page after enabling security

When secured resources are not accessible, probable causes include...

• Authentication errors - WAS security cannot identify the ID of the person or process. Symptoms of authentication errors include...

  • Login prompt displays again after an attempt to log in.

  • Allows three attempts to retry login.

  • Displays Error 401 message after three unsuccessful retries.

• Authorization errors - the security function has identified the requesting person or process as not authorized to access the secured resource. Symptoms of authorization errors include...

  • "You are not authorized to view this page" message is displayed.

  • "HTTP 403 Forbidden" error is also displayed.

• SSL errors - WAS security uses SSL technology internally to secure and encrypt its own communication, and incorrect configuration of the internal SSL settings can cause problems. Also you might have enabled SSL encryption for your own webapp or enterprise bean client traffic which, if configured incorrectly, can cause problems regardless of whether WAS security is enabled.

  SSL related problems are often indicated by error messages which contain a statement such as:

  ERROR: Could not get the initial context or unable to look up the starting context. Exiting.

  ...followed by...

  javax.net.ssl.SSLHandshakeException

 

The client cannot access an enterprise bean after enabling security

If client access to an enterprise bean fails after security is enabled...

• Review the steps for securing and granting access to resources.

• Browse the server JVM logs for errors relating to enterprise bean access and security. Look up any errors in the message table.

  Errors similar to...

  Authorization failed for /UNAUTHENTICATED while invoking resource securityName:/UNAUTHENTICATED;accessId:UNAUTHENTICATED not granted any of the required roles...

  ...indicate that...

  • An unprotected servlet or JSP file accessed a protected enterprise bean. When an unprotected servlet is accessed, the user is not prompted to log in and the servlet runs as UNAUTHENTICATED. When the servlet makes a call to an enterprise bean that is protected the servlet fails.

    To resolve this problem, secure the servlet that is accessing the protected enterprise bean. Make sure the runAs property for the servlet is set to an ID that can access the enterprise bean.

  • An unauthenticated Java client program is accessing an enterprise bean resource that is protected. This situation can happen if the file read by the sas.client.props properties file used by the client program does not have the securityEnabled flag set to true.

    To resolve this problem, make sure that the sas.client.props file on the client side has its securityEnabled flag set to true.

  Errors similar to...

  Authorization failed for valid_user while invoking resource securityName:/username;accessId:xxxxxx not granted any of the required roles roles

  ...indicate that a client attempted to access a secured enterprise bean resource, and the supplied user ID is not assigned the required roles for that enterprise bean.

  • Check that the required roles for the enterprise bean resource are accessed. View the required roles for the enterprise bean resource in the deployment descriptor of the Web resource.

  • Check the authorization table and make sure that the user or the group that the user belongs to is assigned one of the required roles. You can view the authorization table for the application that contains the enterprise bean resource using the administrative console.

If org.omg.CORBA.NO_PERMISSION exceptions occur when programmatically logging on to access a secured enterprise bean, an authentication exception has occurred on the server. Typically the CORBA exception is triggered by an underlying com.ibm.WebSphereSecurity.AuthenticationFailedException. To determine the actual cause of the authentication exception, examine the full trace stack...

1. Begin by viewing the text in the exception, following WSSecurityContext.acceptSecContext(), reason:. Typically, this text describes the failure without further analysis.

2. If this action does not describe the problem, look up the CORBA minor code.

   For example, the following exception indicates a CORBA minor code of 49424300.

   org.omg.CORBA.NO_PERMISSION: Caught WSSecurityContextException in WSSecurityContext.acceptSecContext(),
   reason: Major Code[0] Minor Code[0] Message[ Exception caught invoking authenticateBasicAuthData from SecurityServer for user jdoe.
   Reason: com.ibm.WebSphereSecurity.AuthenticationFailedException] minor code: 49424300 completed: No at com.ibm.ISecurityLocalObjectBaseL13Impl. PrincipalAuthFailReason.map_auth_fail_to_minor_code (PrincipalAuthFailReason.java:83)

   The explanation of this error in the CORBA minor code table reads:

   authentication failed error.

   The user ID or password supplied by the client program is probably invalid

If you get...

CORBA INITIALIZE exception with JSAS1477W: SECURITY CLIENT/SERVER CONFIGURATION MISMATCH error embedded

This indicates that the security configuration for the server differs from the client in some fundamental way. The full exception message lists the specific mismatches. For example, the following exception lists three errors

Exception received: org.omg.CORBA.INITIALIZE: JSAS1477W: SECURITY CLIENT/SERVER CONFIG MISMATCH:
The client security configuration (sas.client.props or outbound settings in GUI) does not support the server security configuration for the following reasons:
ERROR 1: JSAS0607E: The client requires SSL Confidentiality but the server does not support it.
ERROR 2: JSAS0610E: The server requires SSL Integrity but the client does not support it.
ERROR 3: JSAS0612E: The client requires client (e.g., userid/password or token), but the server does not support it.
minor code: 0
completed: No
at com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor.getConnectionKey(SecurityConnectionInterceptor.java:1770)

In general, resolving the problem requires a change to the security configuration of either the client or the server. To determine which configuration setting is involved, look at the text following the JSAS error message.

In these particular cases...

• In ERROR 1, the client is requiring SSL confidentiality but the server does not support SSL confidentiality. Resolve this mismatch in one of two ways. Either update the server to support SSL confidentiality or update the client so that it no longer requires it.

• In ERROR 2, the server requires SSL integrity but the client does not support SSL integrity. Resolve this mismatch in one of two ways. Either update the server to support SSL integrity or update the client so that it no longer requires it.

• In ERROR 3, the client requires client authentication through a user id and password, but the server does not support this type of client authentication. Either the client or the server needs to change the configuration. To change the client configuration, modify the SAS.CLIENT.PROPS file for a pure client or change the outbound configuration for the server in the Security GUI. To change the configuration for the target server, modify the inbound configuration in the Security GUI.

Similarly, an exception like org.omg.CORBA.INITIALIZE: JSAS0477W: SECURITY CLIENT/SERVER CONFIG MISMATCH: appearing on the server trying to service a client request indicates a security configuration mismatch between client and server. The steps for resolving the problem are the same as for the JSAS1477W exceptions previously described.

 

Client program never gets prompted when accessing secured enterprise bean

Even though it appears security is enabled and an enterprise bean is secured, it can happen that the client executes the remote method without prompting. If the remote method is protected, an authorization failure results. Otherwise, execute the method as an unauthenticated user.

Possible reasons for this problem include...

• The server with which you are communicating might not have security enabled. Check with the WAS administrator to ensure that the server security is enabled. Access the global security settings from within the Security section of the administrative console.

• The client does not have security enabled in the sas.client.props file. Edit the sas.client.props file to ensure the property com.ibm.CORBA.securityEnabled is set to true.

• The client does not have a ConfigURL specified. Verify that the property com.ibm.CORBA.ConfigURL is specified on the command line of the Java client, using the -D parameter.

• The specified ConfigURL has an invalid URL syntax, or the sas.client.props that is pointed to cannot be found. Verify that the com.ibm.CORBA.ConfigURL property is valid, for example, similar to the...

  file:/C:/WebSphere/AppServer/properties/sas.client.props

  ...file on Windows systems. Check the Java documentation for a description of URL formatting rules. Also, validate that the file exists at the specified path.

• The client configuration does not support message layer client authentication (user ID and password). Verify that the sas.client.props file has one of the following properties set to true:

  com.ibm.CSI.performClientAuthenticationSupported=true

  com.ibm.CSI.performClientAuthenticationRequired=true

• The server configuration does not support message layer client authentication (user ID and password). Check with the WAS administrator to verify that user ID and password authentication is specified for the inbound configuration of the server within the System Administration section of the administrative console administration tool.

 

Cannot stop an appserver, node manager, or node after enabling security

If you use command line utilities to stop WAS processes, apply additional parameters after enabling security to provide authentication and authorization information.

Use the ./stopServer.sh -help command to display the parameters to use.

Use the following command options after enabling security...

stopServer.sh hostname -username name -password password
stopNode.sh -username name -password password
stopManager.sh -username name -password password

 

After enabling single signon, cannot log on to the administrative console

This problem occurs when single signon is enabled, and you attempt to access the administrative console using the short name of the server, for example...

http://myserver:9090/admin

The server accepts your user ID and password, but returns you to the log on page instead of the administrative console.

To correct this problem, use the fully qualified host name of the server, for example...

http://myserver.mynetwork.companyname.com:9090/admin

 

See Also

Troubleshooting by component: What is not working?
Errors after enabling security

 

---