C.2 Securing Communication Between OAM Servers and WebGates

Securing communication between OAM Servers and clients (WebGates) means defining the transport security mode for the NAP (also known as the OAP) channel within the component registration page. The security level for the channel is specified as either:

Open: Un-encrypted communication

In Open mode, there is no authentication or encryption between the WebGate and OAM Server. The WebGate does not ask for proof of the OAM Server's identity and the OAM Server accepts connections from all WebGates. Use Open mode if communication security is not an issue in your deployment.
Simple: Encrypted communication through the Secure Sockets Layer (SSL) protocol with a public key certificate issued by Oracle.

Use Simple mode if you have some security concerns, such as not wanting to transmit passwords as plain text, but you do not manage your own Certificate Authority (CA). In this case, OAM Servers and WebGates use the same certificates, issued and signed by Oracle CA.

See About Simple Mode, Encryption, and Keys.
Cert: Encrypted communication through SSL with a public key certificate issued by a trusted third-party certificate authority (CA).

Use Cert mode if you want different certificates on OAM Servers and WebGates and you have access to a trusted third-party CA. In this mode, you must encrypt the private key using the DES algorithm. Access Manager components use X.509 digital certificates in PEM format only. PEM refers to Privacy Enhanced Mail, which requires a passphrase. The PEM (Privacy Enhanced Mail) format is preferred for private keys, digital certificates, and trusted certificate authorities (CAs). The preferred keystore format is the JKS (Java KeyStore) format.

See About Cert Mode Encryption and Files.

Logically the request is to the Access Manager credential collector. However, when you have a Web server proxy in front of the WebLogic AdminServer, with a <LocationMatch "/*">, all requests are routed through the proxy. In this case, there is perimeter defense using the proxy.

Figure C-1 illustrates the communication channels used by OAM Servers and WebGates during user authentication and authorization.

Figure C-1 Communication Channels for OAM Servers and WebGates

Description of "Figure C-1 Communication Channels for OAM Servers and WebGates"

Process overview: Authentication and authorization

Request is intercepted by WebGate.
Authentication (credential collection) occurs over HTTP(s) channel.
Authorization occurs over the NAP channel with OAM Agents only (not mod_osso).

Using the secure-sockets layer (SSL) protocol helps prevent eavesdropping and successful man-in-the-middle attacks across the HTTP (HTTPS) channel. The SSL protocol is included as part of most Web server products and Web browsers. SSL uses the public-and-private key encryption system, which includes the use of a digital certificate. For details about enabling SSL communication for a Web server or directory server, see your vendor's documentation.

The PEM (Privacy Enhanced Mail) format (BASE64-encoded ASCII) is preferred for private keys, digital certificates, and trusted certificate authorities (CAs). The preferred keystore format for OAM Servers is JCEKS and for OAM Clients is JKS (Java KeyStore) format. Access Manager components use X.509 digital certificates in DER (binary form of a certificate) format only.

See:

C.2.1 About Certificates, Authorities, and Encryption Keys

Digital certificates can be stored in a registry from which authenticating users can look up the public keys of other users.

Depending on the public key infrastructure, the digital certificate establishes credentials for Web-based transactions based on:

Certificate owner's name
Certificate serial number
Certificate expiration date
A copy of the certificate holder's public key, which is used to encrypt messages and digital signatures
The digital signature of the certificate-issuing authority is provided so that a recipient can verify that the certificate is real

In cryptography, a public key is a value provided by a designated authority to be used as an encryption key. The system for using public keys is called a public key infrastructure (PKI). As part of a public key infrastructure, a certificate authority checks with a registration authority (RA) to verify information provided by the requestor of a digital certificate. When the RA verifies the requestor's information, the CA can issue a certificate.

Private keys can be derived from a public key. Combining public and private keys is known as asymmetric cryptography, which can be used to effectively encrypt messages and digital signatures.

C.2.2 About Security Modes and X509Scheme Authentication

Administrators must ensure that the OAM Server is reachable only over the transport specified in the OAM Server configuration. OAM Server configuration defines the end points for the Server and accounts for the deployment of load balancers or reverse proxies. When the OAM Server is reachable over both HTTP and HTTPS, all requests (over either transport) are accepted. To allow the user to interact with the OAM Server (and logout) over SSL with non-X509 authentication schemes, the specified Server Port must not be configured to require CLIENT CERTS.

With the X509 authentication scheme (X509Scheme), the OAM Server SSL Port must differ from the Server Port, and must be configured to require Client Certificates. When X509Scheme is used, the X509 module is called after credential collection. X509Scheme requires the X509 challenge method and the X509 authentication module. The fully-qualified URL to the credential collector must be specified as the Challenge URL within X509Scheme. For example: https://managed_server_host:managed_server_ssl_port/oam/CredCollectServlet/X509

Note:

If a relative Challenge URL is specified with X509Scheme, the OAM Server uses the specified Server Host/Port to construct the fully-qualified URL of the X509 Credential Collector. However, this configuration will not work.

C.2.3 The Importcert Tool

Administrators use the Oracle-provided importcert tool for several different procedures related to keystores, keys, and certificates.

Table C-1 provides the syntax for importcert commands.

Table C-1 importcert Command Syntax

Option	Description
keystore	Follow this command with the path to an existing (or new) keystore. For example: /scratch/.oamkeystore or /scratch/clientKey.jks
privatekeyfile	Follow this option with the path to your private key. For example: /scratch/aaa_key.der
signedcertfile	Follow this option with the path to your signed certificate. For example: /scratch/aaa_cert.der
alias	Follow this option with your keystore entry alias. Required with genkeystore.: alias
storetype	Follow this option with your keystore type. By default, the store type is JCEKS (OAM Server keystore). For example: Server keystore .oamkeystore, of type: JCEKS Client keystore/scratch/clientTrustStore.jks and /scratch/clientKey.jks can be used. Both are type: JKS
genkeystore	This flag is required for generating OAM client certificates. The client does not expose the alias and alias password parameters. However, importcert tool sets the keystore password as the alias password. Specify: Yes or No Yes imports the certificates in a new keystore. No imports certificates into an existing keystore.
Sample for OAM Server	- java -cp importcert.jar oracle.security.am.common.tools.importcerts.CertificateImport -keystore <path to .oamkeystore> -privatekeyfile <path to aaa_key.der> -signedcertfile <path to aaa_cert.der> -alias oam.certmode -aliaspassword <password> -storetype <JCEKS> genkeystore <yes> Enter the keystore password and alias password when prompted.
Sample for OAM Client See Also Generating Client Keystores for OAM Tester in Cert Mode	- java -cp importcert.jar oracle.security.am.common.tools.importcerts.CertificateImport -keystore <path to clientkey.JKS> -privatekeyfile <path to aaa_key.der> -signedcertfile <path to aaa_cert.der> -storetype <JKS> genkeystore <yes> Enter the keystore password when prompted.