Security

The Java Dynamic Management Kit provides several security mechanisms to protect your agent applications. As is always the case, simple security that enforces management privileges is relatively easy to implement; full security against mischievous attacks requires a more sophisticated implementation and deployment scheme. However, in all cases, the security mechanisms preserve the Java Dynamic Management architecture and management model.

The following sections give an overview of the security features provided through components of the Java Dynamic Management Kit.

Password Protection

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

Password protection can be used to associate managers with a set of privileges which determine access right to agents. The user is free to implement whatever access policy is needed on top of the password authentication mechanism.

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 password. 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, no authentication is performed and access is granted to all clients; this is the default behavior.

HTML Protocol Adaptor

Since 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 password when creating the HTML adaptor. When password protection in enabled in HTML, the web browser usually displays a dialog box for users to enter their login and password.

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

SNMP Access Control

SNMP defines an access control mechanism similar to password authentication. Lists of authorized manager hostnames are defined in an access control list (ACL) stored in an ACL file on the agent side. There are no passwords, but logical community names may be associated with authorized managers to define sets of allowed operations.

The SNMP adaptor will perform access control if an ACL file is defined. Because SNMP is a connectionless protocol, the manager host and community are verified with every incoming request. By default, the file is not loaded and any SNMP manager may send requests.

The ACL file is the default access control mechanism in the SNMP protocol adaptor. However, you may replace this default implementation with your own mechanism. For example, if your agent runs on a device with no file system, you could implement access control lists through a simple Java class.

Context Checking

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

All management requests that arrive through a connector or protocol adaptor may be inspected by the agent application to determine if they are allowed. The management application may filter 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 which refuses attribute set operations, all operation invocation, and doesn't allow MBean registration or deregistration. A more selective filter could just insure that the agent cannot be disconnected: it would disallow MBean deregistrations, 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 may 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 which is stored in the thread object which handles the request. The context is an arbitrary object that your code can use to determine whether or not to allow the request.

Figure 2-6 Context Checking Using Stackable MBean Server Objects

In the figure above, 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 will retain a reference to the real MBean server, to which it will forward all requests that are allowed. The context checker may 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 may insert or remove stackable MBean server objects. This operation is not exposed to management applications, who cannot even know if requests are being filtered. However, the context checker may choose to respond with an exception whose message explains why a request was denied.

Data Encryption

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

• Identification - 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 untrusted parties.

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

SNMP Encoding

SNMP requests follow standardized encoding rules for translating management operations into data packets. At the communication level, an SNMP request is represented by an array of bytes in a UDP protocol packet. The SNMP components in the Java Dynamic Management Kit provide access to the byte encoding of these packets.

Your applications may customize the encoding and decoding of SNMP requests:

• On the manager side, after the request is translated into bytes, your encoding may add signature strings and then perform encryption.

• On the agent side, the bytes may be decoded and the signature can be verified before the bytes are translated into the SNMP request.

  A decoded SNMP request contains the manager's hostname and community string, the operation, the target object, and any values to be written. Like the context checking mechanism, you may insert code to filter requests based on any of these criteria.

In order to implement a secure SNMP management solution, you need to coordinate the security policy between the manager encoding and the agent decoding. However, SNMP request filtering may be performed unilaterally by the agent, to allow requests from unknown managers yet still be able to reject unauthorized operations.

HTTP/SSL

The HTTPS connector enables Java managers to access a Java Dynamic Management agent using HTTP over SSL (Secure Socket Layer). SSL security is implemented in the Java 2 platform. The HTTP/SSL connector provides identity authentication based on 'CRAM-MD5' (Challenge-Response Authentication Mechanism using 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.

The Java Dynamic Management Kit is compliant with the Java Secure Socket Extension 1.0 (JSSE) API. JSSE provides an API framework and reference implementation for security protocols.

Secure Dynamic Loading

The m-let service downloads Java classes from arbitrary locations over the network. If you wish to do so, you may enable code signing to insure that only trusted classes may be downloaded. Secure loading relies on code signing which differs between the JDK 1.1 and Java 2 platforms.

On a JDK 1.1 platform, the m-let service may be instantiated in secure mode to enforce code signing. The m-let service will then only load .jar files that have been signed by a trusted party using the javakey utility. The machine where the agent is running must have the signer's certificate in its keystore.

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.