Administrative Credentials for Application Server 8.xAuthor: Kedar Mhaswade. All comments to Kedar.Mhaswade@Sun.Com This chapter deals with administrative credentials for application server. As you know, the basic boundary that is protected by the administrator for application server is the domain. An application server administrator manages one or domains, each of which can have distinct administrative credentials. By managing a domain an administrator effectively manages various resources like server instances, server clusters, libraries etc. that are required by the enterprise Java applications. Most of this text applies to both the Platform Edition and Enterprise Edition of application server software. 1. Application Server Domain: Administrative Credentials and their Use 1.1 The Background The application server domain (or just the domain) is your entry point into using the application server. A domain provides the essential runtime required for administration. Each domain has its own configuration stored in a set of defined files on disk. These files are stored in the config subfolder inside the domain folder. The config folder is secured by providing read-only access exclusively to the administrative user. Note that this is the operating system user that is being referred to. Usually an application server administrator is same as the system administrator of the machine where the application server software is installed (this is not required however). When that is not the case, the application server administrator should make sure that there are enough privileges available so that a domain could be created on a particular system (machine). It is important to note that it is not required that the user who installs the application server software is the same as the user who creates administrative domains on a given system. This is one of the strengths of Sun's application server software. Usually a system administrator installs the application server software using a suitable mechanism, creates operating system users with sufficient privileges and then these users create the domains with their own configurations. Thus domains are administrative namespaces utilizing the same binaries installed elsewhere. All domains are mutually exclusive sandboxes capable of residing on a given system, provided that enough physical resources are available. When an operating system user creates a domain, this user is the owner of this domain. To be precise, this user is the owner of the domain admin server process, process being the well-known operating system artifact. Thus, invoking the asadmin create-domain command is how a user creates the domain. If you carefully observe the behavior of this command, following is evident:
The admin user name, admin password and master password together define what is called as the admin 3-tuple. Anyone who knows the admin-3-tuple is an administrator for the application server domain. [Note that the cases of hardware accelerator, crypto card passwords etc. for additional security have not been considered.] 1.2 Admin Operations and Use of Admin Credentials An Admin Operation is defined as any operation that results in changing the domain's configuration in some defined way. There are various ways in which an admin operation can be performed. In other words, there are various entry points into the domain administration. Important thing to note is that all of the control flow through all these entry points must satisfy a security constraint defined by the admin user name and admin password. Thus the admin user name and password represent the single sentinel that guards all of administrative access.
________________ _____________________________________________________
|asadmin/NetBeans|--HTTP/S------|----| |--------------|asadmin-web-app| |
|________________| | | A | |
_______________ | | D | |
| Pure JMX/AMX|--JMX/SSL------|----| M |--------------|system-jmx-connector-server| |
|_______________| | | I | |
_____________ | | N | |
| Browser |----HTTP/S-------|----| R |--------------|admingui-web-app| |
|_____________| | | E | |
________________ | | A | |
|JSR-77 Client |--RMI/IIOP/S----|----| L |--------------|MEJB Implementation| |
|________________| | | M | |
|_____________________________________________________|
Domain Admin Server Runtime
Figure 1: Schematic showing admin operations
The admin user name and admin password is required by what is called an admin security realm. This is a security realm provided exclusively for administrative access. The realm implementation decides whether the given credentials (on each admin request) are sufficient to carry out the given request. If the realm rejects a particular user name and password, the entire operation fails and domain configuration is protected. This is the very reason why the Domain Admin Server should be running in order to perform an administrative operation. The admin realm is realized as follows:
The true security can only be achieved when all these remote connections have transport layer security using SSL. In Platform Edition, the admin user name and password might be sent in clear over the network, whereas in Enterprise Edition, care is taken such that only secure connections are attempted in the case of asadmin and browser clients (this is the default behavior). In addition to the above, note that node-agents and server instances communicate with the DAS for internal application server tasks, using the same admin user name and password. 1.3 Admin Security Realm and Multiple Admin Users and Groups The default admin security realm implementation is called the FileRealm. When a domain is created, following two things happen in this regard:
Thus, out-of-the-box, the admin user created is authenticated against the file created this way. It is possible that an application server administrator for a large enterprise chooses to authenticate against a corporate LDAP using the LDAPRelam. The way to do this is mapping admin-realm onto an appropriately configured LDAP. An administrative user can add or delete other users from the asadmin group. All the users in the group asadmin have identical privileges and it is impossible to distinguish one administrative user from another unless auditing is enabled. In other words, there is no role-based administration in application server for this release. The asadmin commands that modify the users in admin-realm, while using the FileRealm are:
There are Admin GUI (Browser based) equivalents for the same. Refer to admin reference and manpages for the exact details of these operations. Note the following regarding these commands:
Like it is said above, an administrator who creates a domain has to provide and remember the admin user name, admin password and master password for a domain. Really speaking, the master password is a misnomer, it is the SSL store password with which the keystore and truststore for the domain are locked. When a domain is created, a self-signed certificate is created (anew every single time). This certificate (nicknamed s1as) is stored in X509 format in the trust-store in config subfolder of domain folder. The master password is the password which protects this store and the keystore. To enhance the developer experience, the developers or the users of Platform Edition are shielded from master password. In case of Platform Edition, the master password is defaulted to "changeit" and user does not have to provide it. In fact, the developers can completely be agnostic that there is such a password. Enterprise Administrators on the other hand will be prompted for master password while creating the domain in Enterprise Edition. For Platform Edition, JKS (Java KeyStore) and relevant tools (e.g. JDK keytool) are used, whereas for Enterprise Edition NSS (Network Security Services) and relevant tools (e.g. certutil) are used. When you start a particular domain and/or node-agent, the security subsystem needs to be initialized with the certificates and keys and in order to unlock the stores, the domain and/or node-agent startup needs access to an identical master password. Note that for Enterprise Edition, all the node-agents in a given domain must have the same master password as that of the domain itself. It is also important to note that master password is never put on the network. It has to be provided every time it is required by either node-agent startup or the domain startup process. There is a way to store the master password on disk in an encrypted manner and the way to realize it is by using --savemasterpassword flags on create-domain and create-node-agent commands. It is also available on the change-master-password command. The idea of --savemasterpassword is that, when this option is used at the time of creation of domain and node-agent, the startup of these entities will read it from there instead of prompting the users for it.
It is possible to get confused with the relationship between admin user name in the admin 3-tuple and the operating system user created by the system administrator. Simply put, there is no relationship between these two. These are two independent entities. From the application server standpoint, any operating system user who has access to the admin user name and password (and master password) is the administrator. Note the following in this regard:
It is obvious that administrators would want to change the admin password and master password from time to time. There are supported ways to perform these operations. One care to exercise in this regard is to plan the activity of changing the passwords. Note the following in this regard:
4.1 The Case of Forgotten Passwords It is possible that administrators/developers forget the admin user name, admin password or master password for a domain. In such situation, the administrator cannot really manage the domain. Hence you should be careful with the credentials. If you have compromised the security inadvertently, you should consider abandoning the domain to reduce the damage further. In some extreme situations however, it is desirable to recover credentials so that the administrator knowingly wants to recover the credentials by undertaking the associated risk. The following text pertains to recovery of credentials under such situations and constraints. Since it is evident from the above that admin security revolves around the admin-realm, it is the configuration of admin-realm that dictates the ability to recover the admin credentials. The following applies to recoverability of admin credentials, if the admin-realm is configured to be the default FileRealm. If you have configured it to be any other realm, it is up to you to recover the credentials. Note that this file admin-keyfile is readable only by the owner of the domain. Thus, you will be able to view the contents of this file if you've created this domain. 4.1.1 Recovering admin user name Follow these steps:
4.1.2 Recovering admin password Assuming that you either know or have recovered the admin user name, following is a workaround to recover the admin password for the domain. Note that merely looking the contents of the admin-keyfile won't reveal the password in clear. This file only has a secure one-way hash of the admin password. Assume that the admin user name is "admin" and domain name is "mydomain" for the domain whose admin password is forgotten.
The admin passwords for both mydomain and foo are now the same. You can now safely delete the domain foo. In reality, this is not the recovery of the old password, but changing it indirectly. 4.1.3 Recovering master password It is not possible to recover or indirectly modify the master password. If you have forgotten the master password, you cannot start or restart a given domain or node-agent(s). The domain will need to be recreated. Like any other secure system, the application server does not store the administrative credentials. in clear text anytime. Here is how the domain stores the passwords:
6. Admin Credentials. and asadmin Commands All the remote asadmin commands do their job by communicating with a running Domain Admin Server (DAS). Examples of remote asadmin commands are: deploy, create-jdbc-resource etc. Other kind of asadmin commands is local. These commands do not communicate with the DAS All remote asadmin commands need admin user name, admin password, DAS's admin port and DAS's host name. These commands also need to know if the admin http port needs plain text connection or SSL. Out-of-the-box, Platform Edition has all the domains with admin port listening for plain text connections, whereas Enterprise Edition has all the domains with admin port listening for secure connections. These options are named:
Remote commands is a misnomer, really speaking. It does not really mean that for these commands, the asadmin script and DAS have to be running on different machines. All it means is that these commands need a running DAS (with compatible versions) defined by the above parameters. While specifying the admin user name and admin password on asadmin commands, following should be noted:
7. Advanced Topic: Password Aliasing Please see the document: aliased passwords. In addition to the above credentials, there are other credentials that an application server domain administrator should be aware of. Here is a brief account of those:
Here are some of the best practices to exercise while using application server domain credentials:
0. Introduction |