Skip Headers
Oracle® Application Server Containers for J2EE Security Guide
10g Release 2 (10.1.2)
B14013-02
  Go To Documentation Library
Library
Go To Product List
Product
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

1 Concepts

This chapter describes the following topics:

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:


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  follows
Description of "Figure 1-1 Java 2 Security Model"


See Also:


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:


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:

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.

Secure Communications

To communicate securely, applications must satisfy the following goals:

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