Java Dynamic Management Kit 3.2 Programming Guide
[ Previous ][ Fast Back ]Chapter 5. Adaptors[ Fast Forward ][ Next ]

Access Control

The Java Dynamic Management Kit provides mechanisms for controlling access by a manager to an agent. The access control methods available depend on the adaptor used.

The Java Dynamic Management Kit does not provide access control for the RMI adaptor or the IIOP adaptor.

Authentication

The HTTP/TCP, HTTP/UDP, HTTP/SSL and HTML adaptors 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 if the client is in the list of permitted clients. If the list of permitted clients is null, no client authentication is performed by the adaptor; access is granted to all clients.

The HTTP/TCP, HTTP/UDP, and HTTP/SSL adaptors provide login/password authentication based on `CRAM-MD5 (Challenge-Response Authentication Mechanism using MD5)' as specified in RFC2104 and RFC2195.

The HTML adaptor provides login/password authentication, as specified in the `Basic Authentication Scheme,' in RFC1945.

Default Behavior

The default behavior for the HTTP/TCP, HTTP/UDP, HTTP/SSL, and HTML adaptors is not to require authentication information.

Adding an Adaptor Supporting Authentication

To add an adaptor to an agent, create an instance of the Java class that implements the adaptor. The classes are shown on Adding an Adaptor to an Agent. To add login/password authentication, create an instance of the AuthInfo class and add this to the adaptor object. Example 5-1 shows the instantiation of an HTTP/TCP adaptor and authentication information objects for two users. The second authentication information object is then removed.

Example 5-1. Adding an Adaptor Supporting Authentication

// Add the HTTP adaptor service.
//
String httpClassName = "com.sun.jaw.impl.adaptor.http.AdaptorServerImpl";
String httpName = new String(domain + ":" + ServiceName.ADAPTOR +
         ".protocol=http,port=8081");
com.sun.jaw.impl.adaptor.http.AdaptorServerImpl http =
          (com.sun.jaw.impl.adaptor.http.AdaptorServerImpl)
          cmf.newObject(httpClassName, httpName);
...
// Initialize the server authentication information.
//
AuthInfo ai1 = new AuthInfo("username1", "password1");
http.addUserAuthenticationInfo(ai1);
AuthInfo ai2 = new AuthInfo("username2", password2");
http.addUserAuthenticationInfo(ai2);
...
// Remove the user with login "username2" from the server.
//
http.removeUserAuthenticationInfo(ai2);

Access Control Using an ACL file

For the SNMP adaptor, the Java Dynamic Management Kit provides access control based on the IP address of the host or proxy machine of the manager. Information on each machine and the access rights it has is stored in an ACL file.

Enabling Access Control for the SNMP Adaptor

To enable access control for the SNMP adaptor, ensure that an ACL file exists when any agents are started. The ACL file must be named jaw.acl and must be located in the configuration directory. If the configuration directory is not found in one of the default directories shown in the table, the framework/adaptor uses the CLASSPATH environment variable (see Appendix B) to determine the correct location.

Operating Environment

Configuration Directory

Solaris

installDir/SUNWconn/jaw/etc/conf/

Windows NT

installDir\SUNWconn\jaw\etc\conf\

If an ACL file exists, the access rights it defines apply to all managers or proxy servers that access agents through the SNMP adaptor. The machine of the agent has read-write access. If this file does not exist when the agents are started, all managers are granted access to the agents through the SNMP adaptor.

The format of an ACL file is defined in ACL File Format. A template file named template.acl is provided in the configuration directory. Copy this file to jaw.acl and edit it to define the access control you require.

ACL File Format

An ACL file contains the following groups of configuration variables:

Format of the acl Variable Group

Example 5-2. Format of the acl Configuration Variable Group
acl = {
   list1
   list2
     ...
   listn
}

The acl group contains one or more lists of configuration variables. The format of each list is defined in Example 5-3.

Example 5-3. Format of a List in the acl Group
{
   communities = communityList
   access = accessCode
   managers = hostList
}

The meaning of each item is:

communities = communityList

This item specifies the SNMP community names, where communityList is a list of SNMP community names. Each community name in the list must be separated from the one that precedes it by a comma.

access = accessCode

This item specifies the access rights to be granted to all managers running on the machines specified in the managers item. The accessCode keyword is one of the following:

read-write

The managers are allowed to get and set properties of m-beans.

read-only

The managers are allowed only to get properties of m-beans.

managers = hostList

This item specifies the host machines of the managers to be granted the access rights specified in the access item. The hostList item is a list of hosts. Each host in hostList can be expressed as any one of the following:

Each host in the list must be separated from the one that precedes it by a comma.


Note - To distinguish between IP addresses and subnet masks in an ACL file, each integer in a subnet mask is separated by an exclamation mark instead of a dot.


Format of the trap Variable Group

The trap group specifies the hosts to which the agent will send traps. The format of the trap variable group is defined in Example 5-4.

Example 5-4. Format of the trap Configuration Variable Group
trap = {
   trap1
   trap2
   ...
   trapn
}

The trap group contains one or more trap community definitions. Each defines the association between a set of hosts and the SNMP community string in the traps to be sent to them. The format of each list is defined in Example 5-5.

Example 5-5. Format of a List in the trap Group
{
   trap-community = trapCommunityString
   hosts = trapInterestHostList
}

The meaning of each item is:

trap-community = trapCommunityString

This item specifies the SNMP community string. It will be present in the traps sent to the hosts specified in the hosts item.

hosts = trapInterestHostList

This item specifies the set of hosts. Traps sent to these hosts will contain the SNMP community string specified by the trap-community item. The trapInterestHostList item is a list of hosts. Each host in trapInterestHostList can be expressed as any one of the following:

Each host in the list must be separated from the one that precedes it by a comma.

Example ACL File

An example ACL file is given in Example 5-6.

Example 5-6. Example ACL File
acl = {
   {
   communities = public, private
   access = read-only
   managers = hubble, snowbell, nanak
   }
   {
   communities = jerry
   access = read-write
   managers = 123.456.789.123
   }
   {
   communities = jerry
   access = read-write
   managers = 123!456!789!255
   }
}
trap = {
   {
   trap-community = SNMP-trap
   hosts = hubble, snowbell
   }
   {
   trap-community = competitor-trap
   hosts = hp_server, ibm_server, sgi
   }
}

In this example, managers running on the host machines hubble, snowbell, and nanak are allowed only to get properties of m-beans. The managers running on the following host machines are allowed to get and set properties of m-beans:

Managers running on any other host are denied access to m-beans.

The trap group in this example specifies that the agent will send:

Formal Grammar Definition of an ACL File

The formal grammar definition of an ACL file is given in Example 5-7.

Example 5-7. Formal Grammar Definition of an ACL File
   <acl_file:> :[ < acls> ] [ <trap_block> ]
   <acls> : "acl" "=" {<acls_list> }
   <acls_list> : /*empty*/ | <acls_list> <acl_item>
   <acl_item> : {<communities_stmt> <acl_access> <hosts> }
   <communities_stmt> : "communities" "=" <communities_set>
   <communities_set> : <communities_set> , <community_elem> | <community_elem>
   <community_elem>: alphanumeric_string
   <acl_access> : "access" "=" <acl_access_type>
   <acl_access_type> : read-only | read-write
   <hosts> : "managers" "=" <hosts_list>
   <hosts_list> : <hosts_list> , <host_item> | <host_item>
   <host_item> : <host_alphanumeric_string>
   <host_alphanumeric_string> : <hostname> | <ipaddress> | <subnet_mask>
   <trap_block> : "trap" "=" { <traps_list> }
   <traps_list> : /*empty*/ | <traps_list> <trap_item> | <trap_item>
   <trap_item> : { <trap_community_string> <trap_interest_hosts> }
   <trap_community_string> : "trap-community" "=" alphanumeric_string
   <trap_interest_hosts> : "hosts" "=" <trap_interest_hosts_list>
   <trap_interest_hosts_list> : <trap_interest_hosts_list> ","
   <trap_interest_host_item> | <trap_interest_host_item>
   <trap_interest_host_item> : <hostname> | <ipaddress>
   <hostname> : alphanumeric_string
   <ipaddress> : ###.###.###.###
   <subnet_mask> : ###!###!###!###

Access Control Using an ACL object

For the SNMP adaptor, you can create a class that implements a com.sun.jaw.reference.agent.services.IPAclSrvIf interface. An instance of that class allows you to enable access control in the same way as with an ACL file in applications that do not use a file system.

Access Control for the RMI Adaptor

The Java Dynamic Management Kit does not provide an access control mechanism for the RMI adaptor. To enable the RMI adaptor to provide secure data transfer you have to implement an access control mechanism using a network security application, such as SunScreenTM SKIP.


[ Previous ][ Home ][ Next ]
Operation of the Adaptors[ Up ]Implementing an Adaptor