Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
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
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
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:
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:
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.
Authenticate the user attempting to log in, which is the role of the security provider.
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.
Table 3-1 summarizes JAAS framework features implemented by the OracleAS JAAS Provider.
Table 3-1 JAAS Framework Features
Feature | Description | See Also |
---|---|---|
"Introducing Authentication Features in the OC4J Environment" |
||
Declarative model |
|
|
Authorization |
|
"Authorization APIs, JAAS Mode, and JACC in the OC4J Environment" |
|
||
|
||
Administration |
|
"Tools for Oracle Application Server and 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.)
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.
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
.
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.
This section discusses the following topics relating to authentication in OC4J:
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.
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".
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".
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-suppliedUserManager
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, thesystem
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.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
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:
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.
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.
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.
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
.
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.