For our planned SNMP applet, we will have to use the networking functions from the Java class libraries. In order to use them, it is important to understand the security concept Java uses, since networking functions are extremely dependent on the security model.
The Java security management distinguishes three different classes of Java applets. This is necessary because there is a clear difference between programs that are installed on a local machine -- and therefore will always be given a certain trust that they are not ``evil'' -- and programs that the user gets over the network. When things downloaded over the network are just text and data there is no security issue. However, downloading a Java program and executing it on the local machine is of course very much a security issue. Unless measures are taken to prevent it, a malicious (or buggy) applet could delete files, post confidential data it reads from the hard disk over the network or do other nasty stuff.
The measures that have been taken to prevent those things mostly consist of providing applets loaded over the network with a very restrictive ``sandbox'' environment in which they run. Since not all applets are loaded over the network, and locally stored programs may be trusted more, the Java security management distinguishes between the following security classes which are given different permissions to use the resources of the machine:
Intermediate applet security policies are also possible. An applet viewer could be implemented that would place fewer restrictions on applets loaded from an internal network (a so called ``intranet'') than on those loaded from the Internet.
The restrictions the ``sandbox'' environment is putting on an untrusted applet include the following:
Since we want to write an applet that will run inside a web browser anywhere on our network, we have to live with those restrictions for untrusted applets. This imposes some problems, especially with SNMP, since here we forceably will need to establish network connections to SNMP agents. Since those agents are (usually) not running on the host we loaded the applet from, this imposes a major design problem here. Fortunately, AdventNet provides a solution for this problem, which we will see later.
The networking restrictions do not only depend on the source the applet is loaded from. There are also differences depending on the type of proxy server that might be located between the client browser and the web server as well as the actual implementation of the environment the applets are loaded into. Additionally, the restrictions do also depend on the kind of networking operation that is attempted. Connections to arbitrary network sockets are not routed through HTML proxies, therefore they are to be treated differently than so called ``URL connections'', which are used to fetch information from web or ftp servers and may transparently access HTTP proxies.
Table 4.1 summarizes where untrusted applets are
allowed to connect using
java.net.Socket and table 4.2 summarizes where they are allowed to connect to when using java.net.URLConnection (to communicate with WWW/ftp servers etc.).
For SNMP applications, URL connections cannot be used. We need direct access to the SNMP port of the agent that is to be queried. As it can be seen from Table 4.1, this connectivity can only be achieved to the web server itself, and currently only if no HTTP proxy is used.
|No Proxy||Depending on the setting of the appletviewer.security.mode property, you can connect nowhere, only to the originating host, or anywhere.||Can only connect to the originating host.|
|SOCKS Proxy||Same as no proxy, assuming you set the socksProxyHost property.||No connections allowed (except under OS/2, where it's the same as with no proxy).|
|HTTP Proxy||if the appletviewer.security.mode property is set to ``none'' then all connections are allowed; else no connections are allowed.||No connections allowed.|
|No Proxy||Depending on the setting of the appletviewer.security.mode property, you can connect nowhere, only to the originating host, or anywhere.||Can only connect to the originating host (= the web server).|
|SOCKS Proxy||Same as no proxy, assuming you set the socksProxyHost property.||Same as no proxy, assuming Netscape has been properly configured to use the proxy.|
|HTTP Proxy||Same as no proxy, assuming you set the appropriate properties (see Proxies).||Same as SOCKS Proxy.|
The solution that Advent proposes as a workaround for this problem is called ``SNMP Applet Server (SAS)''. This server allows the applet to send and receive SNMP packets to and from any managed devices accessible from the web server host. The SAS program is a Java application and has to be run on the web server. The applet using the Advent library will then automatically communicate with the SAS application on the web server, which relays all communication to the agent that the applet wants to communicate with. This is possible, since Java applications don't have to deal with security problems. The whole use of the SAS is completely transparent to the programmer and the user. It suffices to start the server application on the web server once, the applet can then automatically detect the TCP port that is used on the web server and all further communication will be relayed by it.
The SNMP applet server can be used for arbitrary TCP ports, not only the SNMP port. Since this would be a potential security hole, the function of the Applet server can be limited to the forwarding of messages for the SNMP port with the command-line switch. In addition to its networking capabilities, the server also provides functionality that gives the applets limited access to files stored in a user directory on the web server.
It should be mentioned that with the recent new version of the Java JDK an additional new security mechansim is introduced: So called ``signed applets''. In the future, those applets will allow the user to trust certain applets that are loaded over the network as well. For this purpose, applets can be signed using a public key mechanism. Currently, this is still under development and has no significance for us.