Java vs .NET Security: Epilogue
Pages: 1, 2
The already-thorough Java offerings for communication protection at the platform and application levels, described in Part 2, are updated by enriching the existing JSSE model and further extended by adding SASL support.
Java's platform-level mechanism, JSSE, undergoes a significant facelift with the addition of a
SSLEngine (fully described in the JSSE Reference Guide Addendum), which nicely abstracts the logic of SSL/TLS layer and allows advanced applications to take complete control of I/O and threading issues. At the same time, the simplicity of traditional socket-stream SSL programming has been preserved, and the
SSLSocket class still implements that functionality.
An important change for JSSE is switching to using JCE providers exclusively -- in version 1.4, it still contains internal cryptographic code, which will be gone in the new release. Thus, JSSE will be able to take advantage of any configured JCE provider, including hardware accelerators.
Additionally, as a result of relaxing U.S. export restrictions, JSSE will now allow plugging in external providers, which should support a specific set of cipher suites. The JSSE Reference Guide Addendum contains the complete listing of required ciphers.
Kerberos suites have been included in the default SunJSSE provider, which provide support for Kerberos-based TLS communication, as described in RFC 2712.
At the application level, the existing GSS provider is augmented by adding a SASL implementation, which provides a lightweight authentication and security services for network communication. SASL is utilized by several popular modern Internet protocols, among them LDAP v3 and IMAP v4. Its advantage over JSSE and GSS lies primarily in very lightweight infrastructure requirements, whereas those two require complex setup, like PKI and Kerberos. However, it is expected that JSSE, GSS, and SASL mechanisms will be layered on top of each other in many implementations.
.NET, which has been clearly lagging in the communication space (see Part 2), finally catches up by providing a managed SSL/TLS implementation that is capable of protecting TCP-based socket-level communication. It operates via the
SslServerStream classes, and is very similar to the model used in Java. Fortunately, .NET does not stop there, and adds support for a standalone HTTP listener (implemented in the
HTTPWebListener class), essentially removing mandatory application reliance on IIS for web interactions. Actually, a similar class has existed in .NET's Remoting infrastructure since v1.0 -- it was used in standalone applications under the covers for exposing Remoting services on HTTP channels. Now its functionality will be upgraded to include support for authentication and SSL.
The new "Indigo" messaging framework will incorporate all security standards from Web Services Architecture (WSA) released to date, which were formerly found in WSE. It further generalizes the concept of secure messaging by applying similar message-based security protection to different types of messaging mechanisms, such as
EnterpriseServices. The "Indigo" framework partitions security functionality in three security layers: TurnKey, Custom, and Extensibility. A majority of applications (80 percent) is expected to fall into the TurnKey category, which requires fully declarative support from the developers by adding declarative attributes and editing policy settings. The latter two categories are used for programmatical customization of the framework at different levels.
The signing process for Java's main code distribution vehicles, JAR files, has been described in Part 3 of this series. One of the shortcomings of the existing process is the inability to determine the validity of the archive relative to the certificate's expiration time. The addition of Signature Timestamps solves this problem by adding timestamps to the JAR signatures, thus allowing for checking whether the signing certificate was valid at the time of signing. The
jarsigner tool will be updated to include new signing options, and the JAR API in the
java.security package will extended with new classes and methods to access the timestamp information.
.NET extends its existing deployment model (XCOPY- or MSI-based) by introducing the ClickOnce deployment and update mechanism for server-based installations. It is based on using signed manifests and deployment files, similar to the model J2EE has been using for EJB deployments.
However, there are significant improvements waiting ahead -- for details of the manifest, see the preliminary MSDN Longhorn documentation. First, the application manifest will include security requirements of the application (not those of individual assemblies). These trust requests and the application's evidence are evaluated by the newly introduced
TrustManager, and presented for the user's consent if an application requires additional permissions outside of the Secure Execution Environment (SEE). The results of this evaluation and the user's decision are stored on per-user and per-machine levels and used later for CAS decisions (see CAS section). Secondly, deployment manifests specify update policy, which allows secure, XML Digital-Signature-based application updates. An interesting detail about the manifest's structure is that it is the application manifest itself that is signed, and not the individual assemblies comprising the application -- they are represented in the manifest by their digests. In this respect, structure of .NET's application manifest resembles signed JAR files in Java.
The designers of .NET's Base Class Library (BCL) introduced a new feature for limiting code exposure:
friend assemblies. The premise is that the internal classes in a particular assembly are declared to be accessible from another assembly, referenced by its
PublicToken, much like how the
friend declaration works in C++ for classes. Following the general .NET approach, this extension is introduced via a new assembly-level attribute,
.NET's CAS model, described in Part 3, offers an excellent framework for code access security. However, it is rendered completely unusable for locally installed applications, which are blankly granted
FullTrust by the default policy, meaning that any CAS permission check will succeed. The upcoming release of the .NET framework includes the
TrustManager, which will make the decision of granting application trust requests based on the machine policy in effect and the application manifests (see the Deployment section).
At the same time, developers are urged to develop their applications targeting the
Internet permission set, as an application sandbox with low trust and a "safe" permission set (preliminarily named Secure Execution Environment, or SEE) will be introduced in the Longhorn Windows OS (due in 2005) for executing applications. However, according to the preliminary MSDN Longhorn documentation, Longhorn's security system, as it is presently designed, does not attempt to verify trust of local .exe files that do not have deployment manifests, and simply grants them the same
FullTrust as before. Hopefully, this policy will change by the release time, because, with its present design, this setup presents an unfortunate way to bypass the system checks in local scenario.
To allow several choices for attribute-based CAS demands, the CLR adds
LinkDemandChoice actions. Their logic is similar to the ordinary demands, but they allow specifying several attributes with different permission sets. Satisfying any of them is sufficient for the success of the overall check.
Java's flexible Authentication and Authorization Service (JAAS), which was reviewed in detail in Part 4, offers
Krb5LoginModule among other so-called Pluggable Authentication Modules (PAMs). Presently, it does not include an option for TGT renewal, which causes their expiration in long-running services and requires either restarting the process or user intervention for re-authentication. Setting the newly introduced configuration option,
true will now result in automatic TGT renewals whenever expired tickets are retrieved from the ticket cache.
ASP.NET 2.0, which remains the primary web development platform for .NET, brings a whole slew of improvements for its existing forms-based authentication model (Part 4). Most importantly, it introduces Membership and Role Management APIs (found in the
System.Web.Security namespace), which take care of tedious programming tasks by essentially eliminating, or significantly reducing the need for, writing security plumbing.
The Membership API takes care of the issues commonly present in password-based systems, such as secure credential operations (CRUD), finding and authenticating users, and password management. The Role Management API, based on ASP.NET Role model in 1.x, works together with the Membership API (although it can be accessed separately) to solve the user-to-role mapping issue and can be used programmatically and declaratively, in Web.config. Both APIs use a Provider Model design pattern, and are highly extensible (providers for SQL Server and Access are included in the default installation). If these APIs eventually are made available outside of the ASP.NET umbrella (like WSE Pipeline), they will provide a great and flexible addition to many types of .NET applications besides web-based ones.
New server-based GUI controls for ASP.NET take advantage of these new APIs, further reducing the amount of required programming, often making it as simple as dropping the controls on the form. The following controls will be made available, among others, in the new release:
Java does not offer any significant new features in the upcoming release, instead extending its offerings in existing categories.
.NET, on the other hand, aggressively pursues new security functionality. It will catch up with (or even pass) Java on several topics where Java currently holds an advantage, and extend its lead in the areas of its dominance. Most prominently, it catches up in the categories of communication protection and PKI, and it goes one more step ahead by adding full support for the W3C XML Encryption recommendation.
However, it is worth noting that with incorporation of .NET into the core Windows OS (starting with Windows 2003 Server), it is becoming progressively harder to distinguish .NET-specific features from OS features, as in the upcoming versions they are often designed to complement each other. This confusion might stem from the fact that Microsoft authors and spokespeople often do not specifically distinguish between the two in their publications and presentations, thus muddying the overall picture.
Incidentally, adding support for the WSA family of standards into the core .NET libraries prior to submitting them for approval by OASIS (with the exception of WS-Security, which already goes through the technical committee review) means that Microsoft probably does not expect any significant changes to the released set of specifications, or does not intend to submit them at all. Its intentions remain to be seen, but they certainly do not make life easier for Sun's developers, who have to shoot at a moving target in this case.
Denis Piliptchouk is a senior technical member of BEA's AquaLogic Enterprise Security group, participates in OASIS WSS and WS-I BSP standards committees, and regularly contributes to industry publications.
Return to ONJava.com.