1 Overview of Java Security Models

This chapter provides an overview of the security models in the Java Platform, Standard Edition (JavaSE), the Java Authentication and Authorization Service (JAAS), the Java Platform, Enterprise Edition (JavaEE), and the Java Authorization Contract for Containers (JACC).

The coverage of topics in this chapter is not comprehensive; for complete details, consult the appropriate internet site.

The presentation is divided in the following sections:

• Basic Security Concepts

• Java Security Model

• Java Authentication and Authorization Service

• Java EE Security Model

• Java Authorization Contract for Containers

• Comparing the Java Security Models

1.1 Basic Security Concepts

Authentication deals with the question "Who is trying to access services?" In any system or application it is important to ensure that the identity of the entity or caller trying to access a resource is appropriately identified. In a multitier application, the entity or caller can be a human user, a business application, a host, or one entity acting on behalf of (or impersonating) another entity.

Authentication information, such as user names and passwords, is stored in a user repository, such as an XML file, database, or directory service. When a subject attempts to access an application, such as by logging in, the security provider looks up the subject in the user repository and verifies the subject's identity. A security provider is a module that provides an implementation of a specific security service such as authentication or authorization. The Oracle Internet Directory is an example of a repository.

Authorization deals with the question "Who can perform tasks on resources?" Resources are typically expressed in terms of URL patterns for Web applications, and method permissions for EJBs. Authorization is on a per-role basis, with appropriate permissions being assigned to each defined role in an application.

1.2 Java Security Model

The Java security model is based on controlling the operations that a class can perform when it is loaded into a running environment. For this reason, this model is called code-centric or code-based.

The following sections explain the basic concepts necessary to understand how this model works:

• Permissions

• Protection Domains and Security Policies

• Security Managers and Access Controllers

For more details about the Java security model, see http://java.sun.com/developer/technicalArticles/Security/whitepaper/JS_White_Paper.pdf.

1.2.1 Permissions

A permission is a set of permissible operations on some set of resources. Every Java class loaded into a running environment is assigned a set of permissions according to some criteria, each permission granting a specific access to a particular resource. For example, a permission can constrain the access to a database or disallow the editing of a file.

In code-based security, permissions are granted based on code characteristics, such as where the code is coming from and whether it is digitally signed (and by whom). A codebase is a URL indicating code location, such as the following:

• file: (any file on the local file system)

• http://*.oracle.com (any file on any host at oracle.com)

• file:${j2ee.home}/lib/oc4j-internal.jar

A codesource expands this concept to optionally include an array of certificates (stored in a Java keystore) to verify signed code originating from the location. A codesource is represented by a java.security.CodeSource instance, which is constructed by specifying a java.net.URL instance and an array of java.security.cert.Certificate instances.

The abstract Java class java.security.Permission represents a permission; concrete types, all derived from this class, include the following:

• java.security.AllPermission

• java.lang.RuntimePermission (includes only a resource target)

• java.io.FilePermission (includes a resource and actions)

Important: The class AllPermission should be used with caution and only when necessary.

For further details about permissions, see http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc3.html.

1.2.2 Protection Domains and Security Policies

A protection domain associates permissions with codesources. The policy currently in effect is what determines protection domains. A protection domain contains one or more codesources. It may also contain a Principal array describing who is executing the code, a classloader reference, and a permission set (java.security.PermissionCollection instance) representing a collection of Permission objects.

A security policy defines the protection domains of an environment, that is, it identifies the permissions assigned to classes from specified sources. The permissions assigned to a class by a protection domain are bound statically, when the class is loaded, or dynamically, when the executing code attempts a security-sensitive operation. Protections domains are specified in one or several policy files.

The following sample entry in a policy file illustrates how code located in the directory /home/sysadmin and signed by jJoe is granted read access to the file /tmp/abc:

grant signedby jJoe codeBase "file:/home/sysadmin/" {
    permission java.io.FilePermission "/tmp/abc", "read";
};

The signedBy clause in the preceding example is optional. If omitted, the permission is granted to all code in the specified location. Figure 1-1 illustrates the relationship between classes, protection domains, and permission sets.

Figure 1-1 Associating classes with permissions through protection domains

For details about policy file format and policy customization, see http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc3.html#20128.

1.2.3 Security Managers and Access Controllers

A security manager is the component of the Java security model that enforces the permissions granted to applications by security policies. For any security-sensitive operation that an application attempts, the security manager checks the application permissions and determines whether the operation should be allowed. The Java class java.lang.SecurityManager represents a security manager and includes several check methods to determine whether an operation should be allowed or a given permission is in effect.

Important: An application can run with or without the control of a security manager; most thin-applications (such as Web browsers) enable a security manager by default. The security manager is not mandatory for Java policies to be in effect: whether an application chooses to enforce Java policies depends on how permissions are checked by the application. For example, an application can use the method AccessController.checkPermission to enforce Java policies without the security manager being turned on.

An access controller is the object used by the security manager (or directly by an application, if the security manager is not enabled) to control operations and decisions. More specifically, an access controller:

• Decides whether access to a system resource should be allowed or denied, based on the current security policy in effect.

• Marks code as being privileged, thus affecting subsequent access determinations.

• Allows saving the current calling context so access-control decisions that consider the saved context can be made from other, different contexts.

The Java class java.security.AccessController represents an access controller and includes the method checkPermission(aPerm) that determines whether the access requested in the passed permission should be granted. The following code snippet illustrates the use of this method to allow reading the file /temp/testFile:

FilePermission perm = new FilePermission("/temp/testFile", "read");
AccessController.checkPermission(perm);

checkPermission evaluates according to the particular implementation of the access controller. The default implementation examines the entire call stack, the classes in it, and the permissions granted to those classes to determine whether to grant a request. The method returns silently if the request is granted or throws an exception if the request is denied (or the passed permission is invalid).

Note: AccessController.checkPermission performs security checks within the context of the current executing thread. Sometimes, however, an application must perform a security check using a context different from the current one. The method AccessController.getContext takes a snapshot of the current context and returns it in an access control context. The context can then invoke its own method checkPermission, thus basing its evaluation on the context it encapsulates rather than the current context.

A security manager represents a central point of access control, while an access controller implements a particular access algorithm.

For further details about security manager and access controllers see http://java.sun.com/j2se/1.5.0/docs/guide/security/spec/security-spec.doc6.html.

1.3 Java Authentication and Authorization Service

The main features introduced by JAAS are the following:

• It extends the Java security model by allowing checks on the identity of the caller (a feature notably missing in the Java model), checks on the permissions granted to the code being run and subject-based authorization.

• It implements the standard Pluggable Authentication Module (PAM) framework, which decouples an application from its authentication service and supports the implementation of custom authentication modules.

The following sections explain the basic concepts necessary to understand how this model works:

• Principals and Subjects

• Login Modules

• Subjects and the Access Control Context

Oracle Platform Security Services (OPSS) includes a scalable JAAS provider, uses JAAS as a standard mechanism for fine-grained authorization, and supports JAAS authorization for both Web-based and EJB-based applications. The main OPSS extensions to JAAS are supported by the file jazn-data.xml which provides: (a) a light weight XML provider; (b) and LDAP provider; (c) application and anonymous users and roles for fine-grained authorization.

For details about key JAAS features, see http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html

1.3.1 Principals and Subjects

A principal is the identity assigned to an entity (such as a user, a group, or a system process) by an authentication process. The abstract concept of a principal is represented by the Java interface javax.security.auth.Principal. A concrete principal is represented by an instance of a class implementing this interface. Each principal instantiated by an application must have a distinct name, which identifies the principal.

A subject is a grouping of related security information that includes a collection of principals and, possibly, credentials such as passwords or cryptographic keys. The Java class javax.security.auth.Subject represents a subject and an instance of this class is created and populated with principals when authentication succeeds. Thus, a subject represents an authenticated entity, and the principals and credentials in a subject are used to determine what actions the authenticated entity can perform.

For further details about principals and subjects, see:

• http://java.sun.com/j2se/1.5.0/docs/api/java/security/Principal.html

• http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/Subject.html

1.3.2 Login Modules

A login module is a component that authenticates users and populates a subject with principals. Login modules can be plugged in and used by applications without changes to application code. An application can use multiple login modules.

The abstract concept of a login module is represented by the Java interface javax.security.auth.spi.LoginModule. A concrete login module is represented by an instance of a class implementing this interface.

To authenticate users with login modules, a JavaSE application first instantiates a login context, then looks up a configuration file and loads all the login modules configured for the application, and, in turn, invokes the method login in each of them. Each login module adds, as appropriate, one or more principals to a subject that becomes available if, and only if, the authentication succeeds.

In JavaEE applications, however, login modules may be invoked implicitly by the container without the need for the application to instantiate a login context.

A callback handler is the way a login module communicates with users to obtain authentication data. It can be specified when the application instantiates a login context so that all login modules invoked by that context use the passed callback handler. This mechanism frees login module logic from user interaction.

An application can use a stack of login modules to authenticate its users, and each module, independently from the others in the stack, performs its own computations. The stack used by an application is defined in its deployment descriptor; the sequence in which login modules are enumerated in that file is significant, since the authentication algorithm takes this order into account in addition to other data, such as the flag that identifies the module security level (required, sufficient, requisite, or optional).

Note: On Oracle WebLogic Server, a standard JAAS login module cannot be used as-is. For details about WebLogic Authenticator providers, see Section 4.1.1, "Oracle WebLogic Authenticators."

For further details about login module configuration, see http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/login/Configuration.html.

1.3.3 Subjects and the Access Control Context

Once the authentication process succeeds and a subject becomes available, an application calls the method doAs or doAsPriviledged to authorize the subject to perform a sensitive action within a particular context. The difference between them is that doAs uses the current executing context, while doAsPriviledged uses a provided context that can be different from the executing one.

For further details about actions and control contexts, see:

• http://java.sun.com/j2se/1.5.0/docs/api/java/security/class-use/PrivilegedAction.html

• http://java.sun.com/j2se/1.5.0/docs/api/java/security/AccessController.html

For further details about the methods doAs and doAsPrivileged, see the following document:

• http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuide.html.

1.4 Java EE Security Model

The JavaEE security model is a role-based, declarative model based on container-managed security, where resources are protected by roles that are assigned to users. This model allows decoupling an application from its underlying security infrastructure since security can be specified separate from the application logic in an application deployment descriptor. The container, where an application runs, provides security for the application according to a specifications in the deployment descriptor. This model also allows embedding security data (annotations) in the application code that can be referenced in deployment descriptors.

The following sections explain the basic concepts necessary to understand how this model works:

• Container-Based Security

• The Authentication Model

• The Authorization Model

1.4.1 Container-Based Security

A container provides two kinds of security to applications that run in it: declarative security and programmatic security.

Declarative security refers to security expressed in an application deployment descriptor file. At run time, the container uses this file to enforce access to the application resources, such as a Web module URL or an EJB bean method.

For details about EJB technology and the Web Server Security Model, see:

• http://java.sun.com/developer/technicalArticles/J2EE/jpa/

• http://docs.sun.com/app/docs/doc/820-1066/abxep?a=view

Programmatic security refers to security expressed in the code by security-aware applications. This kind of security is useful when declarative security is not sufficient to express fully an application's security requirements.

To use programmatic security, typically, an application implements the interface javax.ejb.EJBContext or the interface javax.servlet.http.HttpServRequest, and uses the weblogic.security APIs and the following methods to customize security decisions:

• EJBContext.isCallerInRole(aRoleName)

• EJBContext.getCallerPrincipal()

• HttpServRequest.isUserInRole(aRoleName)

• HttpServRequest.getUserPrincipal()

For further details about these interfaces, see:

• http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpServletRequest.html

• http://java.sun.com/j2ee/1.4/docs/api/javax/ejb/EJBContext.html

1.4.2 The Authentication Model

A server authenticates the end-user of a Web application in the following ways: basic, form, or client-cert. They differ in the extent of security they provide, but, basically, they all obtain data from the user, such as account name and password, that is processed by the server to create a credential or to deny access. The way a server authenticates a user is specified in the application deployment descriptor.

The server validates the supplied credential against the configured identity store and uses it to authorize further access to secured resources (in the server) or calls to enterprise bean methods (possibly running in a different server).

1.4.3 The Authorization Model

The JavaEE authorization model is based on security roles. A security role is a set of users that can be specified in the application deployment descriptor or in the application code (with annotations). An application controls access to its resources (such as a Web module URL or a bean method) by specifying the roles that are allowed to perform a given operation on a resource.

During deployment, application-scoped roles are mapped to security entities in the running environment, such as users, a group of users, or principals. This mapping is specified in a configuration file different from the deployment descriptor.

At run time, when a principal requests access to a resource, the container determines if the principal has associated a role allowed to access the resource, and if it does, the container transfers control to the application and the request is allowed.

This model also allows an application to specify the identity under which an enterprise Java bean or Web component must run (run-as method-based authorization) and supports transport-layer security (SSL).

For details about servlet security see http://java.sun.com/products/servlet/whitepaper.html.

1.5 Java Authorization Contract for Containers

The Java Authorization Contract for Containers (JACC) specifies a contract between JavaEE containers and authorization modules, so that the container can provide the appropriate authorization. Specifically, JAAC performs the following tasks:

• Defines a role as a collection of permissions

• Grants principals permissions in roles

• Determines whether a principal has been granted the permissions in a role

• Maps identifiers (embedded in application code) to application-scoped roles

JACC allows the JavaEE security model fully to leverage the Java security model by translating JavaEE security constraints into Java permissions. JACC is not enabled by default.

1.6 Comparing the Java Security Models

Here are summarized the features that characterize each of the three models and differentiate them from one another.

All three models are fully supported by OPSS, a platform that supports policy stores where a permission can consist of both Java and JAAS permissions, thus enabling the combination of the code-centric and the user-centric models.

JavaSE

This model is called code-centric because it allows the specification of code security in a predefined policy file. When a class is loaded in the Java run time environment, the class loader automatically associates the following information with the class:

• The location where it was loaded from

• The entity that signed it (if any)

• A set of default permissions

Notably, the identity of the user executing the code is not available at loading time. Authentication is carried out by the application itself as appropriate. Authorization is managed by the application itself or by a security manager.

JAAS

This model extends the JavaSE code-centric model by introducing a user-centric model where both the nature of the code and the executor are taken into account in security decisions.

Authentication can be customized with login modules, and authorization is managed, as in the JavaSE model, according to a predefined policy. Since it also supports custom permissions, this model is suitable for applications where a more fine-grained, customized control of authentication is required.

JavaEE

In this model, secured resources are identified by URL patterns (in Web modules) or method names (in EJB modules); the container where the application runs enforces authentication and authorization according to specifications in the application deployment descriptor or annotations in the application code. The transport layer can use the secure protocol HTTPS.

This model is the least complicated to deploy and administer, and it is often used with the JAAS model.

1.6.1 Summary of Model Comparison

One way to distinguish these three models is to answer the question who does each model protect from accessing what?

The answers, for each model and for OPSS, are summarized in the following table:

Table 1-1 Summary of Model Comparison

Model	Who is Permitted	What is Protected
JavaSE	Code	Code, such as file systems, network resources, classloaders.
JAAS	Subject	Code, such as file systems, network resources, classloaders.
JavaEE	Roles	Resources, such as URLs and EJB methods.
JACC	Subject	Permissions on JEE resources, such as URLs and EJB methods.
OPSS	Code and Subject	All of the above.