Security

The Java Dynamic Management Kit 4.1 provides certain levels of security. The following sections provide an overview of the security services provided with the Java Dynamic Management Kit.

Connectors and Protocol Adaptors

The HTML protocol adaptor, the HTTP/SSL connector and the HTTP/TCP connector all provide login/password authentication. In this authentication scheme, the client object and the server object contain authentication information. The server side object contains an array of objects that contains authentication information for all known clients. When a client attempts to login, the login/password object that it sends is compared with the array to see whether the client is in the list of permitted clients. If the list of permitted clients is null, no client authentication is performed by the protocol adaptor; access is granted to all clients.

HTML

The HTML protocol adaptor is an HTML server that enables web browsers to access a Java Dynamic Management Kit agent through the HTTP communications protocol. When an HTML protocol adaptor is instantiated, it creates a TCP/IP socket and waits for incoming requests. By default, the HTML adaptor listens for incoming requests on port 8082. The HTML protocol adaptor provides login/password authentication.

The HTML protocol adaptor is provided as a tool for debugging and speeding up the development of agents. As such, it has certain limitations; for example it does not display complex types or multi-dimensional arrays.

Security on the manager side is handled by the HTML browser. On the server side, you need to provide a list of agents for which you want to provide security for, in order for those agents to be run securely.

HTTP/SSL

The HTTP/SSL connector enables Java managers to access a Java Dynamic Management Kit agent using HTTP over SSL (Secure Sockets Layer). SSL security is implemented in Java 2. It also allows these management applications to access an agent across proxy servers. By default, the HTTP/SSL connector listens for incoming requests on port 8084. The HTTP/SSL connector provides login/password authentication based on 'CRAM-MD5' (Challenge-Response Authentication Mechanism using MD5). The HTTP/SSL adaptor server requires client authentication by default.

The behavior of the HTTP/SSL connector is governed by the particular SSL implementation used in your applications. The cipher suites that are enabled are the defaults of the SSL implementation. The SSL implementation must be compliant with the SSL Standard Extension API.

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

HTTP/TCP

The HTTP/TCP connector enables Java managers to access a Java Dynamic Management Kit agent using HTTP over a TCP/IP connection. It also allows these management applications to access an agent across proxy servers. By default, the HTTP/TCP adaptor listens for incoming requests on port 8081. The HTTP/TCP connector provides login/password authentication.

SNMP

The Java Dynamic Management Kit allows for two levels of security in SNMP:

• Community-based security via Access Control Lists.

• PDU encryption/filtering via the Snmp PDU factory.

The default implementation of the Snmp PDU factory does not provide any security. It only provides standard BER encoding/decoding of SNMP PDUs. However, you may replace the default Snmp PDU factory and implement encryption/filtering, based upon several factors:

• The host or community of the SNMP manager in a message before it is decoded.

• The type or contents of a request after it is decoded.

• Some encryption of the raw data.

Security on the agent side

On the agent side, the Java Dynamic Management Kit default implementation provides community-based security over Access Control List (ACL) files.

The ACL file is the default access control mechanism in the SNMP protocol adaptor. However, you may replace this default implementation with your own specification. For example, if your agent runs on a device with no file system, you could implement a mechanism which does not rely on the jdmk.acl file, by registering your own custom implementation with the SNMP protocol adaptor.

As outlined above, PDU encryption is not provided by default. However, you may provide any kind of security via PDU encryption/filtering by registering your own implementation of the Snmp PDU factory with the SNMP protocol adaptor. An example of such a secure agent is provided with Java Dynamic Management Kit 4.1.

Security on the manager side

On the manager side, a community-string can be specified via SnmpParameters upon the emission of a request. PDU encryption/decryption can also be implemented by registering your own implementation of the Snmp PDU factory, associated with either:

• The SNMP Peer, which is used for:

  • Encoding PDU requests.

  • Decoding received PDU responses.

• The SNMP Event Report Dispatcher, which is used for:

  • Decoding received PDU traps or inform requests.

  • Encoding PDU inform responses.

Mlet

As outlined in "Mlet", the Mlet service is a class and library loading service which enables agents to obtain MBeans remotely. An agent does this by loading a remote text file that contains information about the MBeans to be obtained. The location of the text file is specified by a URL and the information about each MBean to be obtained is specified in a single instance of a tag, called the MLET tag.

Mlet security

The Java Dynamic Management Kit 4.1 offers security within the Mlet service. Security differs between the JDK 1.1x and Java 2 Java runtime environments. This is explained in the following sections.

JDK 1.1x

The default behavior of the Java Virtual Machine forbids you to download classes and native libraries across the network. For secure operation of the Mlet service, the Java Dynamic Management Kit provides a simple implementation of a security manager, called com.sun.jdmk.AgentSecurityManager, which accepts incoming libraries. This security manager extends the java.lang.SecurityManager interface and you must install it as the default security manager in the Java virtual machine on which the agent is running.

Code signing must also be employed to ensure the secure operation of class and library loading services. The Mlet service allows you to load .jar files that have been signed using the javakey utility. The machine where the agent is running must have the signer's certificate in its keystore. Otherwise, the service will be unable to load .jar files signed by that particular signer. The class loader must have access to the signer's certificate, that is, the signer's certificate must be stored in the keystore on the machine on which the agent is running.

Registering the Mlet Service with the MBean server

The Mlet service is registered in one of the following ways:

• Security Mode.

  • The security mode of the Mlet Service is specified at instantiation time through a parameter passed in the Mlet constructor.

  • If no secure parameter is specified, the service assumes insecure mode to be enabled.

Java 2

Code signing must also be employed to ensure the secure operation of the class and library loading services. The Mlet service allows you to load .jar files that have been signed using the jarsigner utility. The machine where the agent is running must have the signer's certificate in its keystore. Otherwise, the service will be unable to load .jar files signed by that signer. The class loader must have access to the signer's certificate, that is, the signer's certificate must be stored in the keystore on the machine on which the agent is running.

As well as jarsigner, the java.lang.SecurityManager provides the keytool and Policy Tool utilities. You can use keytool to manage your keystore and Policy Tool to create and modify the external policy configuration files that define your installation's security policy.