|
Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2) Part No. B14080-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Certificate Authority Administrator's Guide
10g Release 2 (10.1.2) Part No. B14080-01 |
|
|
Previous |
Next |
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:
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
The Oracle Identity Management Infrastructure is discussed further in the following sections:
Role of Oracle Identity Management in the Oracle Security Architecture
Role of OracleAS Certificate Authority in 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
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.
Each of the Oracle technology stacks (namely, Oracle Database (the RDBMS), Oracle Application Server 10g, the E-business Suite, and Oracle 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
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, Oracle 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."
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.
An application user authenticating to the OracleAS Single Sign-On 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 OracleAS Single Sign-On Server, providing increased security. The issued PKI certificate is automatically published in the Oracle Internet Directory. 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 OracleAS Single Sign-On Server. Doing so enables users authenticating through OracleAS Single Sign-On Server to use OCA's easy graphical interface to apply for a certificate. Having such a certificate makes future OracleAS Single Sign-On ServerOracleAS Single Sign-On Server authentication even easier, because OracleAS Single Sign-On Server can then use Oracle Internet Directory to validate the certificate automatically supplied by the user's browser. OracleAS Single Sign-On Server can rely on the information in the directory because OCA automatically deletes revoked and expired certificates from the directory on a regular basis.
While OCA is part of Oracle Identity Management and Oracle products are tightly integrated, Oracle products also work with any standards-compliant certificate authority. Oracle Wallet Manager, the certificate provisioning tool, will work with any X.509-v3-standard-compliant certificate authority.
|
See Also: For detailed information on Oracle Wallet Manager, see Oracle Application Server Administrator's Guide and Oracle Application Server Security Guide. |
Oracle Wallet Manager can support any existing server certificates that are presented in PKCS#12 format. For instructions on importing such certificates, see the section entitled "Importing Certificates and Wallets Created by Third Parties" in Oracle Application Server Administrator's Guide.
Oracle Application Server Single Sign-On and Oracle Internet Directory work with any third-party standards-compliant certificate authority. For instructions on how to load certificates from such a third-party into Oracle Internet Directory and enable them for PKI authentication with Single Sign-On, see Chapter 7 of Oracle Application Server Single Sign-On Administrator's Guide.
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:
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 lists (CRLs)
Certificate requests using Microsoft Internet Explorer and Netscape Communicator
Multiple enrollment protocols for certificate requests such as Signed Public Key and Challenge (SPKAC) and Public Key Cryptography Standard (PKCS) #10 for certificate requests
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.
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 (installing) 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 OracleAS Single Sign-On Server authentication and click Submit, an OracleAS Single Sign-On Server window appears in which you can enter your OracleAS Single Sign-On Server 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, save the CRL (Certificate Revocation List) to disk or install it in your browser, or change your method of authentication.
When you click the Server/SubCA Certificates tab, you can request a new Server/SubCA certificate, save the CRL to disk or install it in your browser, or save or install the CA certificate. You can also search for particular certificates or certificate requests by ID/Serial number or by common name.
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 administrative 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.
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:
An OracleAS Certificate Authority administrator can use OCA's command line tool to create an SMIME certificate and wallet readily used by OCA and email clients (Outlook, Mozilla/Netscape). Sending and receiving encrypted or signed email becomes easy. The OCA administrator can use the secure web interface to configure OCA notifications and alerts to use SMIME.
|
See Also: To create the SMIME wallet required for encrypted or signed email, see "Regenerating the CA SSL and CA SMIME Wallets" in Chapter 6, "OracleAS Certificate Authority Administration: Advanced Topics". To configure OCA to use SMIME , see "Notification Sub-tab" in Chapter 4, "Configuring Oracle Application Server Certificate Authority". For general SMIME operations, see Appendix G, "SMIME with OracleAS Certificate Authority". |
Conventional provisioning has an administrator issuing certificates to users. The automatic provisioning provided by Oracle Application Server Certificate Authority using OracleAS Single Sign-On Server and SSL reduces the costs and delays of conventional methods for supporting PKI.
For OracleAS Single Sign-On Server 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 OracleAS Single Sign-On Server.
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:
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 OracleAS Single Sign-On Server authentication will then fail.
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.
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 acceptable to Oracle Application Server Certificate Authority 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 save or install existing certificates. Server and subordinate CA's can also request certificates using this manual process.
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.
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)
and optionally Oracle Single Sign-on Server
|
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 Installation Guide.
|
Note: The OracleAS Certificate Authority schema in one repository can only be used with one OCA.When installing another OracleAS Certificate Authority, you must not choose a repository that has been used to install an earlier OCA: the OCA configuration tool will fail.This failure will force you to exit and restart the whole installation. |
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 OracleAS Single Sign-On Server and Oracle Internet Directory 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 Installation Guide.
Figure 2-4 Oracle Application Server Certificate Authority Default Installation
Figure 2-5 OracleAS Certificate Authority Recommended Production Installation
