![]() |
|||
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
| ||
2.6 SecurityThe Java DMK 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. However, 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. New connector protocols were brought into Java DMK in version 5.1, with the integration of the JMX Remote API. These new connectors implement new security mechanisms. The following sections give an overview of the new security features that are provided through components of the Java DMK. 2.6.1 Security for Standard ConnectorsThree main aspects to connector security exist in Java DMK.
2.6.1.1 PrivacyThe 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 connectorAuthentication 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 connectorThe 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 authenticationThe 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 AuthorizationAuthorization 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 DelegationJava 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. 2.7 The SNMP ToolkitThe Java Dynamic Management Kit provides a toolkit for integrating SNMP management into a JMX architecture. SNMP management includes:
For more information regarding the SNMP toolkit, refer to the Java Dynamic Management Kit 5.1 Tools Reference Guide and the Java Dynamic Management Kit 5.1 Tutorial. 2.7.1 SNMP Packaging in Java DMK 5.1The Java packaging of the SNMP classes for Java DMK 5.1 has changed. In Java DMK 5.0, the SNMP classes were included in the SUNWjsnmp package, and they required a separate Java archive (JAR) file, jsnmpapi.jar. In Java DMK 5.1, the SNMP classes are packaged in the SUNWjdmk-runtime package, and require the same jdmkrt.jar JAR file as the rest of the current Java DMK classes. This new arrangement avoids the issue of potentially conflicting versions of the SUNWjsnmp package encountered under Java DMK 5.0. In addition, the SNMP API delivered with Java DMK 5.0 is now deprecated. The SNMP API in Java DMK 5.1 is effectively a completely new SNMP API, that introduces a more orthodox system of Java class naming. To use existing SNMP implementations that you created using Java DMK 5.0 alongside SNMP implementations created using Java DMK 5.1, you must translate the class names of the 5.0 implementations into the new format. How to perform this translation is explained in the Release Notes. To continue to use SNMP implementations you created using version 5.0 of Java DMK under version 5.1, a new JAR file called legacysnmp.jar is provided. You must add this new JAR to your classpath when running your Java DMK 5.0 SNMP implementations under Java DMK 5.1. All the examples of SNMP code given in the /examples/current/Snmp directory have already been translated to implement the new class naming system. However, should you require them, a full set of SNMP examples that follow the package naming from Java DMK 5.0 have been retained in the /examples/legacy/Snmp directory. 2.7.2 Developing an SNMP AgentAn SNMP agent is an application that responds to SNMP requests formulated as get, set, getnext, and getbulk operations on variables defined in a MIB. This behavior can be fully mapped onto the MBean server and MBean resources of a Java dynamic management agent, provided that those MBeans specifically implement the MIB. An SNMP agent can be issued either with or independently from an MBean server. There are two SNMP protocol adaptors: one that supports SNMPv1 and v2, and another introduced in the Java DMK 5.0 that supports SNMPv3 as well as the two previous versions. All features added in the Java DMK 5.0 therefore support SNMPv3 USM MIBs, providing user-based security, and scoped MIBs, that can be registered in the adaptor using a context name. The addition of multithread support in SNMP adaptors and timers in Java DMK 5.0 has also improved the performance of SNMP. The SNMP protocol adaptors respond to requests in SNMP and translate the requests into management operations on the specific MIB MBeans. The SNMP adaptors also send traps, the equivalent of a JMX agent notification, in response to SNMP events or errors. The SNMP protocol adaptors can manage an unlimited number of different MIBs. These MIBs can be loaded or unloaded dynamically, by registering and unregistering the corresponding MBeans. The adaptors attempt to respond to an SNMP request by accessing all loaded MIBs. However, MIBs are dynamic only through the agent application, and the SNMP protocol does not support requests for loading or unloading MIBs. One advantage of the dual JMX-SNMP agent is that MIBs can be loaded dynamically in response to network conditions, or even in response to SNMP requests. Other Java dynamic management applications can also access the MIB through its MBean interface. For example, the value of a MIB variable might be computed in another application and written by a call to the MBean setter. The SNMP protocol adaptors also send inform requests from an SNMP agent to an SNMP manager. The SNMP manager sends an inform response back to the SNMP agent. | ||
| ||
![]() |