The Foliage Software comparative study discussed in the DevX article “Software Engineers Put .NET and Enterprise Java Security to the Test” is quite positive about J2SE and J2EE security mechanisms as compared with those in Microsoft .NET. The comparison makes clear that many aspects of .NET are based on ideas derived from Java and in several areas Java is noted as the more flexible and capable system. The primary Java security shortcoming that Foliage alleges relates to the model of downloading and running standalone applications?which are not fully trusted?from the Internet or local intranets.

Sun has addressed this issue with a new mechanism called Java Web Start, which makes downloading and safely running full client applications as easy as clicking on a Web link. Web Start-enabled Java applications can be automatically cached on the user’s local machine and updated when new versions become available. Users also can install these applications as icons on their desktops so they can run them without having to revisit the site from which they were initially downloaded. Java Web Start applications always run with an enabled Java security manager and are fully bytecode-verified.

Foliage also compares .NET’s application model to the basic Java Runtime Environment (JRE) application execution model and claims that the Java model does not verify code loaded from the local machine. This is not fully accurate. Even for the basic underlying JRE, all local Java standalone application code is always bytecode-verified. In addition, one can easily run a local standalone application with a security manager, which is enabled to take advantage of Java’s flexible and fine-grained security policies (based on where code was downloaded from, who digitally signed it, and under whose user identity it is running).

When enabled, the default Java security policy treats local applications as untrusted and restricts them so they may be run safely (much as an untrusted Java applet is run in a Web browser). Users or site administrators can then change the default policy to grant additional permissions to Java applications if they desire to do so. In contrast, locally installed .NET applications have a documented default security policy that allows them to run as fully trusted and with all privileges.

Future releases of J2SE and J2EE will continue to integrate, extend, and enhance the flexible security mechanisms that enable Java applications to safely leverage the power of network computing on a wide variety of platforms, including Solaris, Linux, and Windows.

The DevX article “Software Engineers Put .NET and Enterprise Java Security to the Test” asserts that the .NET Framework’s close connection to Windows gives it “a richer set of permissions and evidences than Enterprise Java has.” It also states that Java has more configurable policy levels. In fact, the evidence-based and code access security technology discussed is independent of Windows, and it complements the authorization security features built into the operating system.

This model gives administrators incredibly powerful, granular control over what resources can and cannot be accessed by partially trusted code running on their machines. It also gives developers the ability to lock down their code.

For example, developers can use attributes in their code to demand that any classes that call or inherit from class X bear certain evidence?a key, a digital signature, a hash value, origin from a certain URL, and so on. Developers can also refuse certain superfluous permissions (or “rights” to access particular resources) that the administrator-set policies might provide.

This technology is completely configurable, allowing systems administrators to easily extend the list of what may be considered a resource or what may be considered evidence. It also allows administrators to set these resource permissions and evidence requirements on a variety of levels: for a particular application domain, a particular user, a particular machine, and across the enterprise.

Regarding cryptography, the .NET Framework provides an easy-to-use, extensive, and extensible set of cryptographic algorithms. Some of the algorithms are provided by Windows CryptoAPI, as well as third-party cryptographic service providers that plug into CryptoAPI. For example, security tokens (smart card or USB token) or hardware accelerators that are already compatible with CryptoAPI are automatically available to the .NET Framework.

Other algorithms we provide, such as AES/Rijndael, SHA1, SHA256, SHA384, and SHA512, are implemented directly in Microsoft intermediate language (MSIL). Developers who want to plug in their own implementations can do so. The object model is fully extensible. They can even make their implementations be the “default” by changing the common language runtime’s machine.config file.

The article raises concerns about the fact that secure communication with the .NET Framework is tied closely to IIS. While IIS has been a popular target for attacks in the past, we’ve come a long way in the last year with this product. For IIS 5.0, we’ve shipped tools for administrators like the IIS Lockdown Tool and a great ISAPI filter called URLScan that can help mitigate new attacks and block the old ones. IIS 6.0, which will ship with Windows .NET Server, comes completely locked down out of the box, further reducing the likelihood of attack penetration.

On the subject of advanced user-based access control, the .NET Framework provides support for Windows authorization with access control lists and security groups, and also supports delegated authentication using mechanisms like Kerberos. Authorization in the .NET Framework is extremely flexible; it can support a wide variety of scenarios ranging from Windows authentication to application-level authorization decisions based on business logic or processes. The more advanced scenarios do require some developer initiative but the model is meant to easily facilitate building this support and seamlessly integrating it into the core .NET Framework user authorization model.

Finally, with respect to the claim that the .NET Framework must provide better support for transactions, the .NET Framework does in fact support these features in the underlying OS via the System.Diagnostics.EventLog classes.

We appreciate Foliage Software’s research into our security architecture and hope more people will follow its lead.