1
Introduction

This chapter describes the following topics:

• The Java 2 Security Model

• Principals and Subjects

• Authentication and Authorization

• 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 10g Security Guide. For information on Web services, see the Oracle Application Server Web Services Developer's Guide.

The Java 2 Security Model

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.

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

Principals and Subjects

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 subject's identities and security-related attributes (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 current thread's AccessControlContext and then executes the specified request.

Authentication and Authorization

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

• Authentication is establishing the identity and credentials of a subject.

  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 subject's 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 is granting privileges to an authenticated subject.

  Developers specify authorization for subjects in the application's 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's identity.

Secure Sockets Layer

The Secure Sockets Layer (SSL) is the industry-standard point-to- point protocol which provides confidentiality, via 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 a principal's authentication and authorization information. 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-1.

Figure 1-1 Identity Propagation Using CSIv2

Text description of the illustration o_1003.gif

Developing Secure J2EE Applications

J2EE software development is based on a develop-deploy-manage cycle. The Oracle JAAS Provider plays an important role in the deploy-manage part of the cycle. The Oracle 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/or application clients.

   The 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 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.