1. Enterprise Deployment Guide for Oracle Identity and Access Management in a Kubernetes Cluster
  2. About an Enterprise Deployment
  3. About the IAM Enterprise Deployment

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:

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

Oracle strongly recommends the use of a demilitarized zone (DMZ) to ensure maximum security for your organization. See About the 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.

Parent topic: About the IAM Enterprise Deployment

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. The new Oracle IDM Microservices are deployed inside a Kubernetes cluster and they interact with the core IDM components in a traditional deployment.

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.

If you are new to Kubernetes and want to keep your existing enterprise deployment, but extend the deployment with the new microservices, then you can follow the instructions in this guide to deploy just those microservices. If you decide to follow this route, then you have two options:
  • 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)

A Traditional Deployment of Oracle Identity and Access Management with Microservices (in a Kubernetes Cluster)

Parent topic: Topology Diagrams for the Deployment of Oracle Identity and Access Management

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


Deployment of Oracle Identity and Access Management in a Kubernetes Cluster

Parent topic: Topology Diagrams for the Deployment of Oracle Identity and Access Management

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. For simplicity, each product is separated into distinct diagrams.

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.

Parent topic: Topology Diagrams for the Deployment of Oracle Identity and Access Management Components on Kubernetes

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

OUD using the Ingress Controller
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


OAM and OIG Using an Ingress Controller

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

Integrated OIRI Using the Ingress Controller
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

OAA Using an Ingress Controller

Secondary Deployment Topologies

These topologies are fully supported alternative deployments that you can consider using.

Parent topic: Topology Diagrams for the Deployment of Oracle Identity and Access Management Components on Kubernetes

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


Oracle Unified Directory Services Manager Inside a Kubernetes Cluster

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

Oracle Identity and Access Management Inside a Kubernetes Cluster
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


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


Oracle Identity Role Intelligence inside a Kubernetes cluster

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


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


Standalone OAA Using Ingress on Kubernetes

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.

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.

In addition to the domains above, the following components are deployed without a domain:
  • 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.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

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.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

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.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

About Oracle Identity Role Intelligence

Role-Based Access Control (RBAC) has the following challenges:
  • 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.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

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.

OAA has the following features:
  • 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.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

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 and prov.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.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

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.

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

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

Parent topic: About the Primary Oracle Identity and Access Management Topology Diagrams

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.

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

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

Recommended Directory Structure for Oracle identity Role Intelligence

Figure 4-15 Recommended Directory Structure for Oracle Advanced Authentication

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

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

Physical Structure of Shares on a Storage Appliance

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

webbinaries1

/exports/IAMBINARIES1/webbinaries1

WEBHOST1

/u02/private/oracle/products

Read/Write

10 GB

Local storage for the Oracle HTTP Server software binaries (Oracle Home).

IAMBINARIES2

webbinaries2

/exports/IAMBINARIES2/webbinaries2

WEBHOST2

/u02/private/oracle/products

Read/Write

10 GB

Local storage for the Oracle HTTP Server software binaries (Oracle Home).

IAMPVS

oampv

/exports/IAMPVS/oampv

OAM

/u01/oracle/user_projects

Read/Write

5 GB

Shared storage for the OAM domain.

IAMPVS

oigpv

/exports/IAMPVS/oigpv

OIG

/u01/oracle/user_projects

Read/Write

5 GB

Shared storage for the OIG domain.

IAMPVS

oudpv

/exports/IAMPVS/oudpv

LDAP

/u01/oracle/user_projects

Read/Write

10 GB

Shared storage for OUD instances. This is where the Oracle home directory and product directories are installed.

IAMPVS

oudconfigpv

/exports/IAMPVS/oudconfigpv

LDAP

/u01/oracle/config-input

Read/Write

5 GB

Shared storage for the configuration files required to set up OUD.

IAMPVS

oudsmpv

/exports/IAMPVS/oudsmpv

OUDSM

/u01/oracle/user_projects

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

oaaconfigpv

/exports/IAMPVS/oaaconfigpv

oaa-mgmt

/u01/oracle/scripts/settings

Read/Write

  

Used to store the customized configuration file for installing OAA and OARM.

IAMPVS

oaacredpv

/exports/IAMPVS/oaacredpv

oaa-mgmt

/u01/oracle/scripts/cred

Read/Write

  

Used to store credential files such as k8sconfig, helmconfig, trust.p12, and cert.p2.

IAMPVS

oaalogpv

/exports/IAMPVS/oaalogpv

oaa-mgmt

/u01/oracle/logs

Read/Write

  

Used to store installation logs and status.

IAMPVS

oaavaultpv

/exports/IAMPVS/oaavaultpv

oaa-mgmt

/u01/oracle/service/store/oaa

Read/Write

  

Used to store the vault artifacts for a file-based vault.

IAMCONFIG

webconfig1

/exports/IAMCONFIG/webconfig1

WEBHOST1

/u02/private/oracle/config

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

webconfig2

/exports/IAMCONFIG/webconfig2

WEBHOST2

/u02/private/oracle/config

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

images

/exports/IMAGES/images

Kubernetes Workers

/images

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 the binary 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.

CONTAINER_HOME/oracle

/u01/oracle

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

/u01/oracle/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 soa, wcc, idm, bi, or another value, depending on your enterprise deployment.

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 domain_name with the name of the WebLogic Server domain.

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 domain_name with the name of the WebLogic Server domain.

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 domain_name with the name of the WebLogic Server domain.

WEB_CONFIG_DIR

This is the location where you edit the Oracle HTTP Server configuration files (for example, httpd.conf and moduleconf/*.conf) on each web host.

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.

/u02/private/oracle/config/domains/domain_name/config/fmwconfig/components/OHS/instance/instance_name

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
  • User Preferences User Interface
  • MFA Authentication UI
  • Forgot Password UI

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

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

About the Kubernetes Deployment

About Oracle Identity Management on Kubernetes

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.

Procuring Software for an Enterprise Deployment

Prepare the existing database for the deployment.

Preparing an Existing Database for an Enterprise Deployment

Configure Oracle Unified Directory.

Installing and Configuring Oracle Unified Directory

Configure Oracle HTTP Server/Web Tier.

Installing and Configuring Oracle HTTP Server

Install the WebLogic Operator for Kubernetes.

Installing the WebLogic Kubernetes Operator

Create and configure the Oracle Fusion Middleware Infrastructure for Oracle Access Management.

Configuring Oracle Access Manager Using WDT

Create and configure the Oracle Fusion Middleware Infrastructure for Oracle Identity Governance.

Configuring Oracle Identity Governance Using WDT

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