Section 10.2. A Look at Java and J2EE Security Standards

10.2. A Look at Java and J2EE Security Standards

J2EE security builds on the foundation of the Java security APIs. These APIs include application-level interfaces such as the Java Authentication and Authorization Service (JAAS) and the Java Authorization Contract for Containers (JACC ) as well as lower-level APIs such as the Java Cryptography Extension (JCE ), the Java Secure Socket Extension (JSSE), and the Java Generic Security Services (GSS) API. While the nuts and bolts of these standards are often hidden from the developer, it helps to understand what security pieces the standards provide, especially as you evaluate application servers or security providers, for example.

10.2.1. Authentication and Authorization in Java Security

The core Java security model is based on .policy files that govern the allowed operations for specific pieces of code. These pieces of code are defined based on their packages and classes, where the code originated, and who (if anyone) signed the code. This level of security is often called code-level security, since you are authorizing chunks of code to do specific things rather than the users who are interacting with the code.

JAAS enhances the Java security model by providing user-level security. JAAS deals with authenticating users (referred to in JAAS as subjects) and authorizing them to run certain programs, applets, or jars based on a variety of criteria, all specified in the same .policy file used for code-level security. JAAS is a required element in both the 1.3 and 1.4 versions of the J2EE specification, so any compliant application server will offer support for it. The authentication aspects of JAAS are highly applicable to J2EE applications since they allow for pluggable runtime authentication, which is useful for developing and deploying applications in various environments using different security infrastructures. Standalone Java clients can also use JAAS for authentication, provided that their runtime environment has a JAAS implementation available.

The authorization features of JAAS allow you to authorize users to perform specific actions within an application. A set of low-level permissions are available out of the box with JAAS, but you can implement your own context-specific (or even application-specific) permissions by subclassing the java.security.Permission class. Permissions can be specified to restrict users to specific URLs in a web application, for example, or to perform certain administrative actions on a financial system.

The Java Authorization Contract for Containers (JACC) is a newer security API, introduced as a standard part of J2EE as of the 1.4 version of the specification. JACC builds on JAAS in three fundamental ways. First, it provides a set of standard JAAS/Java security permission types that are directly relevant to enterprise applications (e.g., standard permissions related to web resources and EJB business methods). Next, it provides a standard model for role-based authorization, grouping sets of permissions into named roles, such as customer or salesperson, that can be applied to users within policy definitions. Last, JACC defines a standard service provider API (SPI) that allows J2EE containers and servers to plug in their own authorization providers into the standard JACC model. This pluggability layer also allows you to integrate third-party authorization providers into your application server.^[*]

^[*] J2EE 1.4-compliant application servers such as Apache Geronimo, BEA WebLogic 9, and IBM WebSphere 6 support JACC; Tomcat, for example, does not.

10.2.2. Encryption in Java Security

JCE is a lower-level security API aimed at data protection needs in applications. JCE is a pluggable framework for encryption, key generation and agreement, and Message Authentication Code (MAC) algorithms. Sun provides a default implementation of JCE, but several third-party implementations of the framework and of specific cryptographic algorithms are available in both commercial and open source products. Application server vendors may implement underlying security mechanisms by leveraging JCE, but in general JCE has a limited role in the security aspects of the J2EE specification. However, JCE can be a very useful tool in your application code. JCE can be used to encrypt sensitive information such as passwords or credit card numbers, in transport or in storage.

JSSE is also related to data protection through encryption. It is a Java implementation of the SSL protocol. Like JCE, application servers and containers may or may not use JSSE in their internal implementations, in this case for SSL network communications. Some versions of Tomcat, for example, use JSSE internally to implement SSL-enabled HTTP communications. JSSE can also be used by both server- and client-side application code to execute secure socket communications directly.

The Java GSS-API defines and implements Java mappings for GSS-API features including support for Kerberos authentication.