3 Overview of OC4J Security

This chapter introduces the Oracle Containers for J2EE (OC4J) security implementation. This implementation allows developers to integrate authentication, authorization, and delegation services with their applications.

The key component of this implementation is the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider, which supports the JAAS specification.

This chapter covers the following:

• Introducing the OracleAS JAAS Provider and Security Providers

• Introducing Authentication Features in the OC4J Environment

• Introducing Authorization Features in the OC4J Environment

• Overview of Security Role Mapping

• Overview of General-Use Identity Management Frameworks and APIs

See Also:

• Oracle Application Server Best Practices (available post-release) for information about best practices for security

• For Oracle Application Server general security information and infrastructure, the 10.1.2 version of the Oracle Application Server Security Guide, a document that is not part of the 10.1.3.x documentation set but is available at the following location:

  http://www.oracle.com/technology/documentation/appserver1012.html
  

Introducing the OracleAS JAAS Provider and Security Providers

OC4J supplies a JAAS implementation, the Oracle Application Server Java Authentication and Authorization Service (JAAS) Provider. The OracleAS JAAS Provider is easily integrated with J2SE and J2EE applications that use the Java 2 Security model, and implements user authentication, authorization, and delegation services that developers can integrate into their application environments. Instead of devoting resources to developing these services, application developers can focus on the presentation and business logic of their applications.

In addition to the OracleAS JAAS Provider, the other key aspect of the security framework for OC4J applications is support for several particular security providers: file-based, Oracle Identity Management (LDAP directory-based), external LDAP directory, Oracle Access Manager, and custom (using custom login modules).

The rest of this section covers the following topics:

• Overview of the OracleAS JAAS Provider

• Summary of JAAS Framework Features

• Security Realms in the OracleAS JAAS Provider

• Supported Security Providers

Overview of the OracleAS JAAS Provider

The OracleAS JAAS Provider implements the JAAS Login Configuration Provider interface and the JAAS Policy Provider interface:

• The Login Configuration Provider implementation is involved in retrieving login module configuration information and ensuring that the appropriate login module is invoked for authentication. An XML file is used to store JAAS login module configurations.

• The Policy Provider implementation supports either of two repositories to store policies for authorization: an XML file or directory service. (This is as opposed to the Sun Microsystems Policy Provider implementation, for example, which uses the file JAVA_HOME/jre/lib/security/java.policy as a policy repository.) Policies contain the rules, referred to as the permissions or privileges, that authorize a user to access and use resources, such as reading from or writing to a file.

Using OracleAS JAAS Provider, applications can enforce fine-grained access control upon resource users. The three key steps when a security-aware application is running in OC4J are the following:

1. Set up and invoke the login module, which involves the OracleAS JAAS Provider. OC4J supplies login modules for the security providers it supports, or you can use custom login modules.

2. Authenticate the user attempting to log in, which is the role of the security provider.

3. Authorize the user by checking permissions for whatever the user is attempting to accomplish, which involves the OracleAS JAAS Provider.

By default, OracleAS JAAS Provider is configured as part of the OC4J product.

Note:

In earlier releases, the term "JAZN" was used to refer to the OracleAS JAAS Provider. This term is no longer used in general, but still appears in code (such as class and package names) and the Admintool shell prompt.

Summary of JAAS Framework Features

Table 3-1 summarizes JAAS framework features implemented by the OracleAS JAAS Provider.

Table 3-1 JAAS Framework Features

Feature	Description	See Also
Authentication	Integrates with Oracle single sign-on solutions for login authentication in J2EE application environments. Supplies an out-of-the-box RealmLoginModule class for non-SSO environments, such as OracleAS Core or Java Edition. Supports any JAAS-compliant custom login module.	"Introducing Authentication Features in the OC4J Environment"
Declarative model	Integrates J2EE deployment descriptors, such as web.xml and ejb-jar.xml, with JAAS security.
Authorization	Supports the J2EE authorization model. Supports the JAAS authorization model. Supports the Java Authorization Contract for Containers.	"Authorization APIs, JAAS Mode, and JACC in the OC4J Environment"
Realm management	The package oracle.security.jazn.realm is provided to support user and role management.
Policy management	The package oracle.security.jazn.policy is provided for administration of authorization policy.
Administration	Supports administration and configuration using Oracle Enterprise Manager 10g or the command-line OracleAS JAAS Provider Admintool.	"Tools for Oracle Application Server and OracleAS JAAS Provider"
JAZNUserManager	Supplies a security provider implementation that integrates with the file-based provider, Oracle Identity Management, and Oracle Access Manager. This class is in the oracle.security.jazn.oc4j package.

Security Realms in the OracleAS JAAS Provider

The JAAS framework does not explicitly define user communities. However, J2EE has the concept of user communities called realms.

A realm is a collection of users and roles that are controlled by the same authentication policy. In other words, a realm is a security domain that defines a set of permissions for authenticated users.

Each realm includes a set of configured users and roles. (In OC4J configuration, users and roles can all be configured within a realm definition.)

See Also:

• "Using Security Realms in OC4J"

• "Realm Management for the LDAP-Based Provider"

Supported Security Providers

Oracle Application Server supports the following security providers. Each security provider is associated with an appropriate login module (RealmLoginModule for the file-based and LDAP-based providers), which is effectively part of the security provider. In addition, each security provider uses a repository for secure and centralized storage, retrieval, and administration of data that consists of realm information (users and roles) and JAAS policy information (permissions).

• File-based (XML-based) provider

  The file-based provider, discussed in Chapter 7, "File-Based Security Provider", is a fast, lightweight JAAS login module implementation that uses an XML repository. User, role, and policy information is typically stored in the OC4J instance-level file system-jazn-data.xml.

  This is the default security provider.

• LDAP-based provider: Oracle Identity Management

  This is the security provider if you want to use Oracle Internet Directory as your user repository, with or without Oracle Single Sign-On, as described in Chapter 8, "Oracle Identity Management". The Oracle Identity Management provider stores user, role, realm, and policy information in Oracle Internet Directory, which is based on the Lightweight Directory Access Protocol (LDAP) for centralized storage of information.

  This security provider, intended for production environments, is scalable, secure, enterprise-ready, and integrated with Oracle Single Sign-On.

  OC4J must be associated with an Oracle Internet Directory instance in order to use Oracle Identity Management.

• External LDAP providers

  Oracle Application Server supports external (third-party) LDAP providers such as Sun Java System Directory Server or Microsoft Active Directory, as described in Chapter 10, "External LDAP Security Providers". The external LDAP provider implements the login module LDAPLoginModule.

• Custom security providers

  Oracle Application Server allows you or a third party to implement a custom security provider using custom login modules to implement special authentication functionality for an application, as described in Chapter 9, "Login Modules". A custom login module implements the standard JAAS login module interface. You can configure custom login modules when you deploy an application through Oracle Enterprise Manager 10g. The configuration is stored in the OC4J system-jazn-data.xml file.

  Support for custom login modules is implemented through an extension of the file-based provider.

• Oracle Access Manager (formerly Oracle COREid Access and Identity)

  Beginning with OC4J 10.1.3.x implementations, an additional choice for security provider is Oracle Access Manager, as described in Chapter 11, "Oracle Access Manager". This is an enterprise-class authentication, authorization, and auditing solution that provides centralized security administration. This includes functionality for access control, single sign-on (separate from Oracle Single Sign-On), personalization, and user profile management in heterogeneous application environments across a variety of application servers, legacy applications, and databases. Oracle Access Manager implements the login module CoreIDLoginModule.

Note:

Note the following terminology in this document:

• The terms "file-based provider" and "XML-based provider" (sometimes referred to as "JAZN-XML") are equivalent.

• In the context of Oracle Application Server, the term "LDAP-based provider" (also sometimes "JAZN-LDAP") refers to Oracle Identity Management and its repository, the Oracle Internet Directory.

• In OC4J 10.1.3.x implementations, the term "custom security provider" is essentially synonymous with "custom login module".

Figure 3-1 shows how the supported security providers interact with the overall security provider framework.

Figure 3-1 OC4J Security Architecture

Description of "Figure 3-1 OC4J Security Architecture"

Introducing Authentication Features in the OC4J Environment

This section discusses the following topics relating to authentication in OC4J:

• Supported Web Application Authentication Methods

• Overview of OC4J Login Modules

• Overview of Oracle Application Server Single Sign-On Alternatives

• JAZNUserManager Delegation (File-Based Provider)

Supported Web Application Authentication Methods

OC4J supports the standard basic, digest, form, and client-cert authentication methods. These are summarized in "Web Application Standard Authentication Methods", and configured in the standard web.xml file. Details are provided in "Specifying the Authentication Method (auth-method)".

OC4J also supports various single sign-on authentication methods supplied with Oracle Application Server and OC4J. These are summarized in "Overview of Oracle Application Server Single Sign-On Alternatives" below, which includes cross-references for further information.

Overview of OC4J Login Modules

Oracle supplies the following login modules:

• RealmLoginModule, the default login module for the file-based provider or Oracle Identity Management, discussed in "RealmLoginModule"

• LDAPLoginModule, for external LDAP providers, discussed in "Overview of External LDAP Provider Configuration and Administration"

• DBTableOraDataSourceLoginModule, for user repositories in a database (replaces previous functionality of the DataSourceUserManager class), discussed in "DBTableOraDataSourceLoginModule"

• CoreIDLoginModule, for use with Oracle Access Manager, discussed in "Configure the Oracle Access Manager Login Module"

OC4J also supports any custom login module that adheres to login module standards, as discussed throughout Chapter 9, "Login Modules".

Overview of Oracle Application Server Single Sign-On Alternatives

Single sign-on is a feature that lets a user log in just a single time to access multiple Web applications within an OC4J instance or cluster. The following single sign-on authentication methods are Oracle-specific. Usage of these methods is indicated by configuration in the Oracle orion-application.xml file rather than the standard web.xml file.

• SSO

  For this authentication method, OracleAS Single Sign-On is used to authenticate users. This requires an Oracle Application Server infrastructure that includes Oracle Identity Management, Oracle Internet Directory, and OracleAS Single Sign-On. You can find information about OracleAS Single Sign-On in Chapter 8, "Oracle Identity Management".

• COREIDSSO

  For this authentication method, Oracle Access Manager single sign-on (distinct from OracleAS Single Sign-On) is used to authenticate users. This requires an infrastructure that includes Oracle Access Manager. You can find information about Oracle Access Manager SSO in Chapter 11, "Oracle Access Manager".

• CUSTOM_AUTH (for Java Single Sign-On)

  New with the OC4J 10.1.3.1 implementation, Java SSO is a an alternative SSO solution packaged with OC4J for customers who desire a smaller deployment environment. When Java SSO is properly configured and enabled, a CUSTOM_AUTH setting (which is for the OC4J identity management framework, introduced in "Overview of General-Use Identity Management Frameworks and APIs") will enable Java SSO (which is a default implementation of the identity management framework). Java SSO is packaged as part of the OC4J container itself and requires no additional infrastructure. You can find information about Java SSO in Chapter 14, "OC4J Java Single Sign-On".

JAZNUserManager Delegation (File-Based Provider)

The OracleAS JAAS Provider JAZNUserManager coordinates authentication in OC4J. For a Web application, before HTTP requests can be dispatched to a target servlet, JAZNUserManager gets the authenticated user information (set by the Oracle HTTP Server mod_osso module for SSO, for example) from the HTTP request object, and sets the JAAS subject in OC4J.

JAZNUserManager supports a delegation model as detailed below, but effectively this applies only to the file-based provider. With delegation, if a user or group is not found at the application-level JAZNUserManager instance, the request is delegated to the parent user manager.

Specifically, note the following restrictions and additional details:

• If the application and parent application are both configured to use the file-based provider, delegation goes up through the parent hierarchy as far as necessary, until a parent is not configured to use the file-based provider. Delegation is not propagated beyond that point.

• If the application is configured to use the file-based provider, and the parent is configured to use the LDAP-based provider, an external LDAP provider, or a custom login module, there is no delegation support.

• If the application itself is configured to use the LDAP-based provider, an external LDAP provider, or a custom login module, there is no delegation support.

Important:

This also applies with a developer-supplied UserManager implementation instead of JAZNUserManager. However, developer-supplied UserManager classes are deprecated in OC4J 10.1.3.x implementations, and will be desupported in a future release. Use custom login modules instead.

Note:

In OC4J, the system application is at the root of the hierarchy, but the default application is the default parent of any deployed application. Both use system-jazn-data.xml as the user repository.

See Also:

• "Web Application Standard Authentication Methods"

Introducing Authorization Features in the OC4J Environment

Authorization in the OC4J environment includes the following features, detailed in Chapter 5, "Authorization in OC4J":

• Support for Java 2 security and code-based policy management, including use of the standard java2.policy file

• "JAAS mode" setting, which determines security behavior related to functionality of the standard Subject class doAs() and doAsPrivileged() methods

• Granting, checking, and revoking permissions; Oracle permission classes RMIPermission, AdminPermission, RoleAdminPermission, JAZNPermission, and RealmPermission

• JAAS policy management

• Implementation of the Java Authorization Contract for Containers

Overview of Security Role Mapping

OC4J enables you to map a J2EE logical role (or simply "J2EE role") defined in a standard descriptor to a deployment role (referred to as a JAAS role in a previous version of this document) so that a user who is a member of a given deployment role has access to resources that are accessible from the associated J2EE role. Deployment roles are defined in the security provider—for example, in system-jazn-data.xml for the file-based provider, in Oracle Internet Directory for the LDAP-based provider, or in an external LDAP provider, custom login module, or Oracle Access Manager.

The basic steps in security role configuration and mapping are as follows:

1. Specify J2EE logical roles, through standard J2EE functionality, in deployment descriptors such as web.xml and ejb-jar.xml. There is nothing OC4J-specific in this step. A J2EE role is declared in a <security-role> element.

2. As applicable, specify security role references to link application logical roles (roles defined in your application code) to J2EE roles declared through <security-role> elements. This is accomplished in standard deployment descriptors through <security-role-ref> elements. Through this mechanism, you can adjust your definitions of logical security roles without having to change your application code, then simply link J2EE logical roles to application roles as desired. There is nothing OC4J-specific in this step.

3. Configure deployment roles, or use default roles. For the file-based provider, for example, deployment roles are defined in the OC4J system-jazn-data.xml file, or optionally in an application-specific jazn-data.xml file. For the LDAP-based provider, deployment roles are defined in Oracle Internet Directory.

4. Map J2EE roles to deployment roles. You can accomplish this through Application Server Control, and mappings are reflected in <security-role-mapping> elements in orion-application.xml, orion-ejb-jar.xml, or orion-web.xml.

See Also:

• "Mapping Security Roles"

• "Web Application Security Role and Constraint Configuration"

• "Authenticating and Authorizing EJB Applications"

Overview of General-Use Identity Management Frameworks and APIs

The OC4J 10.1.3.1 implementation includes new general-purpose support for third-party identity repositories, with the following features:

• A pluggable identity management framework that allows integration of heterogeneous third-party systems into OC4J, hence allowing any J2EE application to interoperate with these third-party systems. Integration of third-party identity management systems into OC4J is based on standard JAAS login modules.

  Chapter 13, "Pluggable Identity Management Framework" describes how to use this framework, with discussion of its programmatic interfaces, configuration features, and so on.

  Note that Java SSO, an alternative Java single sign-on solution that does not rely on additional infrastructure required by other single sign-on products, is implemented through the pluggable identity management framework. Java SSO is discussed in Chapter 14, "OC4J Java Single Sign-On".

• An identity management API framework for accessing user and role information from disparate identity management repositories. This user and role API framework allows applications to access identity information (users and roles) in a uniform and portable manner regardless of the particular underlying identity repository. The underlying repository could be an LDAP directory server such as Oracle Internet Directory, Active Directory (from Microsoft), or Sun Java System Directory Server (from Sun Microsystems), or could be a database, flat file, or some other custom repository. Supported operations include searching, creating, updating, or deleting users and roles.

  To avoid confusion with the pluggable identity management framework discussed in Chapter 13, which is independent, we refer to the identity management API framework as the "user and role APIs" or "user and role API framework". Chapter 12, "User and Role API Framework", describes how to use these APIs.