1 Concepts

This chapter describes the following topics:

• Java 2 Security Model

• Principals

• Subjects

• Authentication and Authorization

• Secure Communications

• Developing Secure J2EE Applications

For a broader description of Oracle Application Server security in middle-tier environments that connect to the Internet, see the Oracle Application Server Security Guide. For information on Web services, see the Oracle Application Server Web Services Developer's Guide.

Java 2 Security Model

The Java 2 Security Model is fundamental to the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider.The Java 2 Security Model enables configuration of security at all levels of restriction. This provides developers and administrators with increased control over many aspects of enterprise applet, component, servlet, and application security. The Java 2 Security Model is capability-based and enables you to establish protection domains, and set security policies for these domains.

See Also: For a tutorial on Java 2 Security: http://java.sun.com/docs/books/tutorial/security1.2/index.html For full information on Java 2 Security: http://java.sun.com/security

Permissions

Permissions are the basis of the Java 2 Security Model. All Java classes (whether run locally or downloaded remotely) are subject to a configured security policy that defines the set of permissions available for those classes. Each permission represents a specific access to a particular resource. Table 1-1 identifies the elements that comprise a Java permission instance.

Table 1-1 Java Permission Instance Elements

Element	Description	Example
Class name	The permission class	java.io.FilePermission
Target	The target name (resource) to which this permission applies	Directory /home/*
Actions	The actions associated with this target	Read, write, and execute permissions on directory /home/*

Protection Domains

Each Java class, when loaded, is associated with a protection domain. Protection domains can be configured for all levels of restriction (from complete restriction on resources to full access to all resources). Each protection domain is assigned a group of permissions based on a configured security policy at Java virtual machine (JVM) startup.

At runtime, the authorization check is done by stack introspection. This consists of reviewing the runtime stack and checking permissions based on the protection domains associated with the classes on the stack. This is typically triggered by a call to either:

• SecurityManager.checkPermission()

• AccessController.checkPermission()

The permission set in effect is defined as the intersection of all permission sets assigned to protection domains at the moment of the security check.

Figure 1-1 shows the basic model for authorization checking at runtime.

Figure 1-1 Java 2 Security Model

Description of "Figure 1-1 Java 2 Security Model"

See Also: Sun Java documentation at: http://java.sun.com/security/

OracleAS JAAS Provider Permission Classes

Table 1-2 lists the permission classes furnished by the OracleAS JAAS Provider. These classes allow applications to control access to resources.

See Also: OracleAS JAAS Provider Javadoc for information about the classes discussed: JAAS Provider API Reference

Table 1-2 OracleAS JAAS Provider Permission Classes

Permission	Part of Package	Description
AdminPermission	oracle.security.jazn.policy	Represents the right to administer a permission (that is, grant or revoke another user's permission assignment).
RoleAdminPermission	oracle.security.jazn.policy	The grantee of this permission is granted the right to further grant/revoke the target role.
JAZNPermission	oracle.security.jazn	For authorization permissions. JAZNPermission contains a name (also called a target name), but no actions list; you either have or do not have the named permission.
RealmPermission	oracle.security.jazn.realm	Represents permission actions for a realm (such as createRealm, dropRealm, and so on). RealmPermission extends from java.security.Permission, and is used like any regular Java permission.

Principals

A principal is a specific identity, such as a user named frank or a role named hr. A principal is associated with a subject upon successful authentication to a computing service. Principals are instances of classes that implement the java.security.Principal interface. A principal class must define a namespace that contains a unique name for each instance of the class.

Subjects

A subject represents a grouping of related information for a single user of a computing service, such as a person, computer, or process. This related information includes the identities and security-related attributes of the subject (such as passwords and cryptographic keys).

Subjects can have multiple identities; principals represent identities in a subject. A subject becomes associated with a principal (user frank) upon successful authentication to a computing service—that is, the subject provides evidence (such as a password) to prove its identity.

Principals bind names to a subject. For example, a person subject, user frank, may have two principals:

• One binds the principal frank doe (name on his driver license) to the subject

• Another binds the identification principal 999-99-9999 (number on his student identification card) to the subject

Both principals refer to the same subject.

Subjects can also own security-related attributes (known as credentials). Sensitive credentials requiring special protection, such as private cryptographic keys, are stored in a private credential set. Credentials intended to be shared, such as public key certificates or Kerberos server tickets, are stored in a public credential set. Different permissions are required to access and modify different credential sets.

Subjects are represented by the javax.security.auth.Subject class.

To perform work as a particular subject, an application invokes the method Subject.doAs(Subject, PrivilegedAction) (or one of its variations). This method associates the subject with the AccessControlContext of the current thread and then executes the specified request.

Authentication and Authorization

Software security depends on two fundamental concepts: authentication and authorization.

• Authentication deals with the question "Who is trying to access my services?" In any system and application it is paramount to ensure that the identity of the entity or caller trying to access your application is identified in a secure manner. 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 is stored in a user repository. When a subject attempts to access a J2EE application, a user manager looks up the subject in the user repository and verifies the identity. A user repository can be a file or a directory server, depending on your environment. The Oracle Internet Directory is an example of a user repository.

  Although each J2EE application determines which user can use the application, it is the user manager that authenticates the user's identity using the user repository.

  OC4J supports several different authentication options; for details, see "Authentication Environments" .

• Authorization deals with the question "Who can access what services offered by which components?" For large-scale enterprises, where the access to various business-critical services and resources by millions of users need to be managed, it is important that a scalable authorization infrastructure be in place to deal with user and application provisioning. Unfortunately, in part due to the complex nature of authorization, this is also an area where confusion reigns and incompatible technologies and standards are prevalent.

  Developers specify authorization for subjects in the application J2EE and OC4J-specific deployment descriptors. These deployment descriptors indicate what roles are needed to access the different parts of the application. Roles are the identities that each application uses to indicate access rights to its different objects. The OC4J-specific deployment descriptors provide a mapping between the logical roles and the users and groups known by OC4J.

Secure Communications

To communicate securely, applications must satisfy the following goals:

• Secure communications—the data transmitted over the network cannot be intercepted, read, or altered by a third party. OC4J supports secure communications using the HTTP protocol over the Secure Sockets Layer.

• Network authentication—clients and servers must be able to authenticate themselves to one another over the network. This is achieved using digital certificates, single sign-on, or username/password combinations.

• Identity propagation—allowing one client to act as the agent of another client, using the original client identity.

Secure Sockets Layer

The Secure Sockets Layer (SSL) is the industry-standard point-to- point protocol which provides confidentiality through encryption, authentication and data integrity. Although SSL is used by many protocols, it is most important for OC4J when used with the HTTP browser protocol and in the AJP link between the OHS and OC4J processes.

Certificates

Applications need to transmit authentication and authorization information over the network. A digital certificate, as specified by the X.509 v3 standard, contains data establishing authentication and authorization information for a principal. A certificate contains:

• A public key, which is used in public key infrastructure (PKI) operations

• Identity information (for example, name, company, country, and so on)

• Optional digital rights which grant privileges to the owner of the certificate

Each certificate is digitally signed by a trustpoint. The trustpoint signing the certificate can be a certificate authority such as VeriSign, a corporation, or an individual.

HTTPS

For convenience, this book uses "HTTPS" as shorthand when discussing HTTP running over SSL. Although there is an https URL prefix, there is no HTTPS protocol as such.

Identity Propagation

OC4J supports propagating the identity of principals from context to context. A Web client can establish its identity to a servlet; the servlet can then use that identity to communicate with other EJBs and servlets, as illustrated in Figure 1-2.

Figure 1-2 Identity Propagation Using CSIv2

Description of "Figure 1-2 Identity Propagation Using CSIv2"

Developing Secure J2EE Applications

J2EE software development is based on a develop-deploy-manage cycle. The OracleAS JAAS Provider plays an important role in the deploy-manage part of the cycle. The OracleAS JAAS Provider is integrated with J2EE security. This means that developers can use a declarative security model instead of having to integrate security programmatically, unburdening the developer.

The following list summarizes the J2EE development cycle, with an emphasis on the tasks specific to developing secure applications.

1. The software developer creates Web components, enterprise beans, applets, servlets, and application clients.

   The OracleAS JAAS Provider offers programmatic interfaces, but the developer can create components without making use of those interfaces.

2. The application assembler takes these components and combines them into an Enterprise Archive (EAR) file.

   As part of this process, the application assembler specifies OracleAS JAAS Provider options appropriate to the environment.

3. The deployer installs the EAR into an instance of OC4J.

   As part of the deployment process, the deployer may map roles to users.

4. The system administrator maintains and manages the deployed application.

   This task includes creating and managing JAAS roles and users as required by the application customers.