These security considerations include the following:
Access to the Oracle Java Web Console – Whether you can connect to the console through a browser.
Access to applications – Whether you can see a particular application in the Oracle Java Web Console's launch page.
Application permissions – The levels of permissions that you must have to run parts or all of an application.
Application access to remote systems – How security credentials relate to remote systems.
Internal passwords used in the console - Changing the default passwords that are used internally in the console, starting with the Solaris 10 11/06 release.
Permissions to the web console launcher application are usually open so that any valid user can log in. However, you can restrict access to the console by specifying the rights in the authTypes tag in the web console's app.xml file, which is located in the /usr/share/webconsole/webapps/console/WEB-INF directory. For more information, see Specifying Authorizations With the authTypes Tag.
Some system configurations are set up to be very secure, so that attempts to connect from a remote system to the URLs of the console or registered applications are refused. If your system is configured to prevent remote access, when you try to access the console as https://hostname.domain:6789, your browser displays a message such as:
Connect to hostname.domain:6789 failed (Connection refused)
The SMF profile in effect on the system might be restricting access. See SMF Profiles for more information about profiles. See Enabling Remote Access to the Oracle Java Web Console for a procedure to allow access to the console from remote systems.
After you successfully log in to the web console, you might not automatically have access to all of the applications that are registered in that console. Typically, applications are installed so that all users can see them in the console launch page. As an administrator, you can grant and restrict access to applications.
To restrict access to an application, specify the rights in the authTypes tag, which is in the application's app.xml file. You can find the application's app.xml file in the installation-location/WEB-INF/ subdirectory. Typically, this directory would be located in /usr/share/webconsole/webapps/ app-context-name/WEB-INF.
If the application files are not in the usual location, you can locate the files by using the following command:
wcadmin list --detail -a
This command lists each deployed application, showing when it was deployed and the path to the application's base directory. The app.xml file is located in the subdirectory WEB-INF within the base directory.
For more information, see Specifying Authorizations With the authTypes Tag.
If you can see an application's link on the Oracle Java Web Console's launch page, you can run that application. However, an application might make additional authorization checks based upon the authenticated user or role identity. These checks are not controlled by the authTypes tag, but are explicitly coded into the application itself. For example, an application might grant read access to all authenticated users, but restrict update access to a few users or a few roles.
Having all the appropriate credentials does not guarantee that you can use an application to manage every system within the application's scope of operation. Each system that you administer by using the Oracle Java Web Console application has its own security domain. Having read-and-write permissions on the web console system does not guarantee that those credentials are automatically sufficient to administer any other remote system.
In general, access to remote systems depends on how the security is implemented in the web application. Typically, web applications make calls to agents that perform actions on behalf of the applications. These applications must be authenticated by the agents based on their web console credentials and the credentials by which they are known on the agent system. Depending upon how this agent authentication is done, an authorization check might also be made on the agent itself, based upon this authenticated identity.
For example, in web applications that use remote WBEM agents, authentication typically uses the user or role identity that initially authenticated to the Oracle Java Web Console. If this authentication fails on that agent system, access to that system is denied in the web application. If authentication succeeds on that agent system, access might still be denied if the agent makes an access control check and denies access there. Most applications are written so that the authentication and authorization checks on the agent never fail if you have been successfully authenticated on the web console and assumed the correct role.
Starting with the Solaris 10 11/06 release, the Oracle Java Web Console uses several password-protected internal user names to perform administrative tasks on the underlying web server, and to encrypt key store and trust store files. The passwords are set to initial values to enable the console to be installed. To reduce the possibility of a security breach, you should change the passwords after installation. See Changing Internal Passwords for Oracle Java Web Console