Java Web Console Reference Information
This reference section includes the following topics:
Java Web Console Security Considerations
There are several security considerations to keep in mind when you use applications
that are in the Java Web Console.
These security considerations include the following:
Access to the 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 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.
Access to the Java Web Console
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 Java Web Console for a procedure to allow
access to the console from remote systems.
Access to Applications in the Java Web Console
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.
Application Privileges
If you can see an application's link on the 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.
Application Access to Remote Systems
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 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 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.
Internal Passwords Used in the Console
Starting with the Solaris 10 11/06 release, the 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 Java Web Console
Specifying Authorizations With the authTypes Tag
While most system management web applications do not require any administrator intervention to use
the authTypes tag, in some cases, you might need to change the values
of this tag. The authTypes tag contains a set of information that describes
the level of authorization that is required for a user to view an
application in the Java Web Console. The web console determines if a user
is authorized to see a particular application, based on the authorization requirements in
the application's app.xml file. Each application can determine whether a user must have
proper authorization to run the application. This determination might be made as part
of the application installation process. Or, you might need to supply the information,
depending on your own security requirements. The product documentation for the application should contain
the information that is necessary to determine whether you need to specify a
particular permission.
You can nest several authType tags within the authTypes tag.
The authTypes tag must contain at least one authType tag that provides
the following necessary information:
In the following example, the authType tag has one attribute, name. The required
name attribute is the name of the authorization service type. Different authorization types might
require different values for the classType and permissionParam tags.
<authTypes>
<authType name="SolarisRbac">
<classType>
com.sun.management.solaris.RbacPermission
</classType>
<permissionParam name="permission">
solaris.admin.serialmgr.read
</permissionParam>
</authType>
</authTypes>The following table shows the tags that can be nested within an
authType tag
Table 3-1 Nested authType Tags
Tag |
Attribute |
Description |
|---|
classType |
|
The Permission subclass name. This tag is a required tag. |
permissionParam |
name |
The parameters that
are required to create an instance of the class specified by classType. |
The authTypes tag and nested authType tags are required elements in the app.xml
file. If you want to register an application that is available to anyone,
specify the authType tag with no content, as shown in the following
example.
<authTypes>
<authType name="">
<classType></classType>
<permissionParam name=""></permissionParam>
</authType>
</authTypes>
Enabling Remote Access to the Java Web Console
If you can only connect to the console by logging into the
system that is running the console, and then using the URL https://localhost:6789, the system
is using a configuration that prevents remote access. Starting with the Solaris 10
11/06 release, you can enable remote access only to the console, while leaving
the other access restrictions in place, by using the following procedure:
How to Enable Remote Access to the Java Web Console
- Become superuser or assume an equivalent role on the system where the console
is running.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
- Set a property to allow the console server to respond to network requests
and restart the console server.
# svccfg -s svc:/system/webconsole setprop options/tcp_listen = true
# smcwebserver restart
Disabling Remote Access to the Java Web Console
You can prevent users from connecting to the console from remote systems. Starting
with the Solaris 10 11/06 release, you can disable remote access only to
the console, while leaving the other access permissions in place, by using the
following procedure:
How to Disable Remote Access to the Java Web Console
- Become superuser or assume an equivalent role on the system where the console
is running.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
- Set a property to prevent the console server from responding to network requests,
and restart the console server.
# svccfg -s svc:/system/webconsole setprop options/tcp_listen = false
# smcwebserver restart
After the restart the console now only responds to a browser on
the same system as the console server process. You cannot use a
proxy in the browser, only a direct connection. You can also use
the https://localhost:6789/ URL to access the console.
Changing Internal Passwords for Java Web Console
Starting with the Solaris 10 11/06 release, the console uses some internal user
names and passwords. The console's internal user names and passwords are used only
by the console framework, and are never used directly by a user or
system administrator. However, if the passwords were known, a malicious user could potentially
interfere with the console applications. To reduce the possibility of such a security
breach, you should change the passwords. You do not need to remember the
new passwords, because the software uses them invisibly.
How to Change the Console's Internal Passwords
The passwords are known as the administrative password, keystore password, and truststore password.
You do not need to know the default initial values in order to
change the passwords. This procedure explains how to change all three passwords with
separate commands.
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
- Change the administrative password.
# wcadmin password -a
You are prompted to enter the new password twice. The password should be
8 to 32 characters.
- Change the key store password.
# wcadmin password -k
You are prompted to enter the new password twice. The password should be
8 to 32 characters.
- Change the trust store password.
# wcadmin password -t
You are prompted to enter the new password twice. The password should be
8 to 32 characters.
