What kind of error are you seeing?
I cannot access all or part of the administrative console or use the wsadmin tool after enabling security
Note: You will need to use the administrative console to complete the next two items. If you are having a problem accessing the administrative console, you will have to turn off security and restart the administrative console. To turn off security, enter the following command at the system command prompt:
wsadmin.sh -conntype NONEWhen the system command prompt reappears, enter:
securityoffRestart the Deployment Manager after you turn off security.
I cannot access a Web page after enabling security
When secured resources are not accessible, probable causes include:
On a Netscape browser:
On an Internet Explorer browser:
The client cannot access an enterprise bean after enabling security
If client access to an enterprise bean fails after security is enabled:
Errors similar to Authorization failed for /UNAUTHENTICATED while invoking resource securityName:/UNAUTHENTICATED;accessId:UNAUTHENTICATED not granted any of the required roles roles indicate that:
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.
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.
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:
A CORBA INITIALIZE exception with JSAS1477W: SECURITY CLIENT/SERVER CONFIGURATION MISMATCH error embedded, is received by client program from the server.
This error 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. For more detailed explanations and instructions, look in the message reference, by selecting the Reference view of the information center navigation and expanding Messages in the navigation tree.
In these particular cases:
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:
Cannot stop an application server, node manager, or node after enabling security
If you use command line utilities to stop WebSphere Application Server 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:
After enabling single signon, I cannot log on to the administrative console
This problem occurs when single signon (SSO) 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.mycompany.com:9090/admin.