4 Supported Architectures

Oracle Advanced Authentication (OAA), Oracle Adaptive Risk Management (OARM), and Oracle Universal Authenticator (OUA) can be deployed in a variety of architectures. For ease of deployment however, Oracle recommends the following based on whether you are deploying a production environment, or a sandbox environment.

Production Deployments

For production deployments, administrators should follow the installation instructions in the Enterprise Deployment Guide for Oracle Identity and Access Management in a Kubernetes Cluster.

The Enterprise Deployment guide provides topology diagrams and step by step instructions on how to build a Kubernetes cluster and deploy OAA (with or without OARM and OUA), either on it's own, or with other Oracle Identity Management products. It also provides automation scripts that simplify the installation experience. The automation scripts can:
  • Automate the creation of a Kubernetes cluster on Oracle Cloud Infrastructure (OCI), ready for the deployment of Oracle Identity Management products.
  • Automate the deployment of OAA (with or without OARM and OUA) and other Oracle Identity Management products on any compliant Kubernetes cluster.

Sandbox Deployments

For deploying OAA in a sandbox environment, it is assumed you have an existing Oracle Access Management (OAM) environment. The following is a sample OAM environment that can be used for OAA deployment:

Figure 4-1 OAM Sandbox Deployment


OAM Sandbox Environment

Your OAM environment can be deployed differently to the above, for example you may be terminating SSL at a load balancer in front of OHS, or OUD and the Database are installed on the same server as OAM. However, the following are mandatory requirements:
  • Oracle HTTP Server (OHS) is deployed on it's own server.
  • OHS is used as a proxy to OAM.
  • SSL is either terminated at OHS, or at a load balancer in front of OHS.
  • Oracle Unified Directory (OUD) is configured with sample users and groups, and extended with OAM Object classes.
  • OAM is integrated with OUD and configured to communicate with the OUD LDAP port.
  • OAM consoles are protected using an Oracle WebGate and the policies defined in IAMSuiteAgent.
  • Both OAM administration and OAM runtime URL's use the same hostname, for example https://ohs.oracle.com.

If you do not have an existing OAM environment for use with a sandbox OAA deployment, you can build one following the Configuring Oracle Access Management 12c Sandbox Environment for Oracle Advanced Authentication series.

When OAA, OARM, OUA is deployed the environment will be as follows:

Figure 4-2 OAA and OAM Sandbox Deployment


OAA and OAM Sandbox Environment

After deployment, all OAA URL's will be accessed via the OHS, for example https://ohs.example.com. If using a load balancer in front of OHS then all OAA URL's will be accessed via the load balancer.

Note:

If you intend to use the FIDO2 factor in OAA, administrators should take into consideration that most modern browsers now enforce higher security measures for FIDO2. These browsers will not allow FIDO2 access unless the certificate presented is traceable to a trusted Certificate Authority. Therefore, if you intend to use the FIDO2 factor, the certificate used by OHS (or the load balancer if SSL is terminated there) must be a commerically available certificate, traceable to a trusted Certificate Authority.

Throughout this installation guide, various configuration checkpoints are outlined. These checkpoints take you through basic sanity checks, and gathering variables for the URL's, hostnames, ports, and passwords, that are required later for deployment.

Note:

The installation guide in this documentation is based on deploying on the Oracle recommended sandbox architecture.