4 About the IAM Enterprise Deployment
Learn about deploying Oracle Identity and Access Management topologies on commodity hardware. These topologies represent specific reference implementations of the concepts described in About a Typical Enterprise Deployment.
This chapter includes the following topics:
- About the Primary and Build-Your-Own Enterprise Deployment Topologies
There are two primary reference topologies for Oracle Identity and Access Management. While the components installed into each topology are the same, the exact Oracle Identity and Access Management topology you install and configure for your organization may vary. - Using a Demilitarized Zone
Oracle strongly recommends the use of a demilitarized zone (DMZ) to ensure maximum security for your organization. - Topology Diagrams for the Deployment of Oracle Identity and Access Management
There two types of deployment scenarios for Oracle Identity and Access Management. A deployment where you add microservices to an existing enterprise deployment, and the another deployment where you place the entire application tier inside a Kubernetes cluster. - Topology Diagrams for the Deployment of Oracle Identity and Access Management Components on Kubernetes
The sample topologies shown in this section illustrate the deployment of Oracle Identity and Access Management on a Kubernetes cluster by using either an Ingress controller for internal routing or by using individual NodePort Services. - About the Primary Oracle Identity and Access Management Topology Diagrams
The primary enterprise deployment topology is the main Oracle reference topology for Oracle Identity and Access Management. It provides a solution which is both highly available and scalable. - Storage Requirements for an Enterprise Deployment
Preparing the file system for an enterprise deployment involves understanding the requirements for local and shared storage, as well as the terminology that is used to reference important directories and file locations during the installation and configuration of the enterprise topology. - About Permissions
When containers are created, the files owned by the container are owned by the user with UID 1000 and group 1000. - Summary of Microservices and Clusters on the Application Tier
The application tier not only hosts the WebLogic components of Oracle Identity and Access Management, but it also hosts the Microservice components. - About the Forgotten Password Functionality
In Oracle 11g, the mechanism to reset passwords was provided by Oracle Identity Governance. In Oracle 12c, you have two possibilities - by integrating Oracle Access Management (OAM) and Oracle Identity Governance (OIG) or by using Oracle Access Management. - Integrating Oracle LDAP, Oracle Access Manager, and Oracle Identity Governance
Integration of Oracle Identity Manager and Oracle Access Manager with LDAP directories is done by using LDAP Connector. - Roadmap for Implementing the Primary IAM Suite Topologies
This roadmap introduces you to the different tasks that need to be performed for implementing the primary IAM suite topologies on Kubernetes. This guide supports deployments on Oracle Kubernetes Engine (OKE), Oracle Cloud Native Environment, and the on-premises based Kubernetes deployments. - Building Your Own Oracle Identity and Access Management Topology
These step-by-step instructions help you configure the two primary enterprise topologies for Oracle Identity and Access Management. However, Oracle recognizes that the requirements of your organization may vary, depending on the specific set of Oracle Fusion Middleware products you purchase and the specific types of applications you deploy.
Parent topic: About an Enterprise Deployment
About the Primary and Build-Your-Own Enterprise Deployment Topologies
There are two primary reference topologies for Oracle Identity and Access Management. While the components installed into each topology are the same, the exact Oracle Identity and Access Management topology you install and configure for your organization may vary.
This guide provides step-by-step instructions for installing and configuring these topologies.
The components installed into each topology are the same. The difference is that one deployment has all of the Identity Management application tier installed into containers, while the other is a mix of a traditional on-premise deployment with the new microservices deployed into containers.
The topologies depicted in this deployment are the best-practice deployments recommended by Oracle, maximizing security and availability. These topologies have been validated by Oracle.
These are not the only ways of deploying Oracle in a containerized environment; they are Oracle's recommended approach for the deployment of production systems.
To maximize security, Oracle recommends the implementation of a demilitarized zone (DMZ).
Parent topic: About the IAM Enterprise Deployment
Using a Demilitarized Zone
Kubernetes is at its most powerful when used as an application mid-tier. A DMZ is still required to ensure a strictly controlled access to the Kubernetes network. Outside traffic should always be routed through a DMZ to reduce the likelihood of unscrupulous individuals gaining access to your internal network. You ensure maximum network security by placing the web servers outside the Kubernetes network in a DMZ. Placing the Oracle HTTP servers inside Kubernetes ensures that the Kubernetes network is one step closer than it should be to the outside world.
Note:
For an enterprise deployment, Oracle strongly recommends that the web tier is NOT placed inside the Kubernetes cluster containing your business applications, but in a dedicated demilitarized zone.You can create a separate Kubernetes cluster in the demilitarized zone for your web tier. However, it results in unnecessary overhead because you will require a highly available Kubernetes control plane and multiple Kubernetes worker nodes.
This guide does not cover the scenario of including the Oracle web tier inside Kubernetes because Oracle does not recommend this approach.
Parent topic: About the IAM Enterprise Deployment
Topology Diagrams for the Deployment of Oracle Identity and Access Management
There two types of deployment scenarios for Oracle Identity and Access Management. A deployment where you add microservices to an existing enterprise deployment, and the another deployment where you place the entire application tier inside a Kubernetes cluster.
- Topology Diagram for a Traditional IAM Deployment with Additional Microservices
This is the traditional Identity and Access Management deployment on a standalone on-premise hardware. In this topology, the software is distributed across eight hosts: two hosts for the web tier and four hosts for the application tier, and two hosts for the directory services. - Topology Diagram for the Deployment of Oracle Identity and Access Management on Kubernetes
This is a deployment of Identity and Access Management where all components of Identity and Access Management, including Microservices, are deployed into a Kubernetes cluster.
Parent topic: About the IAM Enterprise Deployment
Topology Diagram for a Traditional IAM Deployment with Additional Microservices
This topology is a typical deployment if you are using virtual machines (VMs) that are less powerful, but easy to create and manage. You deploy key components, such as Oracle Access Management, Oracle Identity Governance, and Directory Services on their own dedicated hosts.
The following illustration shows the Oracle Identity and Access Management topology. The diagram is shown with complete separation of components. If you wish to use less hardware, then you can collocate the components as required. For information about the system requirements for each host, see Host Computer Requirements.
Oracle 12c (12.2.1.4) introduces the Oracle Identity Management functionality that is delivered by using microservices. This functionality is delivered in addition to the existing Identity Management functionality that is part of the traditional deployment platform. You must deploy the new microservices inside a Kubernetes cluster. The traditional Identity Management components can be delivered either in a Kubernetes cluster or in a traditional deployment as described in Enterprise Deployment Guide for Oracle Identity and Access Management.
This guide describes how to deploy all the Oracle Identity and Access Management components inside a Kubernetes cluster.
- Deploy the new microservices and integrate them into the
existing Oracle HTTP server deployment.
If you want to follow this deployment method, then use the instructions as described in Installing and Configuring Oracle HTTP Server. This chapter will show the entries you should add to incorporate microservices into the existing virtual hosts.
- Deploy the new microservices completely standalone, using a
dedicated Ingress controller.
If you are following this deployment method, then you should define different virtual hosts for each of the microservices, which will resolve to the Ingress controller that is being used.
Figure 4-1 A Traditional Deployment of Oracle Identity and Access Management with Microservices (in a Kubernetes Cluster)

Topology Diagram for the Deployment of Oracle Identity and Access Management on Kubernetes
This is a deployment of Identity and Access Management where all components of Identity and Access Management, including Microservices, are deployed into a Kubernetes cluster.
The following illustration shows the Oracle Identity and Access Management topology inside Kubernetes. The diagram is shown with complete separation of components. This topology requires that you use a suitably sized Kubernetes cluster.
This guide describes how to deploy all the Oracle Identity and Access Management components inside a Kubernetes cluster.
Figure 4-2 Deployment of Oracle Identity and Access Management in a Kubernetes Cluster

Topology Diagrams for the Deployment of Oracle Identity and Access Management Components on Kubernetes
The control plane consists of three nodes where the Kubernetes API server is deployed and front ended by a load balancer. The load balancer exposes the required VIP and VS for both the Identity Management suite and the control plane itself. This URL should be site agnostic in preparation for disaster recovery configuration. The control plane and worker nodes should resolve this name properly. The database tier consists of a unique RAC DB that hosts the application schemas, JMS/JTA persistent stores, OPSS, and MDS information.An extra load balancer end point maybe created to include all the Kubernetes worker nodes. You can then use this load balancer to distribute requests seamlessly across the available pool of worker nodes.
This section includes the topology diagrams for the following components:
Parent topic: About the IAM Enterprise Deployment
Primary Deployment Topologies
These topologies are the recommended approach suggested by Oracle.
Oracle Unified Directory
Figure 4-3 shows a deployment of Oracle Unified Directory and Oracle Unified Directory Services Manager. Typically, none of the services in this diagram are exposed to the internet.
In a full Kubernetes deployment, interactions with OUD are normally kept inside of the Kubernetes cluster. In this case, LDAP calls can be confined to the cluster.
This deployment uses an Ingress controller to enable external interactions with OUDSM. Ingress services are used only when access to the OUD LDAP services are required outside of the Kubernetes cluster, such as a third party telephone book application. External access may also be required for OUDSM.
While it is possible to access OUDSM through the Oracle HTTP server, because this is an administration function, you can access OUDM directly through the Ingress controller.
Figure 4-3 OUD Using the Ingress Controller

Parent topic: Primary Deployment Topologies
Oracle Access Manager and Oracle Identity Governance
Figure 4-4 shows a deployment of Oracle Access Manager and Oracle Identity Governance.
A load balancer provides external internet access to the OAM and OIG runtime functionality. The same load balancer provides only internal access to the OAM and OIG administrative services.
External requests are SSL terminated at the load balancer and internal requests are standard HTTP requests. The load balancer uses the Oracle HTTP server to proxy these requests to the OAM and OIG services. The Oracle HTTP server, in turn, passes on the application requests to an Ingress controller which forwards the requests to the OAM and OIG Kubernetes services.
Figure 4-4 OAM and OIG Using an Ingress Controller

Parent topic: Primary Deployment Topologies
Oracle Identity Role Intelligence
Figure 4-5 shows the deployment of Oracle Identity Role Intelligence integrated into a complete Oracle Identity and Access Management deployment where all traffic is routed through an Oracle HTTP Server and then an Ingress controller.
In this type of deployment, you can integrate Oracle Identity Role Intelligence with a complete Oracle Identity and Access deployment whether the other Identity components reside in the Kubernetes cluster or not.
A load balancer provides internal only access to the OIRI services. The load balancer uses the Oracle HTTP Server to proxy these requests to the OIRI. The Oracle HTTP server is used where a fully integrated Identity Management deployment is being used, and everything is proxied through the Oracle HTTP server.
OIRI can either share the igdadmin.example.com
virtual
host or use its own dedicated virtual host.
OIRI is an administration only function and does not have any direct interaction with the internet.
Figure 4-5 Integrated OIRI Using the Ingress Controller

Parent topic: Primary Deployment Topologies
Oracle Advanced Authentication, Oracle Adaptive Risk Management, and Oracle Universal Authenticator
Figure 4-6 shows a deployment of Oracle Advanced Authentication. OAA has both administrative and runtime operations.
A load balancer provides access to the OAA/OARM services. The load balancer sends these requests to the Ingress controller directly, which in turn directs the requests to the appropriate OAA microservice. The Oracle HTTP Server is used where a fully integrated Identity Management deployment is being used, and everything is proxied through the Oracle HTTP Server.
The Oracle HTTP Server sends requests to an Ingress controller, which sends these requests to the appropriate OAA Kubernetes services.
OAA can either share the iadadmin
/login
virtual
hosts or use its own dedicated virtual hosts.
External requests are SSL terminated at the load balancer and internal requests are standard HTTP requests.
Figure 4-6 OAA Using an Ingress Controller

Parent topic: Primary Deployment Topologies
Secondary Deployment Topologies
These topologies are fully supported alternative deployments that you can consider using.
Oracle Unified Directory
Figure 4-7 shows a deployment of Oracle Unified Directory and Oracle Unified Directory Services Manager. Typically, none of the services in this diagram are exposed to the internet.
In a full Kubernetes deployment, interactions with OUD are normally kept inside of the Kubernetes cluster. In this case, LDAP calls can be confined to the cluster and NodePort Services are not required. NodePort Services are used only when access to the OUD LDAP services are required outside of the Kubernetes cluster, such as a third party telephone book application. External access may also be required for OUDSM.
While it is possible to access OUDSM through the Oracle HTTP server, because this is an administration function, you can access it directly using the NodePort Service exposed for OUDSM.
Figure 4-7 OUD Using the NodePort Services

Parent topic: Secondary Deployment Topologies
Oracle Access Manager and Oracle Identity Governance
Figure 4-8 shows a deployment of Oracle Access Manager and Oracle Identity Governance.
A load balancer provides external internet access to the OAM and OIG runtime functionality. The same load balancer provides only internal access to the OAM and OIG administrative services. External requests are SSL terminated at the load balancer and internal requests are standard HTTP requests. The load balancer uses the Oracle HTTP server to proxy these requests to the OAM and OIG services. OAM and OIG services are exposed outside of the Kubernetes cluster using individual NodePort Services.
Figure 4-8 OAM and OIG Using the NodePort Services

Parent topic: Secondary Deployment Topologies
Oracle Identity Role Intelligence
Figure 4-9 shows a standalone deployment of Oracle Identity Role Intelligence where traffic is routed through an Ingress controller.
The Ingress controller sends the requests to the appropriate OIRI
Kubernetes services. OIRI can either share the igdadmin.example.com
virtual host or use its own dedicated virtual host.
OIRI is an administration only function and does not have any direct interaction with the internet.
Figure 4-9 OIRI Using Only an Ingress Controller

Figure 4-10 shows the deployment of Oracle Identity Role Intelligence integrated into a complete Oracle Identity and Access Management deployment where all traffic is routed through an Oracle HTTP Server and then sent directly to the OIRI microservices by using the Kubernetes NodePort Services. In this type of deployment, you can integrate Oracle Identity Role Intelligence with a complete Oracle Identity and Access Management deployment whether the other Identity components reside in the Kubernetes cluster or not.
A load balancer provides internal only access to the OIRI services. The load balancer uses the Oracle HTTP Server to proxy these requests to the OIRI. The Oracle HTTP server is used where a fully integrated Identity Management deployment is being used, and everything is proxied through the Oracle HTTP server.
OIRI services are exposed outside of the Kubernetes cluster using individual NodePort services. You can deploy OIRI without the Oracle HTTP server. See Figure 4-10.
OIRI can either share the igdadmin.example.com
virtual
host or use its own dedicated virtual host.
OIRI is an administration only function and does not have any direct interaction with the internet.
Figure 4-10 Integrated OIRI Using the NodePort Services

Parent topic: Secondary Deployment Topologies
Oracle Advanced Authentication, Oracle Adaptive Risk Management, and Oracle Universal Authenticator
Figure 4-11 shows a deployment of Oracle Advanced Authentication and Risk Management, in a fully integrated Oracle Identity and Access Management deployment.
A load balancer provides external internet access to the OAA and OARM runtime functionality. The same load balancer provides internal only access to the OAA and ORAM administrative services.
External requests are SSL terminated at the load balancer and internal requests are standard HTTP requests. The load balancer uses the Oracle HTTP server to proxy these requests to the OAA and OARM services. OAA and OARM services are exposed outside of the Kubernetes cluster using individual NodePort Services.
Note:
In an OAA and OARM deployment, the OAA microservices are SSL enabled.Figure 4-11 OAA Using the NodePort Services

Figure 4-12 shows a standalone deployment of Oracle Advanced Authentication and Risk Management. A load balancer provides external internet access to the OAA and OARM administrative services. An Ingress controller provides access to the OAA Kubernetes services. In this scenario, OAA uses its own dedicated virtual host.
Figure 4-12 Standalone OAA Using Ingress on Kubernetes

Parent topic: Secondary Deployment Topologies
About the Primary Oracle Identity and Access Management Topology Diagrams
The primary enterprise deployment topology is the main Oracle reference topology for Oracle Identity and Access Management. It provides a solution which is both highly available and scalable.
- Product Separation
- About the Web Tier
- About Oracle Unified Directory Assured Replication
- About Oracle Identity Role Intelligence
- About Oracle Advanced Authentication, Oracle Adaptive Risk Management, and Oracle Universal Authenticator
- Summary of Oracle Identity and Access Management Load Balancer Virtual Server Names
- About Oracle Identity Management on Kubernetes
- Summary of the Managed Servers and Clusters on the Application Tier Hosts
Parent topic: About the IAM Enterprise Deployment
Product Separation
An IAM deployment is made up of a number of components. These components include:
- Web Servers
- WebLogic Application Servers
- Microservices deployed in containers
- LDAP
- Database
The Oracle Identity and Access Management components are split into a number of different WebLogic domains: IAMAccessDomain and IAMGovernanceDomain. Products are distributed as follows:
- IAMAccessDomain contains Oracle Access Management (OAM).
- IAMGovernanceDomain contains Oracle Identity Governance.
- OHSDomain used to host the Oracle HTTP Servers.
- OUDSMDomain used when OUDSM is deployed.
Note:
In a Kubernetes deployment, the OHS and OUDSM domains are not controlled by the WebLogic Kubernetes Operator.This split is due to the different operational and availability requirements demanded of the individual components. Typically components in the IAMAccessDomain have a higher availability requirement than those in the IAMGovernanceDomain. By separating these components out, you can manage the availability requirements differently. You can patch governance components independently of access components, and you can shut down the Governance instance without impacting the access components. From Oracle Identity and Access Management 12c, it is not supported to have Oracle Access Manager and Oracle Identity Governance in the same domain.
The OHSDomain and OUDSMDomain are are used to manage the Oracle HTTP Server and Oracle Unified Directory Services Manager, respectively.
- Oracle Unified Directory
- Microservices
A further benefit of this separation is that you can build a topology in a modular fashion. You can start with a directory and extend it to Access components, then later extend it to Governance components, without needing to affect the deployed software or configuration of existing components, unless you are wiring them together.
Oracle Identity Role Intelligence and Oracle Advanced Authentication are deployed as dedicated micro services.
About the Web Tier
The web tier consists of two or more host computers where Oracle HTTP Server is installed. The web tier is located in a demilitarized zone (DMZ) in a different network/subnet from the application tiers. This location ensures that maximum network security is maintained.
The web tier is located between two firewalls, which helps limit traffic from the internet and ensures that only application traffic is allowed to pass through to the application tier.
In an internet-facing application, the web tier is defined so that administration-type functions are constrained to a virtual host, which is only resolvable inside the organization. This feature ensures that someone should be present inside the private network to perform the administrative operations.
The fact that the administration virtual hosts are resolvable only inside the private network means that communications using this virtual host do not require SSL.
Communications with the internet must be to and from the internet client using SSL. However, end-to-end SSL in an application has a performance impact. By placing the web tier in a DMZ, you can ensure that SSL is terminated outside of the web tier by a load balancer, and communication inside the topology uses the much faster non-SSL protocol. This strategy has the benefit of ensuring that all internet traffic is SSL enabled but without the performance overhead of end-to-end SSL.
About Oracle Unified Directory Assured Replication
Oracle Unified Directory server instances natively use replication to keep their embedded databases in sync. By default, replication employs a loose consistency model in which the updates are replicated to replicas AFTER returning the operation result to the application. In this model it is therefore possible to write some data to a replica, and read outdated information from another replica for a short time after the write. Great efforts have been made in Oracle Unified Directory replication to ensure that the replication process is fast and can achieve replication in the order of one millisecond.
Oracle Unified Directory can be configured to use the Assured Replication model, which has been developed to guarantee that the data in the replicas is consistent. When using the Safe Read mode of Assured Replication, applications have the guarantee that the replication process is completed before returning the result of a write operation.
Using Assured Replication has a negative impact on the response time of write operations because it requires some communications with remote replicas before returning the operation result. The amount of the delay varies, depending on the network being used and the capacity of the servers hosting Oracle Unified Directory. Using Assured replication has little if any impact on read operations.
If you expect to regularly perform large writes to your directory, consider configuring your load balancer to distribute requests to your Oracle Unified Directory instances in an active/passive mode. This will remove the chance of you reading out of date data from a replica, but could result in overall performance degradation if your Oracle Unified Directory host is not capable of processing all of the requests.
For the purposes of this Guide, it is assumed that the ability to have multiple servers processing requests is more important than the extra overhead incurred with writing requests in Assured mode. To that end, this Guide shows the configuration of Oracle Unified Directory using Assured Replication. Both of the following Oracle Unified Directory configurations, however, are supported:
-
Active/Active in an assured configuration
-
Active/Passive in a non assured configuration
For more information, see the Assured Replication section of Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory.
About Oracle Identity Role Intelligence
- Building roles as a manual process is time-consuming. Entitlement data is difficult and complex for users to analyze and interpret.
- Entitlements accumulate over time. Users and applications data change constantly.
- Roles are difficult to maintain and change to align with business activities such as reorganization, merge, acquisition, and so on.
- Lack of tooling to provide what if analysis before organizations adopt roles for various business units.
These challenges are addressed by the Oracle Identity Role Intelligence (OIRI) microservice.
Oracle Identity Role Intelligence uses a microservice architecture rather than the traditional WebLogic deployment architecture. This means that Oracle Identity Role intelligence should be deployed using a container based architecture such as Kubernetes. OIRI will continue to integrate with the traditional Oracle Identity and Access Management deployment. However, the OIRI component should be deployed in a container.
Oracle Identity Role Intelligence is an extension to Oracle Identity Governance (OIG). It
is used by administrators. Therefore, in an enterprise deployment it is tied to the
administrative application URL igdadmin.example.com
.
Note:
In this release, although OIRI is integrated into the overall Oracle Identity and Access enterprise deployment architecture, it does not support single-sign on through Oracle Access Manager.Data Ingress: Supports data import to OIRI from the OIG database or flat files in full and incremental modes.
Data Modelling: Enables you to define role mining tasks based on a combination of user, application, and entitlement attributes.
Predictive Analytics: Uses Oracle Database’s KMean clustering and unsupervised Machine Learning (ML) algorithms. The regression model groups the user data based on the common entitlement attributes, and predicts the relevant and matching candidate roles.
Assistant: Compares candidate roles with the existing roles in the system. You can publish the candidate roles to your system to avoid duplication or explosion of roles.
Data Egress: Provides automation to publish the candidate roles to Oracle Identity Governance and triggers the workflow approval.
About Oracle Advanced Authentication, Oracle Adaptive Risk Management, and Oracle Universal Authenticator
Oracle Advanced Authentication (OAA) supports the establishment and assertion of the identity of users.
OAA provides strong authentication using Multiple Authentication Factors (MFA). A wide range of authentication factors are available out-of-the-box for establishing the identity of users. OAA supports integration with Oracle Access Management (OAM) and Oracle Radius Agent (ORA) to provide Multi Factor Authentication (MFA) capabilities.
OAA constitutes unique features that facilitate deployment, configuration, and integration with other products.
- Runs as a standalone micro-service on a Kubernetes platform and is deployed using the Helm charts
- Supports integration with the following clients to enable Multi-factor
Authentication (MFA):
- Clients providing web-based user login flows, such as Oracle Access Management (OAM): OAA integrates with OAM through the Trusted Authentication Protocol (TAP).
- Clients providing API-based user login flows, such as Oracle Radius Agent (ORA): OAA integrates with ORA through REST APIs. This type of integration enables clients to manage their own user-flow orchestration.
- Provides
OAAAuthnPlugin
for integrating with OAM. The plug-in also enables migration of user data from the identity store on OAM to OAA. - Provides a web UI (admin UI console) for administrators to create and manage client registrations, assurance levels, and policies. Administrators can also achieve all the administration tasks using the REST APIs.
- Provides a web UI (user preferences UI) for users to manage and register their challenge factors. User self-registration and management can also be performed using the REST APIs.
- Web UIs are secured by OAM OAuth and OIDC.
- Provides the following challenge factors out-of-the-box:
- Time-based One Time Password (TOTP): (OMA, Google, and Microsoft)
- OTP (Email and SMS)
- Yubikey OTP
- Fast Identity Online (FIDO2)
You can deploy Oracle Advanced Authentication as a standalone service or as part of an integrated Oracle Identity and Access Management deployment.
Summary of Oracle Identity and Access Management Load Balancer Virtual Server Names
In order to balance the load on servers and to provide high availability, a hardware load balancer is required. This hardware load balancer should exist on redundant hardware to ensure maximum availability. The hardware load balancer must be configured to recognize a set of virtual server names.
The hardware load balancer in Oracle Identity and Access Management deployments must recognize the following virtual server names.
-
login.example.com
- This virtual server name is used for all incoming Access traffic. It acts as the access point for all HTTP traffic to the runtime Access Management components. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:login.example.com:443
-
prov.example.com
- This virtual server name is used for all incoming Governance traffic. It acts as the access point for all HTTP traffic to the runtime Governance components. The load balancer routes all requests to this virtual server name over SSL. As a result, clients access this service using the following secure address:prov.example.com:443
Note that, in previous releases of the Enterprise Deployment Guide,
login.example.com
andprov.example.com
were the same entry point. This release allows for them to be separated out. This will enable smarter routing from the load balancer, allow a more modular deployment and will facilitate future Multi-datacenter deployments. If desired these two entry points can still be combined to provide a single point of entry into the IAM deployment. -
iadadmin.example.com
- This virtual server name is enabled on the load balancer. It acts as the access point for all internal HTTP traffic that gets directed to the administration services in the IAMAccessDomain. The incoming traffic from clients is non-SSL enabled. Therefore, the clients access this service using the following address:iadadmin.example.com:80
This in turn is forwarded to port
7777
on WEBHOST1 and WEBHOST2.The services accessed on this virtual host include the WebLogic Administration Server Console and Oracle Enterprise Manager Fusion Middleware Control.
Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the
iadadmin.example.com
virtual host. -
igdadmin.example.com
- This virtual server name is enabled on the load balancer. It acts as the access point for all internal HTTP traffic that gets directed to the administration services in the IAMGovernanceDomain. The igdadmin entry point is also used as the entry point for Oracle Identity Role Intelligence. The incoming traffic from clients is non-SSL enabled. Therefore, the clients access this service using the following address:igdadmin.example.com:80
This in turn is forwarded to port
7777
on WEBHOST1 and WEBHOST2.The services accessed on this virtual host include the WebLogic Administration Server Console and Oracle Enterprise Manager Fusion Middleware Control.
Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the igdadmin.example.com virtual host.
-
igdinternal.example.com
- This virtual server name is for internal communications between the application tier components in the Governance Domain only and is not exposed to the Internet. This virtual server is used for both Oracle OIM Suite and Oracle SOA Suite internal communications.The traffic from clients to this virtual server is not SSL-enabled. Clients access this service using the following address and the requests are forwarded to port 7777 on WEBHOST1 and WEBHOST2 (this is optional in a Kubernetes environment):
igdinternal.example.com:7777
-
idstore.example.com
- This virtual server name is used for all incoming identity store traffic. It acts as the access point to the LDAP directory instances. This virtual server is not exposed to the internet.The traffic from clients to this virtual server may or may not be SSL-enabled, depending on the type of LDAP directory in use. Typically, this will be non-SSL enabled for Oracle Unified Directory. Clients access this service using this virtual server name and the requests are forwarded to the LDAP instances.
Note:
If all of the applications that access the LDAP directory are inside the Kubernetes cluster, you can choose to use the Kubernetes service names rather than a load balancer virtual host, for LDAP access.
About Oracle Identity Management on Kubernetes
Although the topology of Oracle Identity Management on Kubernetes is similar to that of a traditional Oracle Identity Management deployment, there are some notable differences which are described below:
- Managed Servers
Oracle WebLogic Managed Servers, including the Administration Server, are deployed in a container. Each Managed Server resides in its own container.
- Virtual IP Addresses
A traditional enterprise deployment makes use of virtual IP addresses to facilitate Administration failover and server migration. This is not required in a Kubernetes deployment because Kubernetes automatically assigns its own IP addresses.
- Managed Server Interaction
In a traditional enterprise deployment, you interact with Managed Servers using the virtual host name assigned to the Managed Server's listen address or the physical host name on which the Managed Server is running, depending on how you have configured the Managed Server.
In a Kubernetes environment, Kubernetes services are defined at the cluster level. When the Kubernetes containers are added and/or removed, the Kubernetes service gets updated accordingly. All communication occurs through the Kubernetes services.
Kubernetes services are accessible from each Kubernetes worker host.
- Microservices
Microservices extend the traditional Oracle Identity and Access Management functionality. Each microservice is deployed in a Kubernetes container. Similar to Managed Servers, Microservices are assigned a Kubernetes service defined at the cluster level, to provide High Availability. Interaction with micoservices is through the Oracle HTTP Server.
- Shared Storage and Persistence
Each container is associated with a persistent volume. The persistent volume is where the domain/instance files are located. The persistent volume is mapped to an NFS share enabling you to use traditional backup and recovery techniques.
Only the information that is stored on a persistent volume survives reboots. The ORACLE_HOME is not stored on persistent volumes. Therefore, the changes made will not survive a reboot. This makes patching easier. However, you cannot directly edit the files in ORACLE_HOME.
Unlike the traditional enterprise deployment, the DOMAIN_HOME is not split into ASERVER_HOME and MSERVER_HOME.
- Customizations
Certain Oracle products allow customizations. These are often made by changing/creating
.war
files in ORACLE_HOME. In a Kubernetes deployment, any changes made in this way is lost after you restart a container. If you want to make customizations, place the.war
files (including the dev starter pack) inside the persistent volume mounted at/u01/oracle/user_projects
, preferably in a dedicated directory. This method persists customizations across restarts and image changes (bundle patches and upgrades).After you place the
.war
files in the persistent volume, deploy it to the domain from that location (/u01/oracle/user_projects
). - Containers vs Hosts
In a typical enterprise deployment, each WebLogic domain, each LDAP instance, each database and each web server is running on a number of hosts.
In a Kubernetes environment, the WebLogic/Microservices/LDAP components are moved into the Kubernetes cluster. The web tier and database are not. This enables firewalls to be erected between the internet and the web tier, between the web tier and the Kubernetes cluster, and between the Kubernetes tier and the database. This enables you to utilize the flexibility that Kubernetes offers for the application tier, while maintaining entrerprise security.
Summary of the Managed Servers and Clusters on the Application Tier Hosts
The Application tier hosts the Administration Server and Managed Servers in the Oracle WebLogic Server domains.
Depending upon the components you select, the Oracle WebLogic Server domain for the Oracle Identity and Access Management consists of the clusters shown in Table 4-1. These clusters function as active-active high availability configurations.
Table 4-1 Domain Clusters and Managed Servers
Domain | Cluster | Managed Servers |
---|---|---|
IAMAccessDomain |
Oracle Access Manager |
oam_server1, oam_server2 |
Oracle Policy Manager |
oam_policy_mgr1, oam_policy_mgr2 |
|
IAMGovernanceDomain |
Oracle Identity Governance Oracle SOA Suite |
oim_server1, oim_server2 soa_server1, soa_server2 |
Storage Requirements for an Enterprise Deployment
Preparing the file system for an enterprise deployment involves understanding the requirements for local and shared storage, as well as the terminology that is used to reference important directories and file locations during the installation and configuration of the enterprise topology.
- About Preparing Storage for an Enterprise Deployment
- About the Recommended Directory Structure for an Enterprise Deployment
- Summary of the Storage File Systems and Corresponding Mount Points for Containers
- Mapping of File Systems to Hosts
- File System and Directory Variables Used in This Guide
Parent topic: About the IAM Enterprise Deployment
About Preparing Storage for an Enterprise Deployment
It is important to set up your storage in a way that makes the enterprise deployment easy to understand, configure, and manage.
This section provides an overview of the process of preparing storage for an enterprise deployment. Oracle recommends setting up your storage according to information in this chapter. The terminology defined in this chapter is used in the diagrams and procedures throughout the guide.
Use this chapter as a reference to understand the directory variables that are used in the installation and configuration procedures.
Other directory layouts are possible and supported, but the model adopted in this guide was designed for maximum availability, providing both the best isolation of components and symmetry in the configuration and facilitating backup and disaster recovery. The rest of the document uses this directory structure and directory terminology.
Parent topic: Storage Requirements for an Enterprise Deployment
About the Recommended Directory Structure for an Enterprise Deployment
The diagrams in this section show the directory structure for a typical Oracle Fusion Middleware enterprise deployment.
The directories shown in the diagrams contain binary files that are part of the
pre-built container images, domain-specific files generated through the domain
configuration process, as well as domain configuration files that are propagated to the
various host computers through the Oracle WebLogic Server pack
and unpack
commands.
The diagrams are used to indicate:
-
Figure 4-13 shows the resulting directory structure on the shared storage device after you have installed and configured a typical Oracle Fusion Middleware enterprise deployment. The shared storage directories are accessible by the application tier host computers.
-
Figure 4-16 shows the resulting directory structure on the local storage device for a typical web tier host after you have installed and configured an Oracle Fusion Middleware enterprise deployment. Note that the software binaries (in the Oracle home) are installed on the local storage device for each web tier host.
Where applicable, the diagrams also include the standard variables used to reference the directory locations in the installation and configuration procedures in this guide.
Figure 4-13 Recommended Shared Storage Directory Structure for an Enterprise Deployment

See About the Node Manager Configuration in a Typical Enterprise Deployment.
Figure 4-14 Recommended Directory Structure for Oracle Identity Role Intelligence

Figure 4-15 Recommended Directory Structure for Oracle Advanced Authentication

Figure 4-16 Recommended Local Storage Directory Structure for a Web Tier Host Computer in an Enterprise Deployment

Parent topic: Storage Requirements for an Enterprise Deployment
Summary of the Storage File Systems and Corresponding Mount Points for Containers
Oracle Identity and Access Management uses shared storage mounted to individual Kubernetes containers. This ensures that wherever a container is started, it always has access to its file system data.
To organize the enterprise deployment software on the appliance, you create a number of projects, file system shares are then created inside these projecst on the appliance. These shares can then be mounted directly to the Kubernetes containers.
To ease management, these file systems are also mounted to an administration host which you use for deployment and management operations. When mounted to the administration host, they are required to be mounted only for the duration of the management task being performed. Oracle recommends that you do not mount the file systems beyond this time.
Binary files for the Oracle HTTP Server can be created on local volumes or shared volumes mounted exclusively to the web tier hosts.
Figure 4-17 shows the recommended physical directory structure on the shared storage device.
Table 4-3 shows how the shares on the storage device map to the mount points inside the Kubernetes containers.
Figure 4-17 Physical Structure of the Shares on the Shared File System for Virtual Deployments

Figure 4-17 illustrates the physical structure of the shares on the shared appliance.
Table 4-2 Summary of Storage Projects for Virtual Servers
Project | Size |
---|---|
IAMBINARIES |
10 GB |
IAMPVS |
300 GB |
IMAGES |
50 GB Note: Size is dependent on how many docker images have to be stored, including versions. You should allow enough space for at least two versions of each image. This enables you to have the current version and the version to which you want to apply the patch. You will not require an 'Images' project if you are using a container registry. |
Parent topic: Storage Requirements for an Enterprise Deployment
Mapping of File Systems to Hosts
This table summarizes how the physical directories on the storage appliance are mapped to the mount points on each container or host.
Table 4-3 Mapping the Shares on the Appliance to Mount Points on Each Container or Host
Project | Share | Mount Point | Container/Host | Mounted On | Privileges to Assign to User, Group, and Other | Actual Size | Description and Purpose |
---|---|---|---|---|---|---|---|
IAMBINARIES1 |
|
|
WEBHOST1 |
|
Read/Write |
10 GB |
Local storage for the Oracle HTTP Server software binaries (Oracle Home). |
IAMBINARIES2 |
|
|
WEBHOST2 |
|
Read/Write |
10 GB |
Local storage for the Oracle HTTP Server software binaries (Oracle Home). |
IAMPVS |
|
|
OAM |
|
Read/Write |
5 GB |
Shared storage for the OAM domain. |
IAMPVS |
|
|
OIG |
|
Read/Write |
5 GB |
Shared storage for the OIG domain. |
IAMPVS |
|
|
LDAP |
|
Read/Write |
10 GB |
Shared storage for OUD instances. This is where the Oracle home directory and product directories are installed. |
IAMPVS |
|
|
LDAP |
|
Read/Write |
5 GB |
Shared storage for the configuration files required to set up OUD. |
IAMPVS |
|
|
OUDSM |
|
Read/Write |
10 GB |
Shared storage for OUDSM. |
IAMPVS |
oiripv |
/exports/IAMPVS/oiripv |
OIRI OIRI-CLI |
/app/oiri |
Read/Write |
10 GB |
Shared storage for OIRI. |
IAMPVS |
dingpv |
/exports/IAMPVS/dingpv |
SPARK-HISTORY (DING) OIRI OIRI-CLI |
/app |
Read/Write |
10 GB |
Shared storage for Data Ingester. |
IAMPVS |
workpv |
/exports/IAMPVS/workpv |
OIRI-CLI OIRI-DING-CLI |
/app/k8s |
Read/Write |
200 M |
Working directory used for OIRI configuration/management. |
IAMPVS |
|
|
oaa-mgmt |
|
Read/Write |
Used to store the customized configuration file for installing OAA and OARM. |
|
IAMPVS |
|
|
oaa-mgmt |
|
Read/Write |
Used to store credential files such as
|
|
IAMPVS |
|
|
oaa-mgmt |
|
Read/Write |
Used to store installation logs and status. |
|
IAMPVS |
|
|
oaa-mgmt |
|
Read/Write |
Used to store the vault artifacts for a file-based vault. |
|
IAMCONFIG |
|
|
WEBHOST1 |
|
Read/Write |
5 GB |
Local storage for the domain configuration files used by WEBHOST1, if the private Managed Server domain directory resides on a shared storage. |
IAMCONFIG |
|
|
WEBHOST2 |
|
Read/Write |
5 GB |
Local storage for the domain configuration files used by WEBHOST2, if the private Managed Server domain directory resides on a shared storage. |
IMAGES |
|
|
Kubernetes Workers |
|
Read/Write |
10 GB |
Used to store the container images locally. This is optional. |
Note:
If required, after the configuration is complete, you can change thebinary
directories to
read only, .
Parent topic: Storage Requirements for an Enterprise Deployment
File System and Directory Variables Used in This Guide
Understanding the file system directories and the directory variables used to reference these directories is essential for installing and configuring the enterprise deployment topology.
Table 4-4 lists the file system directories and the directory variables that are used to reference the directories on the application tier. Table 4-5 lists the file system directories and variables that are used to reference the directories on the web tier.
For additional information about mounting these directories when you use shared storage, see Creating and Mounting the Directories for an Enterprise Deployment.
Throughout this guide, the instructions for installing and configuring the topology refer to the directory locations that use the variables shown here.
You can also define operating system variables for each of the directories listed in this section. If you define system variables for the particular UNIX shell that you are using, you can then use the variables as they are used in this document, without having to map the variables to the actual values for your environment.
Table 4-4 Sample Values for Key Directory Variables on the Application Tier
Directory Variable | Description | Relative Path | Sample Value on the Application Tier |
---|---|---|---|
CONTAINER_ROOT |
The home directory of the container. The Oracle product binaries and the OUD setup files are present in this directory. |
N/A | /u01 |
ORACLE_HOME |
The read-only location for the product binaries. For the application tier host computers, it is stored on shared disk (PV). The Oracle home is created when the container is deployed. In a Kubernetes deployment, ORACLE_HOME is the same as CONTAINER_HOME. |
|
|
ORACLE_COMMON_HOME |
The directory within the Oracle Fusion Middleware Oracle home where common utilities, libraries, and other common Oracle Fusion Middleware products are stored. |
ORACLE_HOME/oracle_common |
|
WL_HOME |
The directory within the Oracle home where the Oracle WebLogic Server software binaries are stored. |
ORACLE_HOME/wlserver |
/u01/oracle/wlserver |
PROD_DIR |
Individual product directories for each Oracle Fusion Middleware product that you install. |
ORACLE_HOME/prod_dir |
/u01/oracle/prod_dir The product
can be |
EM_DIR |
The product directory used to store the Oracle Enterprise Manager Fusion Middleware Control software binaries. |
ORACLE_HOME/em |
/u01/oracle/em |
JAVA_HOME |
The location where the supported Java Development Kit (JDK) is installed. |
CONTAINER_ROOT/jdk |
/u01/jdk |
SHARED_CONFIG_DIR |
The shared parent directory for shared environment configuration files, including domain configuration, keystores, runtime artifacts, and application deployments | CONTAINER_HOME/user_projects |
/u01/oracle/user_projects |
DOMAIN_HOME |
The domain home, which is installed on a shared disk. |
SHARED_CONFIG_DIR/domains/domain_name |
/u01/oracle/user_projects/domains/domain_name In this example, replace
|
APPLICATION_HOME |
The Application home directory, which is installed on shared disk, so the directory is accessible by all the application tier host computers. |
SHARED_CONFIG_DIR/applications/domain_name |
/u01/oracle/user_projects/applications/domain_name In this example, replace
|
KEYSTORE_HOME |
The shared location for custom certificates and keystores. |
SHARED_CONFIG_DIR/keystores |
/u01/oracle/user_projects/keystores |
Table 4-5 Sample Values for Key Directory Variables on the Web Tier
Directory Variable | Description | Sample Value on the Web Tier |
---|---|---|
WEB_ORACLE_HOME |
The read-only location for the Oracle HTTP Server product binaries. For the web tier host computers, this directory is stored on the local disk. The Oracle home is created when you install the Oracle HTTP Server software . |
/u02/private/oracle/products/web |
ORACLE_COMMON_HOME |
The directory within the Oracle HTTP Server Oracle home where common utilities, libraries, and other common Oracle Fusion Middleware products are stored. |
/u02/private/oracle/products/web/oracle_common |
WL_HOME |
The directory within the Oracle home where the Oracle WebLogic Server software binaries are stored. |
/u02/private/oracle/products/web/wlserver |
PROD_DIR |
Individual product directories for each Oracle Fusion Middleware product that you install. |
/u02/private/oracle/products/web/ohs |
JAVA_HOME |
The location where you install the supported Java Development Kit (JDK). |
/u02/private/oracle/products/jdk |
WEB_DOMAIN_HOME |
The Domain home for the standalone Oracle HTTP Server domain, which is created when you install Oracle HTTP Server on the local disk of each web tier host. |
/u02/private/oracle/config/domains/domain_name In this example, replace
|
WEB_CONFIG_DIR |
This is the location where you edit the Oracle HTTP Server configuration files (for example, Note that this directory is also referred to as the OHS Staging Directory. Changes made here are later propagated to the OHS Runtime Directory. See Staging and Run-time Configuration Directories in the Administering Oracle HTTP Server. |
|
Parent topic: Storage Requirements for an Enterprise Deployment
About Permissions
When containers are created, the files owned by the container are owned by the user with UID 1000 and group 1000.
If you have an existing user with the UID 1000 on your system, you will see all container services running as this user.
If you do not have an existing user/group with the UID/GID of 1000, you should create one.
When creating NFS shares for use by containers, ensure that the user/group with UID:GID of 1000:1000 has the write permission.
Parent topic: About the IAM Enterprise Deployment
Summary of Microservices and Clusters on the Application Tier
The application tier not only hosts the WebLogic components of Oracle Identity and Access Management, but it also hosts the Microservice components.
Depending upon the components you select, Oracle microservices consists of clusters shown in Table 4-6. These clusters function as active-active high availability configurations.
Table 4-6 Oracle Microservices
Component | Function | Microservice |
---|---|---|
OIRI |
Oracle Role Intelligence |
oiri |
OIRI |
Oracle Role Intelligence GUI |
oiri-ui |
OIRI |
Oracle Data Ingester |
spark-history-server |
OAA |
Install OAA and Risk |
oaa-mgmt |
OAA |
Main OAA functionality |
oaa-svc |
OAA + OARM |
Policy Management APIs |
oaa-policy |
OAA + OARM |
Administrative UI (OAA + OARM) |
oaa-admin |
OAA |
|
oaa-spui |
OAA |
Fido Device Registration and Fido-based Authentication |
oaa-factor-fido |
OAA |
Oracle Mobile Authenticator (OMA) OTP Authentication only |
oaa-factor-totp |
OAA |
SMS Authentication only |
oaa-factor-sms |
OAA |
Email Authentication only |
oaa-factor-email |
OAA |
Yubikey-based Authentication only |
oaa-factor-yotp |
OAA |
Knowledge-based Challenge Registration and Authentication |
oaa-factor-kba |
OAA |
OMA Push Registration and Authentication |
oaa-factor-push |
OARM |
Customer Care APIs |
risk-cc |
OARM |
Risk Evaluation APIs |
risk-engine |
Parent topic: About the IAM Enterprise Deployment
About the Forgotten Password Functionality
In Oracle 11g, the mechanism to reset passwords was provided by Oracle Identity Governance. In Oracle 12c, you have two possibilities - by integrating Oracle Access Management (OAM) and Oracle Identity Governance (OIG) or by using Oracle Access Management.
-
Oracle Access Management (OAM) and Oracle Identity Governance (OIG) integration:
In this scenario, when the users first sign in, they can set a number of challenge questions stored in OIG. If users forget their password, they can answer the challenge questions. If they answer their challenge questions successfully, they will be given the option to reset their password by using OIG.
-
Oracle Access Management:
In this scenario, OAM is wired to the Oracle User Messaging Service. Each user is associated with either a telephone number and or an email address. When users request for a forgotten password link, they are sent a one time PIN which they can enter into the application to reset the password.
This guide describes how to set up both the scenarios.
Parent topic: About the IAM Enterprise Deployment
Integrating Oracle LDAP, Oracle Access Manager, and Oracle Identity Governance
Integration of Oracle Identity Manager and Oracle Access Manager with LDAP directories is done by using LDAP Connector.
To enable termination of user sessions upon disablement or termination of a user, download the 12.2.1.3 version of the LDAP Connector.
This section describes how to obtain, install, and configure the Oracle Connector for LDAP.
About the Oracle Connector

The LDAP Connector is implemented by using the Identity Connector Framework (ICF). The ICF is a component that provides basic reconciliation and provisioning operations that are common to all Oracle Identity Manager connectors. The ICF is shipped along with Oracle Identity Manager. Therefore, you need not configure or modify the ICF.
The LDAP Connector uses JNDI to access the target system. This connector can be configured to run in one of the following modes:
-
Identity Reconciliation: Identity reconciliation is also known as authoritative or trusted source reconciliation. In this form of reconciliation, OIM Users are created or updated corresponding to the creation of and updates to users on the target system.
Note:
The identity reconciliation mode supports the reconciliation of user objects only. -
Account Management: Account management is also known as target resource management. This mode of the connector enables provisioning and target resource reconciliation.
Provisioning
Provisioning involves creating, updating, or deleting users, groups, roles, and organizational units (OUs) on the target system through Oracle Identity Manager.
When you allocate (or provision) a target system resource to an OIM user, the operation results in the creation of an account on the target system for that user. In the Oracle Identity Manager context, the term provisioning is also used to mean updates (for example enabling or disabling) made to the target system account through Oracle Identity Manager.
Users and organizations are organized in a hierarchical format on the target system. Before you can provision users to (that is, create users in) the required organizational units (OUs) on the target system, you must fetch into Oracle Identity Manager the list of OUs used on the target system. This is achieved by using the LDAP Connector OU lookup Reconciliation scheduled job for lookup synchronization.
Similarly, before you can provision users to the required groups or roles on the target system, you must fetch into Oracle Identity Manager the list of all groups and roles used on the target system. This is achieved by using the LDAP Connector Group Lookup Reconciliation and LDAP Connector Role Lookup Recon scheduled jobs for lookup synchronization.
Target resource reconciliation
To perform target resource reconciliation, the LDAP Connector User Search Reconciliation or LDAP Connector User Sync Reconciliation scheduled jobs is used. The connector applies filters to locate users to be reconciled from the target system and then fetches the attribute values of these users.
Depending on the data that you want to reconcile, you use different scheduled jobs. For example, you use the LDAP Connector User Search Reconciliation scheduled job to reconcile user data in the target resource mode.
You can deploy the Oracle LDAP Connector either locally in Oracle Identity Manager or remotely in the connector server. A connector server enables remote execution of an Identity Connector. This guide explains the steps to install and configure the connector locally in Oracle Identity Manager.
Parent topic: About the IAM Enterprise Deployment
Roadmap for Implementing the Primary IAM Suite Topologies
This roadmap introduces you to the different tasks that need to be performed for implementing the primary IAM suite topologies on Kubernetes. This guide supports deployments on Oracle Kubernetes Engine (OKE), Oracle Cloud Native Environment, and the on-premises based Kubernetes deployments.
Regardless of the platform chosen, unless otherwise stated, the deployment steps are the same.
Table 4-7 Roadmap for Implementing Primary IAM Suite Topologies on Kubernetes
Scenario | Tasks | For More Information, See |
---|---|---|
Creating an IAM Enterprise Deployment manually on commodity hardware |
Know about a typical enterprise deployment. |
About a Typical Enterprise Deployment |
Procure resources for the enterprise deployment. |
Procuring Resources for an On-Premises Enterprise Deployment Procuring Resources for an Oracle Cloud Infrastructure Deployment |
|
Prepare your environment for enterprise deployment. |
Preparing for an On-Premises Enterprise Deployment Preparing the Oracle Cloud Infrastructure for an Enterprise Deployment |
|
Procure the required software. |
||
Prepare the existing database for the deployment. |
||
Configure Oracle Unified Directory. |
||
Configure Oracle HTTP Server/Web Tier. |
||
Install the WebLogic Operator for Kubernetes. |
||
Create and configure the Oracle Fusion Middleware Infrastructure for Oracle Access Management. |
||
Create and configure the Oracle Fusion Middleware Infrastructure for Oracle Identity Governance. |
||
Install and configure Oracle Identity Role Intelligence |
Installing and Configuring Oracle Identity Role Intelligence |
|
Configure server migration settings. |
Using Whole Server Migration and Service Migration in an Enterprise Deployment |
Parent topic: About the IAM Enterprise Deployment
Building Your Own Oracle Identity and Access Management Topology
These step-by-step instructions help you configure the two primary enterprise topologies for Oracle Identity and Access Management. However, Oracle recognizes that the requirements of your organization may vary, depending on the specific set of Oracle Fusion Middleware products you purchase and the specific types of applications you deploy.
For information on the primary enterprise topology for Oracle Identity and Access Management, see iam-enterprise-deployment.html#GUID-6E3F9FD0-F706-4199-A144-6473AD320003__CHDFBIDE.
In many cases, you can install and configure an alternative topology, one that includes additional components, or one that does not include all the Oracle Identity and Access Management products shown in the primary topology diagrams.
A few alternatives to the reference Oracle Identity and Access Management topologies you can implement by using the steps provided in this guide are:
- OAM only with an existing directory
- OIM only with an existing directory
- OAM/OIM integrated in a modular deployment
- OAM/OIM integrated with an existing directory
- OIRI integrated with OIG
- OAA integrated with OAM
Parent topic: About the IAM Enterprise Deployment