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 evidencea 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.