Enables use of a single password for authentication when establishing an initial connection and transparent authentication in subsequent connections. See the discussion of OracleAS Single Sign-On in Section 4.2.1.
Used for authorization and user provisioning (e.g., supplying relevant user information needed for authentication by other services). See Section 4.2.2.
Based on Apache and includes its own basic security mechanisms to restrict access to directories or URLs. See Chapter 5.
Enables secure access and execution of J2EE applications. JAAS is described in Section 4.2.3.
Used in the authentication process to ensure that entities such as users, databases, and clients are who they say they are. See Section 18.104.22.168.
The discussion of these components in this chapter only scratches the surface. Consult the Appendix for references to more detailed security-related documentation.
You may also consider using other Oracle Application Server components as you develop secure applications, such as OracleAS Web Cache, OC4J, and OracleAS Portal. For information about OracleAS Web Cache, OC4J, and OracleAS Portal, see Chapter 7, Chapter 6, and Chapter 13, respectively.
Figure 4-1 shows a typical Oracle Application Server security deployment architecture.
The Oracle HTTP Server shown in this figure relies on authentication methods that can restrict access to files and services such as basic user authentication (and OracleAS Single Sign-On), client-supplied X.509 certificates, and authentication by IP or hostname addresses. (Oracle Identity Management’s role in authentication is described in the next section.) The Oracle HTTP Server enables intrusion detection by logging authentication attempts. It also extends the more generic Apache HTTP server through Oracle-specific mods such as the one for OracleAS Single Sign-On.
SSL connections are desirable in highly secure environments in which encryption and data integrity are mandated. SSL connections rely on digital certificate authentication using the Public Key Infrastructure (PKI). (See Section 22.214.171.124.) Because OracleAS Web Cache provides a caching front end to the Oracle HTTP Server and proxies requests to Oracle HTTP Server where necessary, OracleAS Web Cache is typically the termination point for SSL connections. However, OracleAS Web Cache can pass the contents of the SSL certificates to the Oracle HTTP Server for further use.
Additional advanced security mechanisms can be implemented with the Oracle HTTP Server. The SSL cryptographic protocol protects data between the Oracle HTTP Server and web clients. Session renegotiation is supported in such a way that different directories can have different degrees of encryption. Because SSL processing can consume a significant portion of CPU resources, Oracle Application Server 10g allows for the use of external dedicated SSL appliances to speed up the encryption process. SSL connections from the Oracle HTTP Server to OC4J are also supported.
The security of J2EE applications using Web Services is usually dependent on the coding of the applications themselves. But such applications can also be integrated as part of a more secure implementation using HTTP authentication, Oracle Wallets (described in a later section), or the UDDI registry. Introduced in Chapter 1, UDDI is essentially a “Yellow Pages” directory in which business entities can register themselves and the services they provide.
Oracle Identity Management provides user authentication, management, and authorization for Oracle Application Server services. Specific components of Oracle Application Server, such as OracleAS Portal, OracleAS Forms Services, OracleAS Reports Services, and OracleAS Discoverer, are designed to leverage Oracle Identity Management as well.
A set of bidirectional services and interfaces that can notify applications and non-Oracle LDAP directories of changes to user information. These services enable synchronization of the Oracle Internet Directory with other repositories, non-Oracle directories, and metadirectories.
The Oracle Internet Directory enables users to be defined by identity, credentials, profiles, and preferences in a single and central location. All other Oracle Identity Management services rely on the Oracle Internet Directory to provide this information.
As noted earlier, Oracle Identity Management isn’t required for all Oracle Application Server deployments. For example, a simple OC4J application might use other identity management services such as Microsoft Active Directory. In other situations, you might choose to use the Oracle Internet Directory preconfigured for directory synchronization with Microsoft Active Directory or other LDAP-compliant directories.
The challenge of managing multiple user accounts in a large
organization can be mitigated by using the Oracle Internet Directory
for identity management. You can use the
Oracle Internet Directory to consolidate separated user definitions
to a single location and also synchronize passwords with non-Oracle
Internet directories. For example, you can synchronize the
orclpassword attribute in the Oracle Internet
Directory with the
userpassword attribute in
Oracle calls this directory-based user management Enterprise User Security . It allows passwords to be maintained for application users in a central location. The identity management infrastructure can also manage database roles and security clearances (for use with the Oracle database’s Label Security feature).
Many users face a proliferation of passwords as they gain access to more applications and systems. Because it is so easy for users to forget passwords when they have so many to remember, users may end up writing them down in public places, thus creating a security risk. Oracle Identity Management can help lift this burden on users by enabling deployment of single sign-on, allowing a single user and password combination across these applications and systems.
Follow these steps to set up a basic single sign-on system:
Configure the HTTP servers in the single sign-on middle tier.
Configure the HTTP hardware load balancer or OracleAS Web Cache.
Configure the identity management infrastructure database single sign-on server to accept authentication requests from an externally published address of the OracleAS Single Sign-On server.
mod_osso (OracleAS Single Sign-On
extension) to the OracleAS Single Sign-On middle tier.
Federated identities are supported in OracleAS Single Sign-On; these allow user identities to be authenticated from one or more trusted authentication sources. Multilevel authentication is also supported and can grant higher privileges with higher degrees of authentication through the use of certificates, which are described in the next section.
Certificates are used in the authentication process to ensure that entities such as users, databases, and clients are who they say they are. An OracleAS Certificate Authority (OCA) can grant a certificate that is signed by the OCA private key and then publish the certificate with the entity’s name and a public key. The certificate also usually includes information about rights, uses, and privileges assigned, a serial number, and an expiration date.
Where data is encrypted using an owner’s private key, it can be decrypted only with a matching public key. Similarly, data encrypted using a public key (usually data to be shared with another entity) can be decrypted only with that entity’s matching private key.
The OracleAS Certificate Authority is critical to creating the public keys. The management of public keys is often said to occur through a PKI.
You can use Oracle wallets as part of the enabling infrastructure in highly secure Oracle Application Server implementations. A wallet is a password-protected container that stores private keys, certificates, and trusted certificates needed by SSL.
Security managers can use the Oracle Wallet Manager to manage passwords, provide Triple-DES encryption for storing private keys associated with X.509 certificates, store wallets in a Microsoft Windows registry, store X.509 certificates and private keys in the PKCS#12 format, and store multiple certificates for each wallet (SSL, S/MIME signature, S/MIME encryption, code-signing, and certificate authority signing). Wallets can be uploaded and retrieved from LDAP-compliant directories.
The Oracle Internet Directory is an LDAP-compliant directory service used for Oracle Application Server user management. The Lightweight Directory Access Protocol is a standard for directories of users and resources. As an LDAP-compliant directory service, the Oracle Internet Directory can interact with other LDAP-compliant directories, mentioned earlier in the description of the Oracle Directory Provisioning and Integration Service.
You may want to configure a highly available Oracle Internet Directory by deploying the Oracle Internet Directory repository across multiple database instances in a RAC configuration. In such a configuration, multiple Oracle database servers appear as a single instance. When you do this, you may also want to use a hardware load balancer as a front end to the multiple Oracle Internet Directory instances. Using RAC and a load balancer can also provide a high-availability OracleAS Single Sign-On service, or you can configure highly available OracleAS Single Sign-On using failover to a standby machine or through Oracle Internet Directory replication.
If you build a RAC configuration, you should consider coordinating the issuing of certificates. For example, keeping private keys in only one location is desirable for security. You can do this by storing the SSL certificate on a hardware accelerator appliance. The SSL session key negotiation and symmetric encryption workload from the Oracle HTTP Server or OracleAS Web Cache would also be handled on the appliance, resulting in better performance.
The Java Authentication and Authorization Service can ensure secure access and execution of J2EE applications. The JAAS provider includes a Java standard framework and programming interface supporting user authentication, authorization, and implementation of JAAS policies (permissions).
J2EE applications can be integrated in an OracleAS Single Sign-On deployment model.
A J2EE application can use JAAS to restrict access to specific users based on the specific authorization permissions they have been granted. For example, consider usage in a retail firm. A contract administrator determines which product suppliers are allowed to deliver to retail store locations. The contract administrator user is given permission to use the application to add suppliers and products to the database. JAAS enables authentication of the contract administrator’s login identification and the authorization needed to update supplier and product information. A store manager might use the same application to monitor shipments from these suppliers to determine when to expect the arrival of inventory. However, if that manager isn’t permitted to negotiate contracts, he would not be given authorization to add suppliers or products to the database.