|Oracle® Application Server Certificate Authority Administrator's Guide
Part Number B15989-01
Oracle Application Server Certificate Authority provides secure mechanisms whereby it creates and signs X.509 v3 digital certificates for clients and servers. OracleAS Certificate Authority enforces policies chosen or created by its administrator, as described in Chapter 6, and is controlled by that administrator through the scalable web-based interface described in Chapter 5. OracleAS Certificate Authority provides a secure infrastructure for supporting and managing such certificates, including the web-based user interface described in Chapter 8.
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 standalone.
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 an Enterprise Identity Management Solution
The Oracle Identity Management Infrastructure is discussed further in the following sections:
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 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.
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 earlier, 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, address book and so on. These components rely on OCA 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 OCA support the secure authentication needed for simple, fast, consistent identity management.
An application user authenticating to OracleAS Single Sign-On 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, 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.
The OCA administrator can optionally configure OracleAS Certificate Authority to broadcast its URL through OracleAS Single Sign-On. Doing so enables users authenticating through OracleAS Single Sign-On to use OCA's easy graphical interface to apply for a certificate. Having such a certificate makes future OracleAS Single Sign-On authentication even easier, because OracleAS Single Sign-On can then use Oracle Internet Directory to validate the certificate automatically supplied by the user's browser. OracleAS Single Sign-On can rely on the information in the directory because OracleAS Certificate Authority 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.
OracleAS 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:
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 OCA 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, for example, if security has been compromised. (Stopping and starting OracleAS Certificate Authority require the administrator to use the command-line tool
ocactl, which requires his password.)
The end-user web interface for OCA 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 OracleAS Single Sign-On name and password to authenticate yourself. When you choose OracleAS Single Sign-On authentication and click Submit, an OracleAS Single Sign-On window appears in which you can enter your OracleAS Single Sign-On 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 OracleAS Certificate Authority supports; otherwise English is the language used. While the administrative command line tool,
ocactl, uses only commands in English, messages (informational, error messages, and so on) are displayed in the language of the server locale, if supported; otherwise English appears.
OracleAS 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 S/MIME 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 S/MIME.
To create the SMIME wallet required for encrypted or signed email, see "Regenerating the CA SSL and CA S/MIME Wallets" in Chapter 7, "OracleAS Certificate Authority Administration: Advanced Topics".
To configure OCA to use SMIME, see "Notification Sub-tab" in Chapter 5, "Configuring Oracle Application Server Certificate Authority".
For general SMIME operations, see Appendix G, "S/MIME with OracleAS Certificate Authority".
Manual provisioning has an administrator issuing certificates to users. The automatic provisioning provided by Oracle Application Server Certificate Authority using OracleAS Single Sign-On and SSL reduces the costs and delays of conventional methods for supporting PKI.
For OracleAS Single Sign-On authentication, OracleAS Certificate Authority uses mod_osso and OracleAS Single Sign-On. These methods simplify certificate management by helping OracleAS Certificate Authority issue certificates to users who have been authenticated automatically by OracleAS Single Sign-On.
A user who has previously been issued an X.509v3 certificate can submit that certificate over HTTPS as a means of authenticating to OracleAS Certificate Authority. Assuming the certificate was issued by the same OracleAS 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.
OracleAS Single Sign-On and Oracle Internet Directory constitute the default user management and authentication platform. Oracle Application Server Certificate Authority uses Oracle Internet Directory as the storage repository for certificates. This architecture provides centralized certificate management, simplifying certificate provisioning and revocation.
OracleAS 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 OracleAS Single Sign-On can choose to request a digital certificate from OracleAS Certificate Authority. OracleAS Single Sign-On can make this easy by displaying a "get certificate" pop-up page, if OracleAS Certificate Authority 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 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 authentication will then fail.
For more information, see Appendix E, "Enabling SSL and PKI on SSO".
Oracle Application Server Certificate Authority supports certificate-based authentication, so a user's prior, unrevoked X.509 v3 certificate will authenticate that user to OracleAS Certificate Authority over HTTPS. Having thus authenticated the user, OracleAS 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. OracleAS 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 OracleAS 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.
OracleAS 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.
OracleAS 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 OracleAS 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.
See Also:Appendix B, "Setting up a CA Hierarchy"
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.