2.6.1 Security for Standard Connectors

Three main aspects to connector security exist in Java DMK.

• Privacy, ensuring that attackers cannot see potentially sensitive information or operations over the connection, or inject new operations into it.

• Authentication, determining the identity of the client, and optionally of the server.

• Authorization, limiting the operations that a client can do based on its authenticated identity.

2.6.1.1 Privacy

The JMXMP connector negotiates security parameters during the initial handshake of a connection. In particular, the JMXMP connector can negotiate that the connection use transport layer security (TLS), which is basically the same as SSL 3.0. The server can require that only connections with TLS are accepted.

The SASL mechanisms DIGEST-MD5 and GSSAPI also provide connection privacy. See 2.6.1.2 Client Authentication in the JMXMP connector.

Privacy can be assured for the RMI connector by using an RMI socket factory to cause connections to be created using TLS. Java DMK 5.1 includes a socket factory that does this. The connector server imposes the socket factory, which is serialized into client stubs so that all clients automatically use it.

2.6.1.2 Client Authentication in the JMXMP connector

Authentication in the JMXMP connector is based on SASL. The handshake phase of a JMXMP connection can negotiate the SASL mechanism to use. The connector server can mandate a list of mechanisms, and reject connections that do not negotiate one of them. When a SASL mechanism successfully completes, it has authenticated a client identity, which is used to derive the Subject for the connection.

The SASL mechanisms DIGEST-MD5 and GSSAPI also provide connection privacy. For these mechanisms, a TLS connection is superfluous.

TLS also supports client authentication. The JMXMP connector can exploit this to accept only clients that can authenticate themselves, but in this case it does not currently support authorization based on the authenticated identity.

2.6.1.3 Client Authentication in the RMI connector

The RMI connector provides a simple way to add authentication. This mechanism is unambitious, but is powerful enough to build real solutions. However, where security is a major concern, users should consider using the JMXMP connector instead.

An RMI connector server can supply a JMXAuthenticator. This is a Java object with a method that takes an arbitrary credentials object and either returns a Java Subject if the credentials are accepted, or throws an exception if they are not. When a connection is made, if the authenticator accepts the credentials then subsequent operations over the connection are performed as the returned Subject. If the authenticator does not accept the credentials, then the connection is refused.

Challenge-response mechanisms can be introduced into this scheme by having the authenticator throw a specific exception containing a challenge. The client responds with new credentials that respond to the challenge.

A simple JMXAuthenticator is included in Java DMK 5.1. This simple authenticator is also included in Sun's implementation of the J2SE platform, version 1.5. The credentials consist of two strings, a role name and a clear text password. The authenticator consults a text file to validate the credentials. In this file, blank lines and lines beginning with # are ignored. Other lines must contain two blank-separated fields, again a role name and a clear text password. If the credentials match one of these lines then the connection is authenticated with a Subject containing the role name.

Obviously, where clear text passwords are involved, considerable caution is necessary. Connection privacy must be established if there is any danger of snooping. We talk of role names rather than user names so as not to encourage naive users to put real user passwords in the password file. A template file is included in the relevant examples that warns in comments that the file must be read-protected, that valuable passwords should not be used, and that in environments with strong security requirements this solution is inappropriate. We include this scheme for simple uses and for getting started, but expect that most deployed systems will prefer a system that does not use clear text passwords and that integrates into an existing security infrastructure.

Again, TLS also supports client authentication. Using the socket factory mentioned in 2.2 The MBean Server, the RMI connector can be configured to accept only clients that can authenticate themselves. However, in this case it does not currently support authorization based on the authenticated identity.

2.6.1.4 Server authentication

The Java DMK's security model is focused on ensuring that rogue clients cannot harm legitimate servers. However, a complete security solution must also ensure that, if a rogue server somehow substitutes itself for the legitimate server a client expects to find, the client is not compromised. For example, a rogue server could send bogus data to the client, or overload it, or receive sensitive information from it.

Server authentication can be done using TLS. The SASL mechanisms DIGEST-MD5 and GSSAPI also support server authentication.

2.6.1.5 Authorization

Authorization works in the same way with both connectors. The authentication step produces a Java Subject, which is a collection of Principals. The security mechanisms in the Java platform allow permissions to be associated with each Principal. When a remote operation is performed, the required permissions must be present, usually because they are associated with one of the authenticated Principals in the policy file.

A simplified authorization scheme is supported by Java DMK. This scheme is also used in Sun's implementation of the J2SE platform, version 1.5. In the simplified scheme, Java permissions are not involved. This removes the need to create policy files and to set a security manager, which are relatively complicated. Instead, there are just two access levels, readonly and readwrite.

The readwrite level gives access to all MBean server operations. The only exceptions are the creation of m-lets and the addition of URLs to existing m-lets. Since these operations could allow arbitrary code to be loaded into the MBean server and run, they are forbidden even at the readwrite level. When there is a security manager, running arbitrary downloaded code is acceptable because it will have no permissions by default. But the simplified scheme is specifically intended for the case where there is no security manager.

The readonly level gives access only to operations that do not change the state of the MBean server, such as reading attributes or querying existing MBeans.

A text file defines the access levels for different principals. In this file, blank lines and lines beginning with # are ignored. Other lines must contain two blank-separated fields. The first is an authenticated principal name, and the second is readonly or readwrite.

The mechanism that checks authorization in this simplified scheme is intended for simple uses and for getting started. It is expected that users with strong security requirements will eventually graduate to using the full Java security model, with permissions, policy files, and a security manager.

2.6.1.6 Subject Delegation

Java DMK 5.1 provides for subject delegation. The idea is that a single connection authenticated with a trusted identity, the delegate, can perform operations on behalf of other identities, without having to authenticate those identities explicitly or to establish a different connection per identity.

The delegate must have a specific permission to perform operations on behalf of each identity it assumes. This permission can be specified with a wildcard, to allow delegation from a set of identities. Unlike most permission checks, this one happens even if there is no Java security manager.