4.4 Security Mechanisms for Legacy Connectors

The legacy RMI and HTTP-based connectors implemented different security mechanisms to those implemented by the new RMI and JMXMP connectors. These legacy mechanisms are now deprecated, and are presented here for reasons of backwards compatibility.

4.4.1 Password Protection

Password-based protection restricts client access to agent applications. All HTTP-based communication provides login- and password- based authentication, as does the SNMP protocol adaptor.

Password protection can be used to associate managers with a set of privileges that determine access right to agents. The user is free to implement whatever access policy is needed on top of the password authentication mechanism. The SNMP protocols also provide password protection to agent applications. See 2.7.5 SNMPv1 and SNMPv2 Security and 2.7.6 SNMPv3 Security.

4.4.1.1 HTTP Connectors

Both HTTP and HTTPS connectors provide login and password-based authentication. The server component contains the list of allowed login identifiers and their passwords. Management applications must specify the login and password information in the address object when establishing a connection.

If the list of recognized clients is empty, the default behavior is to perform no authentication and grant access to all clients.

4.4.1.2 HTML Protocol Adaptor

Because the HTML protocol adaptor relies on HTTP messaging, it also implements password protection. The agent application specifies the list of allowed login identifiers and their passwords when creating the HTML adaptor. When password protection is enabled in HTML, the web browser usually displays a dialog box for users to enter their login and passwords.

In general, the security mechanisms of a protocol adaptor depend on the security features of the underlying protocol. The ability to use security mechanisms also depends on the functionality of the management console. If your web browser does not support the password dialog, you cannot access a password-protected HTML adaptor.

4.4.2 Context Checking

Whereas password protection grants all-or-nothing access, context checking enables the agent application to filter each management request individually. Context checking can be associated with password protection to provide multiple levels of security.

All management requests that arrive through a connector or HTML protocol adaptor are inspected by the agent application to determine if they are authorized. The management application filters requests based on the type of request, the MBean for which they are intended, or the values that are provided in the operation.

For example, context checking could allow an agent to implement a read-only policy that refuses attribute set operations, all operation invocation, and does not allow MBean registration or unregistration. A more selective filter could just ensure that the agent cannot be disconnected: it would disallow MBean unregistrations, stop operations, and invocations that contain null parameters, but only when applied to connector servers or protocol adaptor MBeans.

In addition, requests through connector clients can be filtered by an operation context field, which could be a password or any other identifying data. The context object is provided by the management application, and it will be sent to the connector server along with each request. The agent can verify this context and potentially reject the request if the context is considered invalid or inappropriate for the operation.

To make this context checking possible, the agent provides:

• Stackable MBean server objects – You can insert your own code to perform context checking and filtering between the communication component and the MBean server.

• Thread contexts – Your code can retrieve the remote application's context object that is stored in the thread object that handles the request. The context is an arbitrary object that your code can use to determine whether or not to allow the request.

Figure 4–2 Context Checking Using Stackable MBean Server Objects

In Figure 4–2, a context checker object has been inserted between the connector and the MBean server. Because a context checker object implements the MBeanServer interface, the connector interacts with it in exactly the same way as it did with the MBean server. This stacked object retains a reference to the real MBean server, to which it forwards all requests that are allowed. The context checker can also perform any other action, such as log all filtered requests and trigger a notification when an invalid request is received.

For security reasons, only the agent application can insert or remove stackable MBean server objects. This operation is not exposed to management applications, which cannot even detect whether requests are being filtered. However, the context checker might respond with an exception message that explains why a request was denied.

4.4.3 Data Encryption

The last link in the security chain is the integrity of data that is exchanged between agent and managers. Two issues need to be considered simultaneously:

Authentication:

Both agent and manager must be certain of the other's identity.

Privacy:

The data of a management request should be tamper-proof and undecipherable to nontrusted parties.

These issues are usually resolved by a combination of electronic signatures and data encryption. Again, the implementation is protocol-dependent.

The SNMP protocols also provide password protection to agent applications. See 2.7.5 SNMPv1 and SNMPv2 Security and 2.7.6 SNMPv3 Security.

The HTTPS connector enables Java managers to access a Java dynamic management agent using HTTP over Secure Socket Layer (SSL). SSL security is implemented in the Java 2 platform. The HTTP/SSL connector provides identity authentication based on the Challenge-Response Authentication Mechanism using MD5 (CRAM-MD5). The HTTPS connector server requires client identification by default.

The behavior of the HTTP/SSL connector is governed by the particular SSL implementation used in your applications. For data encryption, the default cipher suites of the SSL implementation are used. The SSL implementation must be compliant with the SSL Standard Extension API.

4.4.4 Secure Dynamic Loading

The m-let service downloads Java classes from arbitrary locations over the network. If you want to do so, you can enable code signing to ensure that only trusted classes can be downloaded. Secure loading relies on code signing.

On the Java 2 platform, the java.lang.SecurityManager property determines if code signing is enforced. When this security is enabled, again only class files signed by a trusted party will be loaded. On the Java 2 platform, users invoke the keytool, jarsigner, and policytool utilities to define their security policies.