Java Dynamic Management Kit 3.2 Programming Guide | ||||
---|---|---|---|---|
![]() | ![]() | Chapter 5. Adaptors | ![]() | ![]() |
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 HTTP and HTML adaptors provide login/password authentication.
The SNMP adaptor provides access control using information contained in an access control (ACL) file.
The SNMP adaptor can also provide access control using information contained in an access control object.
The Java Dynamic Management Kit does not provide access control for the RMI adaptor or the IIOP adaptor.
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.
The default behavior for the HTTP/TCP, HTTP/UDP, HTTP/SSL, and HTML adaptors is not to require authentication information.
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); |
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.
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.
An ACL file contains the following groups of configuration variables:
acl as defined in Example 5-2
trap as defined in Example 5-4
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:
A host name
An IP address
A subnet mask
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.
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:
A host name
An IP address
Each host in the list must be separated from the one that precedes it by a comma.
An example ACL file is given in Example 5-6.
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:
The host with IP address 123.456.789.123
All hosts with subnet mask 123.456.789.255
Managers running on any other host are denied access to m-beans.
The trap group in this example specifies that the agent will send:
Traps to the hosts hubble and snowbell containing the SNMP community string SNMP-trap
Traps to the hosts hp_server, ibm_server, and sgi containing the SNMP community string competitor-trap
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> : ###!###!###!### |
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.
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.
![]() | ![]() | ![]() |
Operation of the Adaptors | ![]() | Implementing an Adaptor |