J2EE security architecture

The J2EE security architecture is defined as part of the platform specification document. It details security management roles, and specifies goals of the security architecture, but does not specify security policy or implementation details (such as the use of a particular security technology to meet the described goals).

 

Code management through the JVM and the class file verifier, the class loader and the Security Manager

 

Basic Java security employs the concept of a “sandbox” to limit the abilities of untrusted code to cause damage to the system on which it runs. Historically, an untrusted piece of code such as an applet would be disallowed from accessing local disk, opening network connections, etc. With the introduction of certificate support through the Java Plug-In, the origin and author of a signed applet could be established definitively, enabling fine-grained permissions to be assigned to individual applets based on the security policy. This means that applets are no longer confined to the default sandbox. As described in the coming paragraphs, the sandbox is implemented through the JVM and its class verifier, but also through the class loader and the Security Manager/ACL manager.

 

Container Managed , Standard J2EE(web only)security

J2EE offers a standard way of working with security, sometimes referred to as Container Managed Security. The container (eg tomcat) handles user authentication so the application doesn’t have to know how users and roles are maintained. And this could even be switched without changing the application. Standard APIS are then used to determine a users identity and role membership for programmatic J2EE security . Or for J2EE security, one can specify security restraints in the web.xml file also.

 

JVM security

The JVM provides a secure runtime environment by managing memory, providing isolation between executing components in different namespaces, array bounds checking, etc. The dynamic way in which the JVM allocates the various memory areas (method area, GC heap, thread stacks) means that it is almost impossible for a would-be attacker to determine what memory areas to attempt to insert malicious instructions into. Bounds checking on arrays prevent unreferenced memory accesses.

 

The JVM’s class file verifier examines classes for basic class file structure upon loading. While bytecodes produced by Sun’s compiler should be relatively free of errors (type
errors, for example), it is possible for an attacker to manually create malicious bytecode.

 

The class file verifier examines each loaded class file in four passes; from the most basic check, where the physical attributes of the file are checked (size, magic number, length of attributes) to checking the constant pool to ensure that method and field references have correct attributes, to parsing the instructions for each method. Note that, by default, the only trusted classes are the base classes. All other classes, including those loaded from the application class path are considered untrusted and must be verified.

 

The Class Loader architecture

There are two types of class loader – the primordial class loader, which is a part of the JVM, and class loader objects, which are used to load non-essential classes. There can only be one primordial class loader, which is used to bootstrap the JVM by loading the base classes, sometimes using native OS-dependent means. There can be many instances of class loader objects in the JVM, which can be instantiated on the fly, and used to load objects from sources such as the network, local disk, or data stores. Controlling the creation of class loader objects is therefore important due to the function of the class loader.

 

Class loaders are responsible for locating classes requested by the JVM for loading into the runtime environment. Part of their responsibility is to prevent unauthorised or untrusted code from replacing trusted code that makes up the base classes. As an example, a class loader should prevent the replacement of the Security Manager class. The attempted replacement of a base class by a maliciously coded class is referred to as class spoofing.

 

All class loaders, with the exception of the primordial class loader, are loaded by other class loaders, which become the loaded class loader’s parent. Thus, the loading of class
loaders describes a tree structure with the primordial class loader at the root and classes as the leaf nodes (obviously class loaders are themselves classes).

If a class loader loads a class, all subsequent requests for related classes are directed through that class loader. For example, if a class loader ”A” loads a class “Building”, and
“Building” makes calls to methods in a class called “Cubicle”, the JVM will use class loader “A” to load “Cubicle” and any other classes that are referred to by “Building”.

Class loaders prevent class spoofing by passing requests back up the tree through their parent class loader until the class loader that loaded the requested class is reached. In the case of the Security Manager class, the primordial class loader is responsible, and consequently the malicious class described above will not be loaded. Classes are loaded only once, and the base classes are only loaded from the local disk using the system class path. Class loaders also provide security by managing namespaces. A class that is loaded by a particular class loader can only reference other classes in the same namespace, i.e.,
loaded by the same class loader or its parents.

 

The Security Manager and Access Controller

The Security Manager was responsible for examining and implementing the security policy, which is specified by policy files. The security policy, as with .Net, determines the
permissions that code has at runtime.

In more recent versions of Java, the decisions on whether to grant permissions based on security policy are delegated to the Access Controller. When a class makes a request for permissions, it is received by the Security Manager which passes the request to the Access Controller.

Signed Java code is assigned permissions based on the system policy as applied to the code’s protection domain. Depending on the permissions associated with the source of the code, the applet may have full access to system resources, or may be restricted to a small subset. Java applications, by default, have no associated security manager, and therefore have full access to system esources.

 

Platform Roles

The J2EE platform specification describes Organisational or Platform Roles that can be used to divide up responsibilities in a J2EE development and deployment cycle. The Roles described in the platform specification are Product Provider, Application Component Provider, Application Assembler, Deployer and Systems Administrator. These Roles are not absolutes – the responsibilities of the various roles could be divided differently to fit a company’s development and deployment methodologies. Of these roles, most have clear security implications. The Product Provider and Application Component Provider roles are responsible for developing secure code, the Assembler is responsible for defining method permissions and security roles, the Deployer verifies the security view of the deployed application and assigns principals to roles, and the Systems Administrator administers principals and ensures that the local security environment is correct for the J2EE platform.

 

Security Roles and the Deployment Descriptor

The deployment descriptor is an XML file that ships with each EJB, and describes declaratively many of the aspects of the EJB’s function and makeup, and its relationship with other beans. One of the elements in the descriptor is the <security-role-ref> element. This element type is used by the bean developer to define all of the security roles used in the EJB code. Security role names are associated with links, which are then called elsewhere in the descriptor.

Membership of a role confers a set of permissions for the duration of the role membership. Principals can be in several roles at the same time, e.g. employee and manager. Method permissions are also described in the eployment descriptor.

 

Programmatic security

Role membership can be determined programmatically in the J2EE environment using the isUserInRole and getUserPrincipal methods of the HTTPServletRequest object for the web container.

As part of the bean-container contract, the container provides the EJBContext object. The corresponding EJBContext methods are isCallerInRole and getCallerPrincipal. getCallerPrincipal returns the principal associated with the security context, while,predictably enough, isCallerInRole is a boolean method used to determine whether the caller belongs to a specified security role.