Security Semantics for J# Browser Controls
Collapse the table of content
Expand the table of content
The document is archived and information here might be outdated

Security Semantics for J# Browser Controls

Visual Studio .NET 2003

J# Browser Controls run on users' computers by accessing the classes in the J# Browser Controls runtime and the .NET Framework. Many of these classes demand appropriate permissions from their callers before performing sensitive operations like accessing or deleting files. Operations that a J# Browser Control is allowed to perform depend on where it is downloaded from and the .NET Framework security policy on the computer. For example, J# Browser Controls downloaded from the Internet or Intranet do not have access to files on the computer they run on.

There are some other aspects in security that developers must be aware of:

  • The java.applet.Applet.getAudioClip and java.applet.Applet.getImage methods only allow access to resources on the same Web server that the J# Browser Control is downloaded from.
  • J# Browser Controls are only allowed to create sockets that use TCP protocol. Creating sockets that use the UDP protocol is not supported.

Deploying Fully Trusted J# Browser Controls

The MSJVM allows a developer to package Java applet classes into a .cab file, sign the .cab file with an Authenticode certificate and associate Java permissions with the .cab file. When a signed cabinet file is downloaded from a page, the signature is examined to see if it contains permission information. If so, Internet Explorer and the Microsoft Virtual Machine work together to determine what the applet will be allowed to do. This determination is based on the security level of the zone the cabinet file is downloaded from, the permissions requested in the cabinet signature, and the response of the user, if needed. This mechanism was called trust-based security.

J# Browser Controls runtime does not support trust-based security. To run a J# Browser Control with full trust, it must be signed with a keypair file. The .NET Framework security policy on user computers must then be modified to fully trust code signed with that particular keypair. The Visual J# compiler supports signing DLLs with keypair files. The sn.exe tool in the .NET Framework SDK can be used to generate keypair files. For more information on generating keypair files, see Strong-Named Assemblies.

Before signed J# Browser Controls can perform operations like file I/O, the .NET Framework security policy on end-user computers will need to be updated to grant additional permissions to code signed with the keypair. The security policy on end-user computers can be updated using policy files. The white paper .NET Framework Enterprise Security Policy Administration and Deployment has information on the several approaches to creating and deploying .NET Framework security policy files.

In J# Browser Controls v1.1b, it is not enough for the J# Browser Control code that is making the call alone to be trusted. The code needs to assert for the appropriate permissions to carry out the privileged operation because the control now runs in a reduced permission context. The developer must ensure that the call to access the protected resource is secure. Please refer to the MSDN documentation on Assert online.

// FileIOPermission per = new FileIOPermission(. . . );
// per.Assert();
// Access the protected resource 
// file.Read(. . . );
// per.RevertAssert();

See Also

Migrating Java Applets to Microsoft J# Browser Controls | Classes Accessible to a J# Browser Control | How to: Debug J# Browser Controls | Supporting J# Browser Controls and Java Applets in the Same Page

© 2016 Microsoft