Simplistically, the Java applet (Figure 1) parses the SDP, mapping
session attributes against a tool definition (a SDR plugin) and then starts
the tools with the correct parameters on the client machine. The SDP content
and tool plugins are embedded within the HTML as parameters to the applet.
The field terminator used in the SDP is replaced with a 'browser friendly'
alternative, as SDP's CR/LF field terminator is removed by the browser.
An added advantage of using HTTP to communicate the SDP content between
client and server is that by using a secure web server, the SDP content
(possibly with encryption keys) will also be secure.
For obvious security reasons standard Java applets do not have
permissions to access local resources and thus cannot execute software
on the client machine. To overcome this, both Netscape’s Communicator
and Microsoft’s Internet Explorer 4 allow applets to be digitally signed
with a private key associated to a RSA object-signing certificate. If
the user accepts the certificate, therefore trusting the applet, then
the browser allows the applet access permissions outside the Java
security sandbox. Communicator and Internet Explorer implement
different methods and technologies for digitally signing and
Communicator requires Java applets to be signed using Netscape’s
Netscape Object Signing software. The certificate and Java code are then
packaged using the JAR file structure. Signed Java applets need to
explicitly request permission to access local resources, such as
executing software using the Netscape’s Capabilities API extensions.
The request causes Communicator to prompt the user, asking them to
either accept or deny the relevant permission (see Figure 2). The
dialog box also contains the certificate as verification of the source
and authenticity of the code.
Figure 2 - Netscape Certificate Dialog Box
Internet Explorer requires Java applets to be signed using
Microsoft's Authenticode software and packaged using a CAB file
structure. A signed Java applet also has to request permission to
access local resources by using Microsoft's Com API extensions. However
unlike Communicator, the specific request doesn't prompt any user action.
Instead the user is asked to accept the applets' certificate when the
applet is encountered by the browser (see Figure 3) and by doing so
grants universal access to local system resources.
Figure 3 - Internet Explorer Certificate
Alternatively, browser's that do not support signed applets but do
have a 'plug-in' architecture can use SUN's Java Plugin to view the
applet. The Plugin requires the applet to be signed and packaged using
Netscape's Netscape Object Signing software but it doesn't implement
Netscape's Capabilities API. Since the API is not supported by the
Plugin, any certificate accepted by the user, grants universal access to
local system resources.