2
Identity Management and
OracleAS Certificate Authority Features

Oracle Application Server Certificate Authority (OCA) provides secure mechanisms whereby it creates and signs X.509 v3 digital certificates for clients and servers. OCA enforces policies chosen or created by its administrator, as described in Chapter 5, and is controlled by that administrator through the scalable web-based interface described in Chapter 4. OCA provides a secure infrastructure for supporting and managing such certificates, including the web-based user interface described in Chapter 7.

This chapter describes the architecture enabling Oracle Application Server Certificate Authority features and operations, in the following sections:

Identity Management Components and Architecture

A complete identity management solution includes the following components:

A scalable, secure, and standards compliant directory service for storing and managing the user information.
A user provisioning framework that can either be linked to the enterprise provisioning system (such as an HR application), or that can be operated stand-alone.
A delegated administration model and application that allows the administrator of the identity management system to selectively delegate access rights to the administrator of the individual application, or to the end-user directly.
An appropriate security model, and user-interface model, that can support diverse requirements is critical.
A directory integration platform that enables the enterprise to connect the Identity Management directory with legacy or application-specific directories.
A run-time model and application for user authentication.
A system to create and manage PKI certificates.

A model for an enterprise identity management solution is shown in Figure 2-1:

Figure 2-1 A Model for Enterprise Identity Management Solution

Text description of modelent.gif follows.

Text description of the illustration modelent.gif

The Oracle Identity Management Infrastructure is discussed further in the following sections:

Oracle Identity Management

Oracle Identity Management is an integrated infrastructure that Oracle products rely on for securing users and applications across the enterprise. Oracle Application Server is the primary release vehicle for Oracle Identity Management; however, it also ships as part of the infrastructure with other Oracle products. The Oracle Identity Management infrastructure includes the following components:

Oracle Internet Directory, a scalable, robust LDAP V3-compliant directory service implemented on the Oracle Database.
Oracle Directory Integration and Provisioning that permits synchronization between Oracle Internet Directory and other directories and automatic provisioning services for Oracle components and applications and, through standard interfaces, third-party applications.
Oracle Delegated Administration Service, which provides trusted proxy-based administration of directory information by users and application administrators. This can be leveraged by applications such as portal, email, and others.
OracleAS Single Sign-On, which provides end-users single sign-on access to Oracle and third-party web applications.
Oracle Application Server Certificate Authority, which generates and publishes X.509 V3 certificates to support PKI based strong authentication methods.

Figure 2-2 Enterprise-Integrated Identity Management

Text description of enterpriseintegratedim.gif follows.

Text description of the illustration enterpriseintegratedim.gif

Leveraging Oracle Identity Management in the Enterprise

While Oracle Identity Management is designed to provide an enterprise infrastructure for Oracle products, it also serves as a robust and scalable identity management solution for custom and third-party enterprise applications, hardware and network operating systems of the enterprise.

In addition, Oracle works with third-party application vendors to ensure their applications can leverage Oracle Identity Management out of the box

Role of Oracle Identity Management in the Oracle Security Architecture

Each of the Oracle technology stacks (namely, the RDBMS, the Application Server, the E-business Suite, and the Collaboration Suite) supports a security model that is appropriate for its design center. Nevertheless, they all employ the Oracle Identity Management infrastructure for implementing their respective security models and capabilities. Figure 2-3 diagrams this architecture:

Figure 2-3 Oracle Identity Management Security Model

Text description of imsecumodel.gif follows.

Text description of the illustration imsecumodel.gif

OracleAS supports a J2EE-compliant security service called Java Authentication and Authorization Service (JAAS). JAAS can be configured to utilize users and roles defined in Oracle Internet Directory. Similarly, the database security capabilities, "Enterprise User" and "Oracle Label Security" provide the means to leverage users and roles defined in the Oracle Internet Directory. Both these platforms, thus, facilitate the applications developed using their respective native security capabilities to transparently leverage the underlying Identity Management infrastructure.

Oracle Collaboration Suite and the Oracle E-Business Suite are application stacks layered over the RDBMS and iAS platforms. As described above, this layering itself brings a level of indirect integration with the Oracle Identity Management infrastructure. In addition, these products also have independent features that are Oracle Identity Management reliant. For instance, Collaboration Suite components such as E-Mail and Voice mail use the Oracle Internet Directory to manage product-specific user preferences, user personal contacts and address book etc. These components rely on Oracle Application Server Certificate Authority for enabling secure email.

These Oracle technology products also leverage the Provisioning Integration services to automatically provision and de-provision user accounts and privileges. The Delegated Administration Service is employed extensively for self-service management of user preferences and personal contacts. Also, the security management interfaces of these products leverage the user and group management building blocks called the "service units."

Role of OracleAS Certificate Authority in Oracle Identity Management

Oracle Application Server Certificate Authority leverages the Oracle Identity Management Infrastructure through its use of Oracle Internet Directory and Single Sign-on. The directory enables publishing certificates upon issuance and propagating the information to all connected databases. Single Sign-on provides the standard interface relied upon by applications and other Oracle components, such as the enterprise user and secure email facilities in Oracle Collaboration Suite. The certificates issued by Oracle Application Server Certificate Authority support the secure authentication needed for simple, fast, consistent identity management.

Simplified Provisioning through SSO Integration

An application user authenticating to the OracleAS Single Sign-On (SSO) Server can seamlessly obtain a certificate without technical education or understanding of PKI. The application can thereafter use the newly issued certificate for transparently authenticating that application user to SSO, providing increased security. The issued PKI certificate is automatically published in the Oracle Internet Directory (OID). In providing this powerful functionality, Oracle leverages the security, high availability and scalability of the Oracle Database, Oracle Internet Directory, and OracleAS Single Sign-On Server.

The Oracle Application Server Certificate Authority (OCA) administrator can optionally configure OCA to broadcast its URL through SSO. Doing so enables users authenticating through SSO to use OCA's easy graphical interface to apply for a certificate. Having such a certificate makes future SSO authentication even easier, because SSO can then use OID to validate the certificate automatically supplied by the user's browser. SSO can rely on the information in the directory because OCA automatically deletes revoked and expired certificates from the directory on a regular basis.

Key Features of Oracle Application Server Certificate Authority

Oracle Application Server Certificate Authority's key features are accessible through a scalable, web-browser interface. These features support administering industry-standard certificates, integrating with LDAP directories, and applying policies, as described in the following sections:

Support for Open Standards

Oracle Application Server Certificate Authority supports open standards, assuring organizations that they will be able to communicate with heterogeneous computing environments. Oracle Application Server Certificate Authority supports the following standards:

X.509 version 3 certificates and certificate revocation list (CRL)
IETF PKIX standard
Signature key lengths of up to 4096 bits (RSA)
Smart cards
Certificate requests using Microsoft Internet Explorer and Netscape Communicator
Various PKCS Standards (5, 7, 8, 10, 12, etc.)
Multiple enrollment protocols for certificate requests such as Signed Public Key and Challenge (SPKAC) and Public Key Cryptography Standard (PKCS) #10 for certificate requests

Flexible Policy

A policy is a set of rules and restrictions that limits the actions, access, or authorizations that users are permitted to use. Oracle Application Server Certificate Authority provides a set of configurable policy rules that can be used to restrict the certificate properties that a user (or a group of users) can get. A site can customize these rules to configure Oracle Application Server Certificate Authority for its particular PKI requirements. A few default policy rules are provided, and customers can develop and apply their own policy rules as well.

Ease of Use for Administrators and End Users

The administrative web interface for Oracle Application Server Certificate Authority provides two primary tabs: Certificate Management and Configuration Management. To use them, the administrator must enroll by filling out a form upon first entry and then importing his certificate.

The Certificate Management tab gives the administrator the ability to approve or reject certificate requests and to generate or update CRL's (Certificate Revocation Lists). The administrator can also revoke issued certificates for various reasons, e.g., if security has been compromised. (Stopping and starting OCA require the administrator to use the command-line tool ocactl, which requires his password.)

The end-user web interface for Oracle Application Server Certificate Authority also provides two tabs: a User Certificates tab and a Server/SubCA Certificates tab. When you click the User Certificates tab, you can use your Oracle Single sign-on name and password to authenticate yourself. When you choose SSO authentication and click Submit, an SSO window appears in which you can enter your SSO username and password.

When the User Certificates page appears, it shows you all certificate requests and their status (pending, approved, rejected), among other information. You can request a new certificate, download the CRL (Certificate Revocation List), or change your method of authentication.

When you click the Server/SubCA Certificates tab, you can request a new Server/SubCA certificate, download the CRL, or download the CA certificate. You can also search for particular certificates or certificate requests by ID/Serial number or by common name.

National Language Support (NLS) for OCA Screens

The administrative and user screens for OracleAS Certificate Authority can appear in the language of the client or of the server, if certain prerequisites are met. The database character set must be UTF8, and the required language must be one of the many that OCA supports; otherwise English is the language used. While OCA's command line tool, ocactl, uses only commands in English, messages (informational, error messages, etc.) are displayed in the language of the server locale, if supported; otherwise English appears.

Scalability, Performance, and High Availability

Oracle Application Server Certificate Authority automatically attains these benefits through integration with OracleAS as the application server and with the Oracle database as the repository for the following information:

Users, roles, and privileges
Pending and approved certificate requests
Certificates issued

Automatic or Conventional Provisioning

Conventional provisioning has an administrator issuing certificates to users. The automatic provisioning provided by Oracle Application Server Certificate Authority using SSO and SSL reduces the costs and delays of conventional methods for supporting PKI.

For SSO authentication, Oracle Application Server Certificate Authority uses mod_osso and Oracle Single Sign-on server. These methods simplify certificate management by helping Oracle Application Server Certificate Authority issue certificates to users who have been authenticated automatically by SSO.

A user who has previously been issued an X.509v3 certificate can submit that certificate over HTTPS as a means of authenticating to the Oracle Certificate Authority. Assuming the certificate was issued by the same Oracle Certificate Authority and has not been revoked, the certificate request will be approved automatically. Swift approval allows the user to get additional certificates for encryption or signing without the delay of waiting for the administrator or security officer to approve the request.

OCA can also support smart cards through Netscape and Internet Explorer integration, and display its forms in the language determined by the browser's locale setting.

Oracle Application Server Certificate Authority supports the following authentication methods, explained in the following sections:

Oracle Single Sign-on Authentication

OracleAS Single Sign-On Server and Oracle Internet Directory constitute the default user management and authentication platform. The Oracle Certificate Authority uses Oracle Internet Directory as the storage repository for certificates. This architecture provides centralized certificate management, simplifying certificate provisioning and revocation.

Oracle Application Server Certificate Authority's integration with OracleAS Single Sign-On Server and Oracle Internet Directory provides seamless certificate provisioning mechanisms for applications relying on them. A user provisioned in the Oracle Internet Directory and authenticated to the OracleAS Single Sign-On Server can choose to request a digital certificate from the Oracle Certificate Authority. The OracleAS Single Sign-On Server can make this easy by displaying a "get certificate" pop-up page, if OCA is configured as explained in the section entitled Simplified Provisioning through SSO Integration. The user can authenticate with username/password, an existing SSL certificate, or both. The user simply clicks the Request a Certificate button and a certificate will be automatically and immediately provisioned in the Oracle Internet Directory.

This method leverages the ability of OracleAS Single Sign-On Server to identify the user and to populate required fields in the certificate request by using data from Oracle Internet Directory. Similarly, the Oracle Certificate Authority administrator or certificate owner can revoke a certificate in real time, automatically causing it to be deleted from Oracle Internet Directory. Future attempts to use that certificate for SSO authentication will then fail.

Secure Socket Layer (SSL-based) Authentication

Oracle Application Server Certificate Authority supports certificate-based authentication, so a user's prior, unrevoked X.509 v3 certificate will authenticate that user to Oracle Application Server Certificate Authority over HTTPS. Having thus authenticated the user, Oracle Application Server Certificate Authority can automatically issue a new certificate for SSL, for signatures, or for other purposes without delay.

Manual Approval

An organization's security policy can dictate that requests for certificates be approved manually rather than allowing certificates to be issued by an automatic process. If this choice is made, the more conventional manual mode of approval and authentication will be used, and the Single Sign-on and SSL modes will be turned off. Oracle Certificate Authority can enforce such an approval process, requiring an administrator or security officer to manually verify the identify of the requestor.

For manually approved authentication, the certificate requests that Oracle Application Server Certificate Authority accepts use the basic input fields required by all CAs. This manual process requires the user to provide personal information, such as name, email address, and location. (Users can optionally supply advanced DN attributes, such as domain components, customizing the certificate request.) The manual method is considered more complex than Oracle Single Sign-on Authentication or Secure Socket Layer Authentication. However, it also affords users the additional options to view and download existing certificates. Server and subordinate CA's can also request certificates using this manual process.

Hierarchical Certificate Authority Support

Oracle Application Server Certificate Authority supports a hierarchy of certificate authorities. In a hierarchical PKI, the root CA for a security domain is the original single CA that is ultimately trusted by all users. Its identity serves as the beginning of trust paths.

Oracle Application Server Certificate Authority can be a root CA. It can also certify the certificate of another CA, thereby creating a subordinate CA. Alternatively, the signing/SSL certificate of a subordinate installation can be obtained from another Oracle Certificate Authority installation or any standards-compliant certificate authority. This subordinate CA can in turn issue certificates to even lower-level CAs. Because each authority's certificate is signed by a higher CA, a user can verify the certificate chain by tracing the certificate authority path back to a higher authority he trusts, or to the root CA.

Obtaining the sub/CA certificate from a separate certificate authority is useful when a PKI infrastructure is already in place. Hierarchical CA support is useful in a geographically distributed organization.

Using a hierarchical CA also provides important additional benefits in cost and safety, enabling a sub-CA to conduct normal operations while the root CA is especially protected. Such protection can include being off-line in a highly secure location. In this way, even if an online subordinate CA is compromised, it can be revoked and a new sub-CA created to replace it. All earlier operations can continue using certificates as issued. However, if the root CA is compromised, a completely new infrastructure needs to be established, and all applications relying on it need to be updated.

Deployments and Installations

Oracle Application Server Certificate Authority (OCA) can work with several different deployment strategies for the following components that OCA needs:

Oracle HTTP Server (OHS) (must be on the same machine as OCA)
OC4J for OCA (must be on the same machine as OCA)
Infrastructure metadata repository
Oracle Internet Directory (OID)
and optionally Oracle Single Sign-on Server (SSO)

Note:
OCA is not automatically selected for installation, that is, as a default selected choice. To install OCA, you must select it for installation.

In the default deployment, all these components are on the same machine and in the same Oracle Home, as shown in Figure 2-4. This configuration is ideal for development and non-production environments, and is the default installation configuration. The installation instructions for this default deployment configuration of OCA appear in Section 6.14 of the Oracle Application Server 10g Installation Guide.

In the recommended production deployment, OHS, OC4J, OCA and the infrastructure metadata repository will be on one machine, in one Oracle Home. The remaining components like SSO and OID will be on a different machine, in a different Oracle Home. This physical separation makes it possible to harden the security of that separate location, to protect OCA in a very secure location. Since OCA is at the top of the trust chain for certificates, these additional protections are prudent in a production environment, as is illustrated in Figure 2-5. Similarly, it is better for Oracle Application Server Certificate Authority security reasons not to use Enterprise Manager for starting or stopping these components.

Installation instructions for this recommended deployment configuration appear in Section 6.20 of the Oracle Application Server 10g Installation Guide.

Figure 2-4 Oracle Application Server Certificate Authority Default Installation

Text description of defaultinstlnnewocaag.gif follows.

Text description of the illustration defaultinstlnnewocaag.gif

Figure 2-5 Oracle Application Server Certificate Authority Recommended Production Installation

Text description of rxdprodninstlnnewocaag.gif follows.

Text description of the illustration rxdprodninstlnnewocaag.gif

2 Identity Management and OracleAS Certificate Authority Features