19 Configuring Oracle Identity Governance Using WDT

Install and configure an initial domain to use as the starting point for an enterprise deployment. Later, configure this domain.

A complete Oracle Identity and Access Management uses a split domain deployment, where there is a single domain for Oracle Access Management and a different domain for Oracle Identity Governance.

In version 4.1.2 of the WebLogic Kubernetes Operator, two different methods to create Oracle WebLogic domains are available. The traditional WLST method uses WLST scripts to create the domain which is the method employed in the Enterprise Deployment Guide for several releases.

Starting with this release, the Enterprise Deployment Guide will use the Weblogic Deployment Tools (WDT) to create the domains. The WDT uses templates to create domains which simplifies the installation procedure. For more information about WebLogic deployment tools, see WebLogic Deploy Tooling

This chapter includes the following topics:

• Synchronizing the System Clocks
  Before you deploy Oracle Identity Governance, verify that the system clocks on each host computer are synchronized. You can do this by running the date command simultaneously on all the hosts in each cluster.
• About the Initial Infrastructure Domain
  Before you create the initial Infrastructure domain, ensure that you review the key concepts.
• Prerequisites
  Before creating the Oracle Identity Governance (OIG) on the kubernetes infrastructure, you should have downloaded the Oracle Identity Governance container image and installed the Oracle WebLogic Operator.
• Creating a Namespace for Oracle Identity Governance
  Create a namespace to contain all the Oracle Identity Governance Kubernetes objects.
• Creating a Container Registry Secret
  If you are using a container registry and want to pull the Oracle container images on demand, you must create a secret which contains the login details of the container registry.
• Creating a Kubernetes Secret for Docker Hub Images
  This secret allows Kubernetes to pull an image from hub.docker.com which contains third-party images such as helm, kubectl, and logstash commands.
• Creating the Database Schemas for Oracle Identity Governance
  Oracle Fusion Middleware components require schemas in a database, these schemas are handled by the WebLogic Deployment Tools at the time of deployment.
• Creating the Oracle Identity Governance Domain
  To create the Oracle Identity Governance domain, you should configure the WebLogic Kubernetes Operator for the domain namespace, create the Kubernetes secrets, and then create the Governance domain.
• Creating the Kubernetes Services
  By default, the OIG domain gets created with all the components (except the Administration Server) configured as ClusterIP services. This means that the Oracle Identity Governance components are visible only within the Kubernetes cluster.
• Tuning JMS Queues
  To ensure maximum throughput, tune the JMS queues.
• Installing the Connector Bundle
  After you create the domain, you need to copy any connectors you require, to the Kubernetes container. These connectors must be stored on the persistent volume.
• Performing the Post-Configuration Tasks for Oracle Identity Management Domain
  The post-configuration tasks for the OIG domain include creating the server overrides file and updating the data sources.
• Validating Identity Governance
  Perform a few tests to validate your installation.
• Analyzing the Bootstrap Report
  When you start the Oracle Identity Governance server, the bootstrap report is generated at $DOMAIN_HOME/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.html.
• Configuring the Web Tier for the Domain
  If you have not already done so, configure the web server instances on the web tier so that the instances route requests for both public and internal URLs to the proper clusters in the extended domain.
• Integrating Oracle Identity Governance with Oracle SOA Suite
  You can integrate Oracle Identity Governance with Oracle SOA suite using the load balancer entry points to maintain high availability.
• Managing the Notification Service
  An event is an operation that occurs in Oracle Identity Manager, such as user creation, request initiation, or any custom event created by the user. These events are generated as part of the business operations or through the generation of errors. Event definition is the metadata that describes the event.
• Configuring the Messaging Drivers
  Each messaging driver needs to be configured. You have to configure this service if you want to enable OAM's forgotten password functionality.
• Increasing Database Connection Pool Size
  The default database connection pool size needs to be increased when Oracle Identity Governance is used in conjunction with a connector that allows interactions with an LDAP directory.
• Integrating Oracle Identity Governance with LDAP
  Before you integrate OIG with LDAP, you should configure the connector for LDAP and add the required object classes if any are missing.
• Integrating Oracle Identity Governance and Oracle Access Manager
  You have to complete several tasks to integrate Oracle Identity Governance and Oracle Access Manager. These tasks include creating the WLS authentication providers, deleting OIMSignatureAuthenticator and recreating OUDAuthenticator, adding the administration role to the new administration group, and so on.
• Running the Reconciliation Jobs
  Run the Oracle Identity Governance domain to import the LDAP user names into the Oracle Identity Governance database.
• Configuring OIM Workflow Notifications to be Sent by Email
  OIM uses the human workflow, which is integrated with the SOA workflow. The SOA server configures email to receive the notifications that are delivered to the user mailbox. The user can accept or reject the notifications.
• Adding the wsm-pm Role to the Administrators Group
  After you configure a new LDAP-based Authorization Provider and restart the Administration Server, add the enterprise deployment administration LDAP group (WLSAdministrators) as a member to the policy.Updater role in the wsm-pm application stripe.
• Adding the WebLogic Administration Group to SOA Administrators
  To manage SOA using the users in the LDAP administration group 'WLSAdministrators', you should add the name of the group to the SOA Administrators group.
• Adding the Oracle Access Manager Load Balancer Certificate to the Oracle Keystore Service
  The Oracle Identity Governance to Business Intelligence Reports link inside of the Self Service application requires that the SSL certificate used by the load balancer be added to the Oracle Keystore Service Trusted Certificates.
• Setting the Initial Server Count
  When you first created the domain, you specified that only one Managed Server has to be started. This value ensured that the OIG bootstrap process was completed successfully. After you complete the configuration, you can increase the initial server count to the actual number you require.
• Setting Challenge Questions
  If you have integrated OAM and OIM, then after the environment is ready, you need to set up the challenge questions for your system users.
• Integrating Oracle Identity Manager with Oracle Business Intelligence Publisher
  Oracle Identity Manager comes with a number of prebuilt reports that can be used to provide information about Oracle Identity and Access Management.
• Enabling Design Console Access
  You cannot access the Design Console that is installed as part of the installation because it is inside a container and requires access to an external X Window environment.
• Centralized Monitoring Using Grafana and Prometheus
  If you are using a centralized Prometheus and Grafana deployment to monitor your infrastructure, you can send Oracle Identity Governance data to this application.
• Centralized Log File Monitoring Using Elasticsearch and Kibana
  If you are using Elasticsearch and Kibana, you can configure a Logstash pod to send the log files to the centralized Elasticsearch/Kibana console. Before you configure the Logstash pod, ensure that you have access to a centralized Elasticsearch deployment.
• Backing Up the Configuration
  As a best practice, Oracle recommends you to back up the configuration after you have successfully extended a domain or at another logical point. Back up only after you have verified that the installation is successful so far. This is a quick backup to enable immediate restoration in case of problems in later steps.
• Running the OIM Bulkload Utility from a Container
  If you want to run the oimbulkload utility from a container, create a new container image based on the Oracle Database Instant Client which also has a JDK and the oimbulkload utility installed.

Synchronizing the System Clocks

Before you deploy Oracle Identity Governance, verify that the system clocks on each host computer are synchronized. You can do this by running the date command simultaneously on all the hosts in each cluster.

Alternatively, there are third-party and open-source utilities you can use for this purpose.

About the Initial Infrastructure Domain

Before you create the initial Infrastructure domain, ensure that you review the key concepts.

• About the Software Distribution
  
• Characteristics of the Domain
  
• Variables Used in this Chapter
  
• Kubernetes Services
  

About the Software Distribution

You create the initial Infrastructure domain for an enterprise deployment by using the Oracle WebLogic Operator. The Oracle Identity Governance software is distrubted as a pre-built container image. See Identifying and Obtaining Software Distributions for an Enterprise Deployment. This distribution contains all of the necessary components to install and configure Oracle Identity Governance.

See Understanding Oracle Fusion Middleware Infrastructure in Understanding Oracle Fusion Middleware.

Characteristics of the Domain

The following table lists some of the key characteristics of the domain that you are about to create. Reviewing these characteristics helps you to understand the purpose and context of the procedures that are used to configure the domain.

Many of these characteristics are described in more detail in Understanding a Typical Enterprise Deployment.

Characteristic of the Domain	More Information
Places each WebLogic domain in a Kubernetes cluster.	See About the Kubernetes Deployment.
Each WebLogic Server is placed into a pod in the Kubernetes cluster.	See About the Kubernetes Deployment.
Places each Kubernetes domain object in a dedicated Kubernetes namespace.	See About the Kubernetes Deployment.
Uses Kubernetes NodePort Services to interact with the WebLogic Managed servers.	See Creating the Kubernetes Services.
Uses Kubernetes persistent volumes to hold the domain configuration.	See unresolvable-reference.html#GUID-CF07EE44-34D9-4F36-97BE-6B3FBB4FCEA8.
Each Kubernetes pod is built from a pre-built Oracle container image.	See Identifying and Obtaining Software Distributions for an Enterprise Deployment.
Uses a per domain Node Manager configuration.	See About the Node Manager Configuration in a Typical Enterprise Deployment.
Requires a separately installed LDAP-based authentication provider.	See Installing and Configuring Oracle Unified Directory.
Certificates are stored in the Oracle Keystore Service.	See Configuring Oracle OPSS Keystore Service.
JMS and TLOGS are stored in the database.	See Using a JDBC Store.

Variables Used in this Chapter

The later sections of this chapter provide instructions to create a number of files. These sample files contain variables which you need to substitute with values applicable to your deployment.

Variables are formatted as <VARIABLE_NAME>. The following table provides the values you should set for each of these variables.

Table 19-1 The Variables to be Changed

Variable	Sample Value(s)	Description
<REGISTRY_ADDRESS>	iad.ocir.io/<mytenancy>	The location of the registry.
<REGISTRY_SECRET_NAME>	regcred	The name of the Kubernetes secret containing the container registry credentials. Required only if you are pulling images directly from a container registry. See Creating a Container Registry Secret.
<REG_USER>	mytenancy/oracleidentitycloudservice/[e-mail]	The name of the user you use to log in to the registry.
<REG_PASSWORD>	<password>	The registry user password.
<OIG_REPOSITORY>	oracle/oig local/oracle/oig container-registry.oracle.com/middleware/oig_cpu <REGISTRY_ADDRESS>/oracle/oig	The name of the OIG software repository. If you have downloaded and staged a container image, this value will be: oracle/oig. If you use OLCNE, the value will be local/oracle/oig. If you use the oracle container registry, the value will be container-registry.oracle.com/middleware/oig_cpu. If you use a container registry, the value will be the name of the registry with the product name: <REGISTRY_ADDRESS>/oracle/oig.
<OIG_VER>	12.2.1.4-jdk8-ol7-220420.0828 or latest.	The version of the image you want to use. This will be the version you have downloaded and staged either locally or in the container registry.
<PVSERVER>	nfsserver.example.com	The name or IP address of the NFS server Note: This name should be resolvable inside the Kubernetes cluster.
<OIGNS>	oigns	The name of the OIG domain namespace.
<WORKDIR>	workdir/OIG	The location where you want to create the working directory for OAM.
<K8WORKER>	k8worker1.example.com	One of the Kubernetes hosts where the external WebLogic Administration Server Kubernetes service is resolvable.
<OIG_SHARE>	/exports/IAMPVS/oigpv	The NFS export for the persistence store.
<OID_BULK_SHARE>	/exports/IAMPVS/oigbulkpv	The persistent volume used for storing data to be loaded through the bulk load utility.
<OIG_DB_SCAN>	dbscan.example.com	The SCAN address of the RAC database.
<OIG_DB_LISTENER>	1521	The listener port number of the RAC database .
<OIG_DB_SERVICE>	igdedg.example.com	The name of the database service. If you are using a PDB, specify the name of the PDB service.
<OIG_DB_SYS_PWD>	MySysPWD__001	The SYS password for the database.
<OIG_RCU_PREFIX>	IADEDG	The prefix used when the database schemas are created.
<OIG_SCHEMA_PWD>	MySchemaPWD__001	The password you want to set for the product schemas being created.
<OIG_WEBLOGIC_USER>	weblogic	The name of the administration user for IAMGovernance domain.
<OIG_WEBLOGIC_PWD>	mypassword	The password for the WebLogic user.
<OIG_DOMAIN_NAME>	governancedomain	The name of the domain to be created.
<OIG_DOMAIN_SECRET>	governancedomain-weblogic-credentials	The name of the secret you want to create, for the namespace that is used. The name of the secret must be <OIG_DOMAIN_NAME>-weblogic-credentials.
<OIG_RCU_SECRET>	governancedomain-rcu-credentials	The name of the RCU secret. The name of the secret must be <OIG_DOMAIN_NAME>-rcu-credentials. See Creating the RCU Secret.
<OIG_LBR_HOST>	prov.example.com	The load balancer entry point for OIM.
<OIG_LBR_PORT>	443	The load balancer port for OIM.
<OIM_SERVER_NAME>	oim_server1	The name of the OIM server.
<OIG_EMAIL_DOMAIN>	example.com	The email domain.
<OIG_ADMIN_PORT>	7101	The internal port assigned to the OIG Administration Server.
<WG_CONNECTIONS>	20	The maximum number of connections supported by the WebGate agent.
<LDAP_TYPE>	OUD	It is the type of directory you are using: OUD or OID.
<LDAP_OAMADMIN_USER>	oamadmin	The name of the user you want to administer OAM. See Creating a Configuration File.
<LDAP_OAMLDAP_USER>	oamLDAP	The name of a user that OAM will use to connect to the directory for validating logins.
<LDAP_XELSYSADM_USER>	xelsysadm	The OIM administrator account.
<LDAP_HOST>	idstore.example.com edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local	The load balancer name for the LDAP directory. If your LDAP directory is inside the Kubernetes cluster, then you can use the Kubernetes service name, which has this format: <K8_SERVICE_NAME>.<NAMESPACE>.svc.cluster.local. If you are wiring to an LDAP directory external to the Kubernetes cluster, then you should specify the name of the external load balancer.
<LDAP_PORT>	1389	It is the LDAP port of the load balancer.
<LDAP_ADMIN_USER>	cn=oudadmin for OUD.	The credential used to connect to the directory to perform administrative actions.
<LDAP_OIGLDAP_USER>	oimLDAP	The name of the user that OIM uses to connect to LDAP for validating logins.
<LDAP_SYSTEMIDS>	cn=systemids	The name of a container where you want to store system ids. The user names placed in this container are not subject to OIM reconciliation or password aging. This container is reserved for users such as <LDAP_OAMLDAP_USER> and <LDAP_OIGLDAP_USER>.
<LDAP_SEARCHBASE>	dc=example,dc=com	The directory tree for your organization. This is where all the data is stored.
<LDAP_USER_SEARCHBASE>	cn=Users,dc=example,dc=com	The location in the directory where names of users are stored.
<LDAP_GROUP_SEARCHBASE>	cn=Groups,dc=example,dc=com	The location in the directory where user groups are stored.
<LDAP_USER_PWD>	<password>	Contains the password of the <LDAP_OAMADMIN_USER> account.
<OAM_LOGIN_LBR_HOST>	login.example.com	The listen address of the front end load balancer for the OAM cluster.
<OAM_LOGIN_LBR_PORT>	443	The port of the front end load balancer for the OAM cluster.
<OAM_WEBLOGIC_USER>	weblogic	The administration user of the OAM Administration Server.
<OAM_WEBLOGIC_PWD>	<password>	The optional password for <OAM_WEBLOGIC_USER>.
<OAM_OAP_PORT>	5575	The internal OAP port number. If you are using the Kubernetes service, this value can be the internal port number.
<OAP_SERVICE_PORT>	30540	The Kubernetes service port which fronts the OAM OAP cluster nodes. If you are using the Kubernetes service, this value can be the internal port number.
<GLOBAL_PASSPHRASE>	-	Set this to the global passphrase. For obtaining the value, see Obtaining a Global Passphrase.
<OIG_SERVER_COUNT>	5	The number of Managed Servers required. Oracle highly recommends you to set this value to a number greater than the anticipated need in the system's lifetime. It creates a number of server definitions in the WebLogic domain and ensures that you have a simple mechanism to scale up the system when the demand increases. This value does not reflect the number of server instances you actually start with; it just enables you to start additional servers if your needs change. Adding additional server definitions post domain creation is a complex task and should be avoided, if possible.
<OIG_INITIAL_SERVERS>	1	The number of Managed Servers to start. Oracle recommends you to set this value to 1 for the duration of the configuration.
<OIM_MAX_CPU>	1	Maximum number of CPUs each OIG_SERVER pod is allowed to consume. The CPU is measured in CPU cores and the value of 1 is equal to 1 CPU core or 1 virtual core.
<OIM_CPU>	500m	The initial number of CPUs each OIM_SERVER pod is allowed to consume. It is measured in CPU cycles and the value of 1000m is equal to 1 CPU core or 1 virtual core. The CPU is measured in CPU cores and the value of 1 is equal to 1 CPU core or 1 virtual core.
<SOA_MAX_CPU>	1	Maximum number of CPUs each SOA_SERVER pod is allowed to consume. The CPU is measured in CPU cores and the value of 1 is equal to 1 CPU core or 1 virtual core.
<SOA_CPU>	500m	The initial number of CPUs each SOA_SERVER pod is allowed to consume. It is measured in CPU cycles and the value of 1000m is equal to 1 CPU core or 1 virtual core. The CPU is measured in CPU cores and the value of 1 is equal to 1 CPU core or 1 virtual core.
<OIM_MAX_MEMORY>	8Gi	The maximum amount of memory that the OIM_SERVER pods are allowed to consume. The memory is measured in standard units, where 1G is equal to 1Gi.
<OIM_MEMORY>	4Gi	The initial amount of memory that the OIM_SERVER pods are allowed to consume. The memory is measured in standard units, where 1G is equal to 1Gi.
<OIMSERVER_JAVA_PARAMS>	-Xms4096m -Xmx8192m	The maximum (Xmx) and minimum heap size to allocate to each OIM_SERVER. Sizes are shown as a number of Mb. Note: The maximum amount of heap size must be less than the maximum amount allowed to be used by the pod <OIM_MAX_MEMORY>.
<SOASERVER_JAVA_PARAMS>	-Xms4096m -Xmx8192m	The maximum (Xmx) and minimum heap size to allocate to each SOA_SERVER. Sizes are shown as a number of Mb. Note: The maximum amount of heap size must be less than the maximum amount allowed to be used by the Pod <SOA_MAX_MEMORY>.
<OIG_OIM_T3_PORT_K8>	30142	The Kubernetes service port you want to use.
<OIG_ADMIN_K8>	30711	The external Kubernetes service port for the external WebLogic Administration Server.
<ELK_HOST>	https://elasticsearch-es-http.elkns.svc:9200	The host and port of the centralized Elasticsearch deployment. This host can be inside the Kubernetes cluster or external to it. This host is used only when Elasticsearch is used.
<ELK_VER>	8.11.0	The version of Elasticsearch you want to use.

Kubernetes Services

If you are using NodePort Services, the following Kubernetes services are created as part of this deployment:

Table 19-2 Kubernetes NodePort Services

Service Name	Type	Service Port	Mapped Port
governancedomain-oim-http-NodePort	NodePort	30140	14000
governancedomain-soa-http-NodePort	NodePort	30801	8001
governancedomain-adminserver-external	NodePort	30711	7101

If you are using an Ingress-based deployment, the following Ingress services are created as part of your deployment:

Table 19-3 Ingress Services

Service Name	Host Name
oigadmin-ingress	igdadmin.example.com
oigruntime-ingress	prov.example.com
oiginternal-ingress	igdinternal.example.com

Prerequisites

Before creating the Oracle Identity Governance (OIG) on the kubernetes infrastructure, you should have downloaded the Oracle Identity Governance container image and installed the Oracle WebLogic Operator.

• To download the Oracle Governance Manager Image and load it into the Docker image repository (this repository must be visible to each Kubernetes node), see Identifying and Obtaining Software Distributions for an Enterprise Deployment.
• To install the Oracle WebLogic Operator, see Installing and Configuring WebLogic Kubernetes Operator.

• Setting Up a Product Specific Work Directory
  

Setting Up a Product Specific Work Directory

Before you begin the installation, you should have downloaded and staged the Oracle Identity Governance container image and the code repository. See Downloading Images from a Container Registry and Staging the Code Repository. You must also have deployed the Oracle WebLogic Operator as described in Installing the WebLogic Kubernetes Operator.

This section describes copying the downloaded sample deployment scripts to a temporary working directory on the configuration host for OIG.

1. Create a temporary working directory as the install user. The install user should have kubectl access to the Kubernetes cluster.

   mkdir -p /<WORKDIR>

   For example:

   mkdir -p /workdir/OIG

2. Change directory to this location:

   cd /workdir/OIG

3. Copy the sample scripts to the work directory.

   cp -R <WORKDIR>/fmw-kubernetes/OracleIdentityGovernance/kubernetes <WORKDIR>/samples

   For example:

   cp -R /workdir/OIG/fmw-kubernetes/OracleIdentityGovernance/kubernetes /workdir/OIG/samples

Creating a Namespace for Oracle Identity Governance

Create a namespace to contain all the Oracle Identity Governance Kubernetes objects.

1. To create a namespace, use the following command:

   kubectl create namespace <OIGNS>

   For example:

   kubectl create namespace oigns

   The output appears as follows:

   namespace/oigns created

2. Tag the namespace so that the WebLogic Kubernetes Operator can manage it.

   kubectl label namespaces oamns weblogic-operator=enabled

Creating a Container Registry Secret

If you are using a container registry and want to pull the Oracle container images on demand, you must create a secret which contains the login details of the container registry.

Note:

If you are not using a container registry, you still need to create the registry secret. However, the user name and password need not contain meaningful data.

To create a container registry secret, use the following command:

kubectl create secret -n <OIGNS> docker-registry <REGISTRY_SECRET_NAME> --docker-server=<REGISTRY_ADDRESS> --docker-username=<REG_USER> --docker-password=<REG_PWD>

For example:

kubectl create secret -n oigns docker-registry regcred --docker-server=iad.ocir.io/mytenancy --docker-username=mytenancy/oracleidentitycloudservice/[e-mail] --docker-password=<password>

Creating a Kubernetes Secret for Docker Hub Images

This secret allows Kubernetes to pull an image from hub.docker.com which contains third-party images such as helm, kubectl, and logstash commands.

Note:

If you are pulling the images from your own container registry, then this step is not required.

You should have an account on hub.docker.com. If you want to stage the images in your own repository, you can do so and modify the helm override file as appropriate.

To create a Kubernetes secret for hub.docker.com, use the following command:

$ kubectl create secret docker-registry dockercred --docker-server="https://index.docker.io/v1/" --docker-username="<DH_USER>" --docker-password="<DH_PWD>" --namespace=<OIGNS>

For example:

$ kubectl create secret docker-registry dockercred --docker-server="https://index.docker.io/v1/" --docker-username="username" --docker-password="<mypassword>" --namespace=oigns

Creating the Database Schemas for Oracle Identity Governance

Oracle Fusion Middleware components require schemas in a database, these schemas are handled by the WebLogic Deployment Tools at the time of deployment.

The tool creates the following schemas:

• Metadata Services (MDS)
• Audit Services (IAU)
• Audit Services Append (IAU_APPEND)
• Audit Services Viewer (IAU_VIEWER)
• Oracle Platform Security Services (OPSS)
• User Messaging Service (UMS)
• WebLogic Services (WLS)
• Common Infrastructure Services (STB)

For more information about RCU and how the schemas are created and stored in the database, see Preparing for Schema Creation in Creating Schemas with the Repository Creation Utility.

Complete the following steps to install the required schemas:

• Installing and Configuring a Certified Database
  
• Configuring OIM Schemas for Transactional Recovery
  

Installing and Configuring a Certified Database

Make sure that you have installed and configured a certified database, and that the database is up and running.

See Preparing an Existing Database for an Enterprise Deployment.

Configuring OIM Schemas for Transactional Recovery

After you have installed the Oracle Identity Governance successfully, use the procedure in this section to configure the schemas for transactional recovery.

This procedure sets the appropriate database privileges so that the Oracle WebLogic Server transaction manager can query the schemas for transaction state information and issue the appropriate commands, such as commit and rollback, during recovery of in-flight transactions after a WebLogic Server is unexpectedly unavailable.

These privileges should be granted to the owner of the OIM schema, which you defined when you created the schemas with the Repository Creation Utility.

To configure the OIM schemas for transactional recovery privileges:

1. Log on to SQL*Plus as a user with sysdba privileges. For example:

   sqlplus "/ as sysdba"
   

2. If you are using a PDB, change your session to the PDB hosting IDM. For example:

   alter session set container=igdpdb;

3. Enter the following commands:

   grant select on sys.dba_pending_transactions to <OIG_RCU_PREFIX>_oim;

   Grant succeeded.

   SQL> grant force any transaction to <OIG_RCU_PREFIX>_oim;

   Grant succeeded.

Creating the Oracle Identity Governance Domain

To create the Oracle Identity Governance domain, you should configure the WebLogic Kubernetes Operator for the domain namespace, create the Kubernetes secrets, and then create the Governance domain.

• Creating the Kubernetes Secrets
  
• Creating the Governance Domain
  

Creating the Kubernetes Secrets

Rather than passing the credentials directly into the domain creation process, you can use the Kubernetes secrets to store the credentials in the encrypted format. The WebLogic Operator reads these secrets instead of asking for credentials.

• Creating the Domain Secret
  
• Creating the RCU Secret
  

Creating the Domain Secret

The domain secret contains information about the WebLogic Administration user who creates the domain.

1. Use the following command to create the domain secret:

   cd <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils

   ./create-secret.sh -l "username=<OIG_WEBLOGIC_USER>" -l "password=<OIG_WEBLOGIC_PWD>" -n <OIGNS> -d <OIG_DOMAIN_NAME> -s <OIG_DOMAIN_SECRET>

   For example:

   cd /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/wdt-utils

   ./create-secret.sh -l "username=weblogic" -l "password=mypassword" -n oigns -d governancedomain -s governancedomain-weblogic-credentials

   The output appears as follows:

   secret/governancedomain-weblogic-credentials created
   secret/governancedomain-weblogic-credentials labeled 
   The secret governancedomain-weblogic-credentials has been successfully created in the oigns namespace

2. Verify that the secret has been created, using the following command:

   kubectl get secret governancedomain-weblogic-credentials -o yaml -n oigns

Creating the RCU Secret

The RCU secret is used by the WebLogic Operator to determine how to connect to the database schemas that you have already created. See Creating the Database Schemas for Access Manager.

To create the RCU secret, perform the following steps:

1. Use the following command:

   cd <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils

   ./create-secret.sh -l "rcu_prefix=<OIG_RCU_PREFIX>" -l "rcu_schema_password=<OIG_SCHEMA_PWD>" -l "db_host=<DB_HOST>" -l "db_port=<DB_PORT>" -l "db_service=<OIG_DB_SERVICE>" -l "dba_user=sys" -l "dba_password=<OIG_SYS_PWD>" -n <OIGNS> -d <OIG_DOMAIN_NAME> -s <OIG_RCU_SECRET>

   For example:

   cd /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/wdt-utils

   ./create-secret.sh -l "rcu_prefix=IGDEDG" -l "rcu_schema_password=MySchemaPWD__001" -l "db_host=DB-SCAN.example.com" -l "db_port=1521" -l "db_service=oig_s.example.com" -l "dba_user=sys" -l "dba_password=MySysPassword" -n oigns -d governancedomain -s governancedomain-rcu-credentials

   The output appears as follows:

   secret/governancedomain-rcu-credentials created
   secret/governancedomain-rcu-credentials labeled
   The secret governancedomain-rcu-credentials has been successfully created in the oigns namespace

2. Verify that the secret has been created, using the command:

   kubectl get secret governancedomain-rcu-credentials -o yaml -n oigns

Creating the Governance Domain

The procedure to create the Oracle Identity Governance domain includes creating the domain configuration file, creating the domain using the WebLogic Kubernetes Operator, setting the memory parameters, initializing the domain, and verifying the domain.

• Creating the Domain Configuration File
  
• Generate WDT Auxiliary Image
  
• Updating domain.yaml
  
• Creating the Domain Using the WebLogic Operator
  
• Verifying the Domain
  

Creating the Domain Configuration File

A configuration file is used to tell the WebLogic Operator how to create the domain. This configuration file is named create-domain-wdt.yaml and is located in <WORKDIR>/samples/create-oim-domain/domain-home-on-pv.

1. Create a copy of the create-domain-wdt.yaml file.
   For example:

   cp /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/create-domain-wdt.yaml /workdir/OIG/wdt-utils/generate_models_utils/create-domain-wdt.yaml

2. Make the following changes to the /workdir/OIG/create-domain-wdt.yaml file:

   domainUID: <OIG_DOMAIN_NAME> 
   domainPVMountPath: /u01/oracle/user_projects/
   domainHome: /u01/oracle/user_projects/domains/<OIG_DOMAIN_NAME> 
   image: <OIG_REPOSITORY>:<OIG_VER>
   imagePullSecretName: <REGISTRY_SECRET_NAME>
   namespace: <OIGNS> 
   weblogicCredentialsSecretName: <OIG_DOMAIN_SECRET> 
   logHome: /u01/oracle/user_projects/domains/logs/<OIG_DOMAIN_NAME> 
   exposeAdminNodePort: true
   configuredManagedServerCount: <OIG_SERVER_COUNT>
   initialManagedServerReplicas: <OIG_INITIAL_SERVERS>
   productionModeEnabled: true
   exposeAdminT3Channel: false
   adminPort: 7101
   adminNodePort: <OIG_ADMIN_K8>
   # Front End Host that will front end the oim and soa servers
   frontEndHost: <OIG_LBR_HOST>
   frontEndPort: <OIG_LBR_PORT>
   datasourceType: agl
   weblogicDomainStorageNFSServer: <PVSERVER>
   weblogicDomainStorageType: NFS
   weblogicDomainStoragePath: <OIG_SHARE>
   edgInstall: true
   oimServerJavaParams: <OIMSERVER_JAVA_PARAMS>
   
   oimMaxCPU: <OIM_MAX_CPU>
   oimCPU: <OIM_CPU>
   oimMaxMemory: <OIM_MAX_MEMORY>
   oimMemory: <OIM_MEMORY>
   
   soaServerJavaParams: <SOASERVER_JAVA_PARAMS>
   soaMaxCPU: <SOA_MAX_CPU>
   soaCPU: <OAM_CPU>
   soaMaxMemory: <SOA_MAX_MEMORY>
   soaMemory: <SOA_MEMORY>

   For example:

   domainUID: governancedomain 
   domainPVMountPath: /u01/oracle/user_projects/
   domainHome: /u01/oracle/user_projects/domains/governancedomain
   image: latest
   imagePullSecretName: regcred
   namespace: oigns 
   weblogicCredentialsSecretName: oig-domain-credentials
   persistentVolumeClaimName: governancedomain-domain-pvc
   logHome: /u01/oracle/user_projects/domains/logs/governancedomain 
   rcuSchemaPrefix: IGDEDG 
   rcuDatabaseURL: dbscan.example.com:1521/igdedg.example.com 
   rcuCredentialsSecret: oig-rcu-credentials
   exposeAdminNodePort: true
   configuredManagedServerCount: 5
   initialManagedServerReplicas: 1
   productionModeEnabled: true
   exposeAdminT3Channel: false
   adminPort: 7101
   adminNodePort: 30711
   # Front End Host that will front end the oim and soa servers
   frontEndHost: prov.example.com
   frontEndPort: 443
   datasourceType: agl

3. Save the configuration file.

Generate WDT Auxiliary Image

When creating a domain using the WebLogic deployment tool, a dedicated image is created which describes the deployment. This is based on the domain creation file described in Creating the Domain Configuration File. This image is then stored in a local container registry.

The benefit of using an auxiliary image with the configuration is that it can be used repeatedly to create multiple environments with slightly different properties. For example, the same image file can be used to create a development, testing, and production environment where only the database connection details vary. You need not create a new image each time you create a similar environment. This image must be stored in a registry where images are loaded, and you need have access to this registry.

The following sections describe how to generate the WDT model files, create an auxiliary image, and upload it to your repository.

Generating WDT Model Files

Perform the following steps to generate the WDT model files from the Domain Configuration file:

1. Change the directory to WDT utils directory of the samples download.

   cd <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils/generate_models_utils

   For Example:

   cd /workdir/OIG//samples/create-oim-domain/domain-home-on-pv/wdt-utils/generate_models_utils

2. Generate the model files using the generate_wdt_models.sh utility.

   ./generate_wdt_models.sh -i <WORKDIR>/create-domain-wdt.yaml -o <WORKDIR>

   Use -i to specify the location of the Domain configuration file you created in Creating the Domain Configuration File.

   Use -o to specify where the WDT Model files and templates should be created.

   For example:

   ./generate_wdt_models.sh -i /workdir/OIG/create-domain-wdt.yaml -o /workdir/OIG

   After running the utility, a directory is created called weblogic-domains which contain the generated files.

Sample Output with Input Parameters

export version="create-weblogic-sample-domain-inputs-v1"
export adminPort="7101"
export domainUID="governancedomain"
export configuredManagedServerCount="5"
export initialManagedServerReplicas="1"
export productionModeEnabled="true"
export t3ChannelPort="30012"
export datasourceType="agl"
export edgInstall="true"
export domainHome="/u01/oracle/user_projects/domains/governancedomain"
export image="iad.ocir.io/mytenancyoig:12.2.1.4-jdk8-ol8-apr24"
export imagePullSecretName="regcred"
export logHome="/u01/oracle/user_projects/domains/logs/governancedomain"
export exposeAdminT3Channel="false"
export adminNodePort="30711"
export exposeAdminNodePort="false"
export namespace="oigns"
javaOptions=-Dweblogic.StdoutDebugEnabled=false
export domainPVMountPath="/u01/oracle/user_projects"
export weblogicDomainStorageType="NFS"
export weblogicDomainStorageNFSServer="mynfsserver.example.com"
export weblogicDomainStoragePath="/exports/IAMPVS/oigpv"
export weblogicDomainStorageReclaimPolicy="Retain"
export weblogicDomainStorageSize="10Gi"
export frontEndHost="prov.example.com"
export frontEndPort="443"
export oimServerJavaParams="-Xms8192m -Xmx8192m "
export soaServerJavaParams="-Xms4096m -Xmx8192m"
export oimMaxCPU="1"
export oimCPU="500m"
export oimMaxMemory="8Gi"
export oimMemory="4Gi"
export soaMaxCPU="1"
export soaCPU="1000m"
export soaMaxMemory="10Gi"
export soaMemory="4Gi"

validateWlsDomainName called with governancedomain
WDT model file, property file and sample domain.yaml are genereted successfully at /workdir/OIG/weblogic-domains/governancedomain

Create Image Property File

After the model files are created, they need to be added to an image, and uploaded to your registry which begins with describing the target registry in a property file.

Perform the following steps to create an image property file:

1. Run the following command to ensure java is installed on your machine:

   which java

2. Copy the property file to your work directory.

   cp <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image/properties/build-domain-creation-image.properties <WORKDIR>

   For Example:

   cp /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image/properties/build-domain-creation-image.properties /workdir/OIG

3. Edit the file build-domain-creation-image.properties and add the following values:

   JAVA_HOME set this to the location of your JAVA installation found in Step 1.

   For Example:

   /usr

   • REPOSITORY set this to the location in your registry where the image file is to reside.

     For example,

     iad.ocir.io/<mytenancy>/idm/oig_wdt

     .

     Where oig_wdt is the name of the image you wish to create.

   • IMAGE_TAG used to assign a tag to the uploaded image, you can use anything here. In case of this example, we can use <OIG_DOMAIN_NAME>.

   • IMAGE_PUSH_REQUIRES_AUTH must be set to true if you do not allow non-authenticated uploads to your registry.

   • REG_USER must be set to the user in your registry where you wish to upload the image. This user must have upload privileges.

   • WDT_MODEL_FILE must be set to the file oam.yaml which was generated in the step above. For Example, <WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME>/oim.yaml.

   • WDT_VARIABLE_FILE must be set to the file oam.properties which was generated in the step above. For example, <WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME/>oim.properties.

   • REG_PWD must be set to the password of the above user and placed in a separate file in buiidpwd in the <WORKDIR> as shown below:

     REG_PASSWORD="<mypwd>"

     Sample build-domain-creation-image.properties

     
     # Copyright (c) 2024, Oracle and/or its affiliates.
     # Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
     # Input Property file for build-domain-creation-image.sh script
     
     #
     # set the JAVA_HOME environment variable to match the location of your Java installation. Java 8 or newer is required
     #
     JAVA_HOME=/usr
     
     #
     # Image Details
     #
     #Set the IMAGE_TAG, default oam-aux-v1 if not set.
     IMAGE_TAG=governancedomain
     # Set the BASE_IMAGE, default ghcr.io/oracle/oraclelinux:8-slim if not set.
     BASE_IMAGE=ghcr.io/oracle/oraclelinux:8-slim
     #
     # Container Registry
     #
     #Image will be created with REPOSITORY:IMAGE_TAG
     REPOSITORY=iad.ocir.io/<mytenancy>idm/oig_wdt
     # Container registry username
     REG_USER=<mytenancy>/oracleidentitycloudservice/[e-mail]
     #Set it to false if authentication is not required for pushing the image to registry, for example docker login already done in the host before invoking the script.
     IMAGE_PUSH_REQUIRES_AUTH=true
     #
     # WDT and WIT Variables
     #
     #Full path to wdt model files
     WDT_MODEL_FILE=/workdir/OIG/weblogic-domains/governancedomain/oim.yaml
     #Full path to wdt variable files
     WDT_VARIABLE_FILE=/workdir/OIG/weblogic-domains/governancedomain/oim.properties
     #Full path to wdt archive files
     WDT_ARCHIVE_FILE=""
     #If not set, Latest version will be used.
     WDT_VERSION="3.5.3"
     #If not set, latest will be used during every fresh run
     WIT_VERSION="1.12.1"
     
     #In Most cases, no need to use these parameters. Please refer https://oracle.github.io/weblogic-image-tool/userguide/tools/create-aux-image/ for details about them.
     TARGET=""
     CHOWN=""

Uploading WDT Auxiliary Image

Use the utility build-domain-creation-image.sh to create and upload the Auxiliary image:

For Example:

cd <WORKDIR>/samples/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image

./build-domain-creation-image.sh -i <WORKDIR>/build-domain-creation-image.properties -p <WORKDIR>/.buildpwd

For Example:

cd /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/wdt-utils/build-domain-creation-image

./build-domain-creation-image.sh -i /workdir/OIG/build-domain-creation-image.properties -p /workdir/OIG/.buildpwd

Extract from Sample Output

Getting image source signatures
Copying blob sha256:d56869e2b34f592d78b05cce249e0130a52fb73209bbb394bb329b1fed54a652
Copying blob sha256:ba40a64765a65573fb1b9cfc9e175bd53c420c7ce8ec1424fda55835efbb7055
Copying blob sha256:0b458bb8ab4506598a0a925a3110c079ffbf77f85e3b97713e4592a2cb47a97f
Copying blob sha256:9aa2b64b3e6fefe00a04b52511ffda5b5ab3018538a1c7b11c4af4300e9220e0
Copying blob sha256:8b4d3bacf0d79476c744efb9d80fc05c5e1298b2ce8c5ed88edc9a4a01198ba9
Copying blob sha256:3ae779ed2d0c15ccbf8b31ae75afcbb857bb731618e9bde89108e8079ed4e9fe
Copying blob sha256:306ac5e1f9589c0be83dfa010d3bc53097c7acb7ef0fd51d054d1e6545c35c84
Copying blob sha256:5002f0067a2f325a4e67415b2e6889568719d0020b1df7b07af6be945c332210
Copying blob sha256:97acec59a7dd3180feaa8c2257fa8ed8027e5763d6aedb1c8a4df1a740e1ecb7
Copying blob sha256:5778e746ec78114f3569e4729dc11cc746dc6af9b5ebcf577ae9fe94867b495d
Copying blob sha256:6e841a878721c1c37fc0885152697674be097dc5d81004188a2e1dd647850e3e
Copying config sha256:ff14e6503d9efa8858512e8e7401e9c1b7d532acf11ffc44fb866ed5f4de00f1
Writing manifest to image destination
Storing signatures
Pushed image iad.ocir.io/mytenancy/oig_wdt:governancedomain to image repository

Updating domain.yaml

While generating the WDT model files, a file called domain.yaml was created in the directory <WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME>. This file is used to create the WebLogic domain. Before using this file the auxiliary image you create must be added to the file by editing

domain.yaml

Locate the variable in the file %DOMAIN_CREATION_IMAGE% and replace it with the name of your image as <REPOSITORY>:<IMAGE_TAG> obtained from the file build-domain-creation-image.properties.

For example,

iad.ocir.io/mytenancy/idm/oig_wdt:accessdomain

Note:

If the registry where your image is located is different to the registry where your OIG image is stored then create a new secret with the credentials for the Auxiliary image registry using a different name to the main registry.

For example:

kubectl create secret -n oigns docker-registry regcred2 --docker-server=iad.ocir.io/mytenancy2 --docker-username=mytenancy/oracleidentitycloudservice/[e-mail] --docker-password=<password>

Update the file domain.yaml and replace the lines with the name of your new secret.

Add additional secret name if you are using a different registry for domain creation image.

Identify which secret contains the credentials for pulling an image.

  imagePullSecrets:

  - name: regcred2

Creating the Domain Using the WebLogic Operator

Create the domain using the following command:

cd <WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME>

kubectl create -f <WORKDIR>/weblogic-domains/<OIG_DOMAIN_NAME>/domain.yaml

For example:

cd /workdir/OIG/weblogic-domains/governancedomain

kubectl create -f /workdir/OIG/weblogic-domains/governancedomain/domain.yaml

Use the following to monitor the domain creation:

kubectl logs -n <OIGNS> <OIG_DOMAIN_DOMAIN>-introspector

kubectl describe domain -n <OIGNS> <OIG_DOMAIN_NAME>

For Example:

kubectl logs -n oigns governancedomain-introspector

kubectl describe domain -n oigns governancedomain

For more information, see the WebLogic operator logs.

For Example:

kubectl logs -n opns weblogic-operator-688f5dcdc4-qxnnz | grep <OIG_DOMAIN_NAME>

After the domain is created, the OAM Kubernetes pods is started automatically and can be viewed using the command:

kubectl get pods -n <OIGNS>

Verifying the Domain

To verify the creation of the domain, perform the following steps:

1. To confirm that the domain is created, use the following command:

   kubectl describe domain <domain_uid> -n <namespace>

   For example:

   kubectl describe domain governancedomain -n oigns

2. Verify that the domain pods and services have been created and started, using the following command:

   kubectl get all,domains -n oigns

   The output appears as follows:

   NAME                                                            READY   STATUS      RESTARTS   AGE   IP               NODE       NOMINATED NODE   READINESS GATES
   pod/governancedomain-adminserver                                1/1     Running     0          17h   192.168.14.205   slc09byd   <none>           <none>
   pod/governancedomain-create-fmw-infra-sample-domain-job-45mwk   0/1     Completed   0          23h   192.168.14.203   slc09byd   <none>           <none>
   pod/governancedomain-soa-server1                                1/1     Running     0          16h   192.168.14.206   slc09byd   <none>           <none>
   pod/helper                                                      1/1     Running     0          45h   192.168.14.202   slc09byd   <none>           <none>
   
   NAME                                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)               AGE    SELECTOR
   service/governancedomain-adminserver            ClusterIP   None             <none>        7101/TCP              17h    weblogic.createdByOperator=true,weblogic.domainUID=governancedomain,weblogic.serverName=AdminServer
   service/governancedomain-adminserver-external   NodePort    10.96.33.206     <none>        7101:30711/TCP        17h    weblogic.createdByOperator=true,weblogic.domainUID=governancedomain,weblogic.serverName=AdminServer
   service/governancedomain-cluster-oim-cluster    ClusterIP   10.103.195.154   <none>        14002/TCP,14000/TCP   16h    weblogic.clusterName=oim_cluster,weblogic.createdByOperator=true,weblogic.domainUID=governancedomain
   service/governancedomain-cluster-soa-cluster    ClusterIP   10.106.89.77     <none>        8001/TCP              16h    weblogic.clusterName=soa_cluster,weblogic.createdByOperator=true,weblogic.domainUID=governancedomain
   service/governancedomain-soa-server1            ClusterIP   None             <none>        8001/TCP              16h    weblogic.createdByOperator=true,weblogic.domainUID=governancedomain,weblogic.serverName=soa_server1
   
   NAME                                                            COMPLETIONS   DURATION   AGE   CONTAINERS                           IMAGES                  SELECTOR
   job.batch/governancedomain-create-fmw-infra-sample-domain-job   1/1           9m9s       23h   create-fmw-infra-sample-domain-job   oracle/oig:12.2.1.4.0   controller-uid=a724d3ea-cbf0-43e1-9743-61a4f753c8b7

Note:

It will take several minutes before all the services listed above appear. A pod with a STATUS of 0/1 indicates that the pod has already started but the SOA server associated with the pod is just starting. While the pods are starting, you can check the startup status in the pod logs by using the following commands:

kubectl logs governancedomain-adminserver -n oigns

kubectl logs governancedomain-soa-server1 -n oigns

Only after the Administration Server and SOA servers have started successfully, you start the remaining servers using the command:

kubectl patch cluster -n <OIGNS> <OIG_DOMAIN_NAME>-oim-cluster --type=merge -p '{"spec":{"replicas":1}}"'

For example:

kubectl patch cluster -n signs governancedomain-oim-cluster --type=merge -p '{"spec":{"replicas":1}}"'

Verify that the domain has been initialized, using the following command:

kubectl get all,domains -n oigns

The output appears as follows:

NAME                                                            READY   STATUS      RESTARTS   AGE   
pod/governancedomain-adminserver                                1/1     Running     0          13h   
pod/governancedomain-create-fmw-infra-sample-domain-job-ks2rj   0/1     Completed   0          14h   
pod/governancedomain-oim-server1                                1/1     Running     0          12h
pod/governancedomain-oim-server2                                1/1     Running     0          12h   
pod/governancedomain-soa-server1                                1/1     Running     0          12h
pod/governancedomain-soa-server2                                1/1     Running     0          12h   
pod/helper                                                      1/1     Running     0          14h   

NAME                                            TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)               AGE    
service/governancedomain-adminserver            ClusterIP   None              <none>        7101/TCP              13h    
service/governancedomain-cluster-oim-cluster    ClusterIP   10.98.52.6        <none>        14002/TCP,14000/TCP   14h    
service/governancedomain-cluster-soa-cluster    ClusterIP   10.104.237.225    <none>        8001/TCP              14h    
service/governancedomain-oim-server1            ClusterIP   None              <none>        14002/TCP,14000/TCP   12h    
service/governancedomain-oim-server2            ClusterIP   None              <none>        14002/TCP,14000/TCP   12h
service/governancedomain-oim-server3            ClusterIP   10.107.107.116    <none>        14002/TCP,14000/TCP   12h
service/governancedomain-oim-server4            ClusterIP   10.98.134.71      <none>        14002/TCP,14000/TCP   12h
service/governancedomain-oim-server5            ClusterIP   10.103.64.15      <none>        14002/TCP,14000/TCP   12h    
service/governancedomain-soa-server1            ClusterIP   None              <none>        8001/TCP              12h
service/governancedomain-soa-server2            ClusterIP   None              <none>        8001/TCP              12h
service/governancedomain-soa-server3            ClusterIP   10.111.204.234    <none>        8001/TCP              12h
service/governancedomain-soa-server4            ClusterIP   10.107.90.229     <none>        8001/TCP              12h
service/governancedomain-soa-server5            ClusterIP   10.97.72.84       <none>        8001/TCP              12h

NAME                                                              COMPLETIONS   DURATION   AGE   
job.batch/governancedomain-create-fmw-infra-sample-domain-job     1/1           5m41s      14h   

NAME                                            AGE 
domain.weblogic.oracle/governancedomain         14h

NAME                                                        AGE
cluster.weblogic.oracle/governancedomain-oim-cluster        14h
cluster.weblogic.oracle/governancedomain-soa-cluster        14h

Note:

It will take several minutes before all the services listed above show up. When a pod has a STATUS of 0/1, the pod is started but the OIM server associated with it is just starting. While the pods are starting, you can check the startup status in the pod logs, by running the following commands:

kubectl logs governancedomain-oim-server1 -n oigns

Creating the Kubernetes Services

By default, the OIG domain gets created with all the components (except the Administration Server) configured as ClusterIP services. This means that the Oracle Identity Governance components are visible only within the Kubernetes cluster.

In an enterprise deployment, all interactions with the WebLogic components take place through the Oracle HTTP Server which sits outside of the Kubernetes cluster. You expose the WebLogic components to the outside world by creating Kubernetes additional services. You can use either NodePort Services or an Ingress controller.

• Creating NodePort Services
  
• Creating a SOA NodePort Service
  
• Validating the Services
  
• Creating the Ingress Services
  

Creating NodePort Services

To create an OIM NodePort Service:

1. Create a text file called <WORKDIR>/oim_nodeport.yaml with the following content:

   kind: Service
   apiVersion: v1
   metadata:
     name: <OIG_DOMAIN_NAME>-oim-nodeport
     namespace: <OIGNS>
   spec:
     type: NodePort
     selector:
       weblogic.clusterName: oim_cluster
     ports:
       - targetPort: 14000
         port: 14000
         nodePort: <OIG_OIM_PORT_K8>
         protocol: TCP
     sessionAffinity: ClientIP
   

2. Create the service using the following command:

   kubectl create -f /workdir/OIG/oim_nodeport.yaml

   The output appears as follows:

   service/governancedomain-oim-nodeport created

Creating a SOA NodePort Service

To create a SOA NodePort Service:

1. Create a text file called <WORKDIR>/soa_nodeport.yaml with the following content:

   kind: Service
   apiVersion: v1
   metadata:
     name: <OIG_DOMAIN_NAME>-soa-nodeport
     namespace: <OIG>
   spec:
     type: NodePort
     selector:
       weblogic.clusterName: soa_cluster
     ports:
       - targetPort: 8001
         port: 8001
         nodePort: <OIG_SOA_PORT_K8>
         protocol: TCP

2. Create the service using the following command:

   kubectl create -f /workdir/OIG/soa_nodeport.yaml

   The output appears as follows:

   service/governancedomain-soa-nodeport created

Validating the Services

To validate that the services have been created correctly, use the following command:

kubectl -n oigns get all -o wide

Creating the Ingress Services

To create Ingress services, you must first create an Ingress controller. For more information about the installation procedure, see Installing and Configuring Ingress Controller.

The Ingress service is created inside the product namespace. It tells the Ingress controller how to direct requests inside the namespace.

Note:

The example below creates three Ingress services, one for each of the OIG virtual hosts.

• igdadmin.example.com
• prov.example.com
• igdinternal.example.com

To create an Ingress service:

1. Copy the values.yaml file from the <WORKDIR>/samples/charts/ingress-per-domain to your working directory and rename the file to override_ingress.yaml.
2. Edit the file <WORKDIR>/override_ingress.yaml and set the values as follows:

   set domainUID to <OIG_DOMAIN_NAME>
   set adminServerPort to <OIG_ADMIN_PORT>
   set hostName.enabled to true
   set admin to <OIG_ADMIN_LBR_HOST>
   set runtime to <OIG_LBR_HOST>
   set internal to <OIG_LBR_INT_HOST>

   For example:

   # Load balancer type. Supported values are: NGINX
   type: NGINX
   
   # SSL configuration Type. Supported Values are : NONSSL,SSL
   sslType: NONSSL
   
   # domainType. Supported values are: oim
   domainType: oim
   
   #WLS domain as backend to the load balancer
   wlsDomain:
     domainUID: governancedomain
     adminServerName: AdminServer
     adminServerPort: 7101
     adminServerSSLPort:
     soaClusterName: soa_cluster
     soaManagedServerPort: 8001
     soaManagedServerSSLPort:
     oimClusterName: oim_cluster
     oimManagedServerPort: 14000
     oimManagedServerSSLPort:
   
   # Host specific values
   hostName:
     enabled: true
     admin: igdadmin.example.com
     runtime: prov.example.com
     internal: internal.example.com
   
   # Ngnix specific values
   nginx:
     nginxTimeOut: 180

3. Create the Ingress services by running the following commands:

   cd <WORKDIR>/samples

   helm install oig-nginx charts/ingress-per-domain --namespace <OIGNS> --values <WORKDIR>/override_ingress.yaml

4. Validate that the Ingress service has been created correctly by using the following command:

   kubectl get ingress -n oigns

Tuning JMS Queues

To ensure maximum throughput, tune the JMS queues.

To tune the OIM JMS queue:

1. Log in to the WebLogic Server Console at: http://k8worker1.example.com:30711/console.
2. Click Lock & Edit.
3. In Domain Structure, expand Services and Messaging, and then click JMS Servers.
4. Click on OIMJMSServer. Change the values for the following:
   • Message Buffer Size to 1073741824 (1GB).
   • Under Thresholds and Quota, change Messages Maximum to 1000000.
5. Click Save.
6. Click Activate Changes.

Installing the Connector Bundle

After you create the domain, you need to copy any connectors you require, to the Kubernetes container. These connectors must be stored on the persistent volume.

To install the connector bundle, this example uses the Oracle Internet Directory connector bundle, which is used to integrate Oracle Identity Governance with Oracle Unified Directory.

1. If not already done, download the connector bundle to the <WORKDIR>.
   https://www.oracle.com/middleware/technologies/identity-management/oim-connectors-downloads.html
2. Create a sub-directory and unzip the connector into it. For example:

   mkdir /workdir/OIG/connectors
   cd /workdir/OIG/connectors
   unzip /workdir/OIG/oid-12.2.1.3.zip

3. Copy the connector to the Kubernetes container locating it in persistent storage.

   kubectl exec -ti oimserver-1 -n <OIGNS> -- mkdir -p /u01/oracle/user_projects/domains/ConnectorDefaultDirectory

   kubectl cp <CONNECTOR_DIR>/OID-12.2.1.3.0 <OIGNS>/<domain-uid>-adminserver:/u01/oracle/user_projects/domains/ConnectorDefaultDirectory

   For example:

   kubectl exec -ti governancedomain-oim-server1 -n oigns -- mkdir -p /u01/oracle/user_projects/domains/ConnectorDefaultDirectory

   kubectl cp /workdir/OIG/connectors/OID-12.2.1.3.0 oigns/governancedomain-adminserver:/u01/oracle/user_projects/domains/ConnectorDefaultDirectory

Performing the Post-Configuration Tasks for Oracle Identity Management Domain

The post-configuration tasks for the OIG domain include creating the server overrides file and updating the data sources.

• Limiting Pods to Specific Worker Nodes
  
• Creating the Server Overrides File
  

Limiting Pods to Specific Worker Nodes

If you want to ensure that the OIG servers start only on a specific set of worker servers, complete the following steps:

• Labeling the Kubernetes Worker Nodes
  
• Restricting Processes to Labels
  

Labeling the Kubernetes Worker Nodes

Label the worker nodes you want to include in scheduling. This can be as granular as you need. For example, if you want to schedule the OIG processes to run on a set of nodes, then label that set with a label such as oigservers. If you want to dictate that the Administration Server runs on a specific set of worker nodes and the oim_server on a different set, then create two labels, oigadmin and oimservers.

Add a label to a Kubernetes node using the following command:

kubectl label node worker1 name=oimservers

Restricting Processes to Labels

To ensure that the OIM pods run on only worker nodes with the appropriate label, edit the domain.yaml file located in the following path:

<WORKDIR>/samples/create-oim-domain/domain-home-on-pv/output/weblogic-domains/<OIG_DOMAIN_NAME>/

For example:

/workdir/OIG/samples/create-oim-domain/domain-home-on-pv/output/weblogic-domains/accessdomain/

Alter the Managed Servers section for all the Managed Servers configured in the cluster and ensure that only the labeled worked nodes are used for scheduling.

For oim_server1 and oim_server2, the entries will look similar to:

   managedServers:
   - serverName: oim_server1
     serverPod:
       nodeSelector:
         name: oimservers
   - serverName: oim_server2
     serverPod:
       nodeSelector:
         names: oimservers

Creating the Server Overrides File

The serverOverrides file is used to set specific Java values when the containers start. The parameters are appended to the configuration in the setDomainEnv.sh file but unlike the setDomainEnv.shfile, the serverOverrides file is not overwritten during the upgrade.

• Disabling the Derby Database
  
• Enabling the Managed Servers to Use IPv4 Networking
  
• Setting the Memory Parameters in IAMGovernanceDomain
  
• Copying Server Overrides to the Kubernetes Containers
  

Disabling the Derby Database

Disable the embedded Derby database, which is a file-based database, packaged with Oracle WebLogic Server. The Derby database is used primarily for development environments. Therefore, you must disable it when you are configuring a production-ready enterprise deployment environment. Otherwise, the Derby database process starts automatically when you start the Managed servers.

To disable the Derby database:

1. Create a file called /workdir/OIG/setUserOverrides.sh with the following content:

   DERBY_FLAG=false

2. Save and close the file.

Enabling the Managed Servers to Use IPv4 Networking

If the Managed Server is configured to use IPv6 networking, then you may encounter issues when you start the Managed Server. Therefore, you must enable the Managed Servers to use IPv4 networking.

1. Edit the setUserOverrides.sh file and add the following line:

   JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.net.preferIPv4Stack=true"

   Note:

   If the file does not exist, create it.
2. Save and close the file.

Setting the Memory Parameters in IAMGovernanceDomain

The initial startup parameter in the IAMGovernanceDomain, which defines the memory usage, is insufficient. You must increase the value of this parameter.

1. Change the following memory allocation in the setUserOverrides.sh file, by updating the Java maximum memory allocation pool (Xmx) to 8192m and initial memory allocation pool (Xms) to 4096m. For example, add the following line:

   MEM_ARGS="-Xms4096m -Xmx8192m"

2. Save and close the file.

Copying Server Overrides to the Kubernetes Containers

In a Kubernetes environment, there is no editior inside the container. To work around this issue, create the file on the master node and copy it to the Kubernetes container using the following commands:

chmod 755 /workdir/OIG/setUserOverrides.sh

kubectl cp /workdir/OIG/setUserOverrides.sh oigns/governancedomain-adminserver:/u01/oracle/user_projects/domains/governancedomain/bin/setUserOverrides.sh

Where oigns is the OIG namespace and governancedomain is the DOMAIN_NAME/UID.

Validating Identity Governance

Perform a few tests to validate your installation.

• Validating OIM by Logging in to the Identity Console
  
• Validating the SOA Application
  
• Validating the Fusion Middleware Control Application
  

Validating OIM by Logging in to the Identity Console

You can validate the Oracle Identity Manager Server instance by bringing up the Oracle Identity Manager Console in a web browser.

1. Launch the Oracle Identity Manager Console in a web browser at:

   http://k8worker1.example.com:30140/identity/ 

   http://k8worker1.example.com:30140/sysadmin/

2. Log in using the xelsysadm user name and password.

Validating the SOA Application

Validate SOA by logging into soa-infra:

http://k8worker1.example.com:30801/soa-infra

Log in using the weblogic user name.

Validating the Fusion Middleware Control Application

You can access the Fusion Middleware Control application after you execute the bootstrap process and validate it.

Note:

Provide the challenge questions if you are prompted to enter them.

To navigate to the Fusion Middleware Control application, enter the following URL, and log in with the Oracle WebLogic Server administrator credentials:

http://k8worker1.example.com:30711/em

Analyzing the Bootstrap Report

When you start the Oracle Identity Governance server, the bootstrap report is generated at $DOMAIN_HOME/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.html.

The bootstrap report BootStrapReportPreStart_XXXX.html is an HTML file that contains information about the topology that you have deployed, the system level details, the connection details like the URLs to be used, the connectivity check, and the task execution details. You can use this report to check if the system is up, and also to troubleshoot the issues, post-configuration.

Every time you start the Oracle Identity Governance server, the bootstrap report is updated.

Sections in the Bootstrap Report

• Topology Details

  This section contains information about your deployment. It shows whether you have configured a cluster setup, SSL enabled, or upgraded an Oracle Identity Manager environment from 11g to 12c.

• System Level Details

  This section contains information about the JDK version, Database version, JAVA_HOME, DOMAIN_HOME, OIM_HOME, and MIDDLEWARE_HOME.

• Connection Details

  This section contains information about the connect details like the Administration URL, OIM Front End URL, SOA URL, and RMI URL.

  This also shows whether the Administration Server, Database, and SOA server is up or not.

• Execution Details

  This section lists the various tasks and their statuses.

To obtain the bootstrap report, you can do one of the following:

• Connect to the Oracle Identity Governance Administration Server by using the command:

  kubectl exec -n <OIGNS> -ti <OIG_DOMAIN_NAME>-adminserver –- /bin/bash

  cat /u01/oracle/user_projects/domains/<OIG_DOMAIN_NAME>/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.html

  For example:

  kubectl exec -n oigns -ti governancedomain-adminserver –- /bin/bash

  cat /u01/oracle/user_projects/domains/governancedomain/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.html

• If you have mounted the IAMPVS on your configuration host, you can simply point a browser at:

  /nfs_volumes/oigpv/domains/governancedomain/servers/oim_server1/logs/BootStrapReportPreStart_XXXX.html

Configuring the Web Tier for the Domain

If you have not already done so, configure the web server instances on the web tier so that the instances route requests for both public and internal URLs to the proper clusters in the extended domain.

For more information about configuring Oracle HTTP Server, see Installing and Configuring Oracle HTTP Server.

For additional steps in preparation for possible scale-out scenarios, see Updating Cross Component Wiring Information.

Integrating Oracle Identity Governance with Oracle SOA Suite

You can integrate Oracle Identity Governance with Oracle SOA suite using the load balancer entry points to maintain high availability.

• Updating the OIM Integration URLs
  

Updating the OIM Integration URLs

This section describes how to update the SOA integration URLs to use the load balanced URLs. If you want to integrate Oracle Identity Governance with Oracle SOA suite, use the Enterprise Manager Console.

You need to perform certain tasks in order to configure the newly created domain with the Oracle Identity Governance. These tasks are post-domain creation tasks.

To integrate Oracle Identity Governance with Oracle SOA Suite, do the following:

1. Log in to Oracle Fusion Middleware Control using the following URL:

   http://igdadmin.example.com/em

   or

   http://k8worker1.example.com:30711/em

   The Administration Server host and port number were in the URL on the End of Configuration screen (Writing Down Your Domain Home and Administration Server URL). The default Administration Server port number is 7101.

   The login credentials were provided on the Administrator Account screen (Configuring the Administrator Account).

2. Click weblogic_domain, and then click System Mbean Browser.
3. In the search box, enter OIMSOAIntegrationMBean, and click Search. The mbean is displayed.

   Note:

   If Oracle Identity Governance still starting (coming up) or is just started (RUNNING MODE), the Enterprise Manager does not show any Mbeans defined by OIM. Wait for two minutes for the server to start, and then try searching for the Mbean in System Mbean Browser of the Enterprise Manager.

4. Go to the Operations tab of mbean, and select integrateWithSOAServer.
5. Enter the following information:
   • Weblogic Administrator User Name: Enter the name of the WebLogic administrator. For example: weblogic.
   • Weblogic Administrator Password: Enter the password for the above account.
   • OIM Front end URL: Set this URL to the load balancer virtual host used for internal call backs. For example:

     http://igdinternal.example.com:7777/

   • OIM External Front End URL: Set this URL to the main load balancer virtual host used for Oracle Identity Governance. For example:

     https://prov.example.com:443/

   • SOA SOAP URL: Set this URL to the SOA Kubernetes Service used for internal call backs. For example:

     http://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001

   • SOA RMI URL: Set this URL to the SOA Kubernetes Service used for internal call backs. For example:

     t3://<OIG_DOMAIN_NAME>-cluster-soa-cluster.<OIG NAMESPACE>.svc.cluster.local:8001

     Example of the above URL:

     t3://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001

   • UMS Webservice URL: Set this URL to the SOA Kubernetes Service used for internal call backs. For example:

     http://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001/ucs/messaging/webservice

6. Click Invoke.

Managing the Notification Service

An event is an operation that occurs in Oracle Identity Manager, such as user creation, request initiation, or any custom event created by the user. These events are generated as part of the business operations or through the generation of errors. Event definition is the metadata that describes the event.

To define the metadata for events, you must identify all event types supported by a functional component. For example, as a part of the scheduler component, metadata is defined for a scheduled job execution failure and shutting down of the scheduler. Every time a job fails or the scheduler shuts down, the associated events get triggered, and the notifications associated with the event get sent.

The data available in the event is used to create the content of the notification. The different parameters defined for an event help the system to select the appropriate notification template. The various parameters defined for an event help the system decide which event variables should be made available at template design time.

A notification template is used to send notifications. These templates contain variables that refer to available data to provide more context to the notifications. The notification is sent through a notification provider. Examples of such channels are e-mail, Instant Messaging (IM), Short Message Service (SMS), and voice. To use these notification providers, Oracle Identity Manager uses Oracle User Messaging Service (UMS).

At the back end, the notification engine is responsible for generating the notification and utilizing the notification provider to send the notification.

• Using Oracle Unified Messaging for Notification
  
• Updating the CSF Key
  

Using Oracle Unified Messaging for Notification

Using Oracle Unified Messaging (UMS) for notification involves configuring the UMS email notification provider properties and adding the CSF key.

To configure SMTP Email Notification Provider properties by using the UMSEmailNotificationProviderMBean:

1. Log in to the Oracle Fusion Middleware Control using the following URL:

   http://igdadmin.example.com/em

   or

   http://k8worker1.example.com:30711/em

   The Administration Server host and port number were in the URL on the End of Configuration screen (Writing Down Your Domain Home and Administration Server URL). The default Administration Server port number is 7001.

   The login credentials were provided on the Administrator Account screen (Configuring the Administrator Account).

2. Click weblogic_domain, and then click System Mbean Browser.
3. In the search box, enter UMSEmailNotificationProviderMBean, and click Search. The mbean is displayed.

   Note:

   If Oracle Identity Governance still starting (coming up) or is just started (RUNNING MODE), the Enterprise Manager does not show any Mbeans defined by OIM. Wait for two minutes for the server to start, and then try searching for the Mbean in System Mbean Browser of the Enterprise Manager.
4.  Ensure that the correct information is entered for your email server in particular:

   Table 19-4 SMTP Email Notification Provider Properties

   Attribute	Value
   Enabled	Set to true.
   MailServerName	Set to the host name of your email server.
   WSUrl	http://<OIG_DOMAIN_NAME>-cluster-soa-cluster.<OIGNS>.svc.cluster.local:8001/ucs/messaging/webservice

5. Click Apply to save the changes.

Updating the CSF Key

To update the CSF key:

1. Log in to Oracle Enterprise Manager.
2. Click WebLogic Domain, click Security, and then Credentials.
3. Expand oracle.wsm.security and click Create Key.
4. Enter the following information.

   Table 19-5 CSF Key Properties

   Attribute	Value
   Key name	Enter the value of the credential Key, this must be the same value as defined in Using Oracle Unified Messaging for Notification for example; mailUser.
   Username	Enter the name of the user you use to authenticate with your email server.
   Password/Confirm Password	Enter the password of the user you use to authenticate with your email server.
   Description	Provide a description of the key being created. For example, Mail Server Credentials

5. Click OK.

Configuring the Messaging Drivers

Each messaging driver needs to be configured. You have to configure this service if you want to enable OAM's forgotten password functionality.

• Configuring the Email Driver
  

Configuring the Email Driver

To configure the driver to send and emails then you need to perform the following steps:

1.  Log in to the Oracle Fusion Middleware Control.
2. Click the Target Navigation icon next to the Domain name.
3. Click usermessagingserver (soa_server) under User Messaging Service. A list of all the drivers will be shown.
4. Click Configure Driver next to the User Messaging Email Driver.
5.  If a configuration does not exist then click Create. If the configuration exists, click Edit.
6. Update the attributes with the required details.

   Table 19-6 Configuring the Email Driver Attributes

   Attributes	Values
   Name	MyemailServer
   Sender Address	Enter the From email address for the emails you wish to send in the format: EMAIL:[e-mail]
   Capability	Choose whether you are going to send or receive emails. Complete the following Email Properties using the values specific to your organisation. Contact your email administrator for details, the details below are for Sending only. Refer to the documentation for receiving email details. Outdoing Mail server. Outgoing Mail server port Outgoing email Server Security Outgoing User name and password, if your email server requires it.

7. Click Test to validate the information.
8. Click OK to save the information.

Increasing Database Connection Pool Size

The default database connection pool size needs to be increased when Oracle Identity Governance is used in conjunction with a connector that allows interactions with an LDAP directory.

To do this, complete the following steps:

1. Log in to the WebLogic Server Administration Console in IAMGovernanceDomain.
2. Click Lock & Edit.
3. Click Services and then click Data Sources.
4. Click the data source mds-oim.
5. Go to the Connection Pool tab.
6. Modify the following properties with the values specified:
   • Initial Capacity: 50
   • Maximum Capacity: 150
   • Minimum Capacity: 50
   • Inactive Connection Timeout value to 30 from any other value

   Note:

   Inactive Connection Timeout is in the Advanced section.
7. Click Save.
8. Click Activate Changes.
9. You will receive a message All changes have been activated. No restarts are necessary.

Integrating Oracle Identity Governance with LDAP

Before you integrate OIG with LDAP, you should configure the connector for LDAP and add the required object classes if any are missing.

Note:

The following sections require that you edit the property files and use those property files with the ./OIGOAMIntegration.sh script.

In a Kubernetes container there is no editor. So, copy the file to the local machine, edit it, and then copy it back. The syntax of the command is:

kubectl cp <OIGNS>/<OIG_DOMAIN_NAME>-adminserver:<SOURCE FILENAME> <DESTINATION_FILENAME>

Edit the file, and then copy it back. The syntax to copy a file back to Kubernetes is:

kubectl cp /workdir/OIG/configureLDAPConnector.config oigns/governancedomain-adminserver:/u01/oracle/idm/server/ssointg/config/configureLDAPConnector.config

• Configuring the Oracle Connector for LDAP
  
• Adding Missing Object Classes
  

Configuring the Oracle Connector for LDAP

The Oracle Connector for LDAP enables you to store users and passwords in a certified LDAP directory. Configure the connector before using it. Perform the following steps to configure the connector:

1. Change directory to /u01/oracle/idm/server/ssointg/config.

2. Edit the configureLDAPConnector.config file.

   Following is the template file:

   ## [configureLDAPConnector]
   IDSTORE_DIRECTORYTYPE=<LDAP_TYPE>
   OIM_HOST=<OIG_DOMAIN_NAME>-cluster-oim-cluster.<OIGNS>.svc.cluster.local
   OIM_PORT=14000
   OIM_SERVER_SYSADMIN_USER=<LDAP_XELSYSADM_USER>
   OIM_WLSHOST=<OIG_DOMAIN_NAME>-adminserver-external.<OIGNS>.svc.cluster.local
   OIM_WLSPORT=<OIG_ADMIN_PORT>
   OIM_WLSADMIN=<OIG_WEBLOGIC_USER>
   OIM_WLSADMIN_PWD=<OIG_WEBLOGIC_PWD>
   IDSTORE_HOST=<LDAP_HOST>
   IDSTORE_PORT=<LDAP_PORT>
   IDSTORE_BINDDN=<LDAP_ADMIN_USER>
   IDSTORE_OIMADMINUSERDN=cn=<LDAP_OIGLDAP_USER>,cn=<LDAP_SYSTEMIDS>,<LDAP_SEARCHBASE>
   IDSTORE_SEARCHBASE=<LDAP_SEARCHBASE>
   IDSTORE_USERSEARCHBASE=<LDAP_USER_SEARCHBASE>
   IDSTORE_GROUPSEARCHBASE=<LDAP_GROUP_SEARCHBASE>
   IDSTORE_USERSEARCHBASE_DESCRIPTION=Default user container
   IDSTORE_GROUPSEARCHBASE_DESCRIPTION=Default group container
   IDSTORE_EMAIL_DOMAIN=<OIG_EMAIL_DOMAIN>
   ## For ActiveDirectory use the values of "yes" or "no". i.e. IS_LDAP_SECURE=yes/no
   IS_LDAP_SECURE=false
   SSO_TARGET_APPINSTANCE_NAME=SSOTarget
   ## Path to expanded connector bundle: e.g. for OID and OUD
   CONNECTOR_MEDIA_PATH=/u01/oracle/user_projects/domains/ConnectorDefaultDirectory/OID-12.2.1.3.0
   WLS_OIM_SYSADMIN_USER_PWD=<LDAP_USER_PWD>
   IDSTORE_BINDDN_PWD=<LDAP_ADMIN_PWD>
   IDSTORE_OIMADMINUSER_PWD=<LDAP_USER_PWD>

   This is a sample of the file, as an example:

   ##-----------------------------------------------------------##
   ## [configureLDAPConnector]
   IDSTORE_DIRECTORYTYPE=OUD
   OIM_HOST=governancedomain-cluster-oim-cluster.oigns.svc.cluster.local
   OIM_PORT=14000
   OIM_SERVER_SYSADMIN_USER=xelsysadm
   OIM_WLSHOST=governancedomain-adminserver-external.oigns.svc.cluster.local
   OIM_WLSPORT=7101
   OIM_WLSADMIN=weblogic
   OIM_WLSADMIN_PWD=<Password1>
   IDSTORE_HOST=edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local
   IDSTORE_PORT=1389
   IDSTORE_BINDDN=cn=oudadmin
   IDSTORE_OIMADMINUSERDN=cn=oimLDAP,cn=systemids,dc=example,dc=com
   IDSTORE_SEARCHBASE=dc=example,dc=com
   IDSTORE_USERSEARCHBASE=cn=Users,dc=example,dc=com
   IDSTORE_GROUPSEARCHBASE=cn=Groups,dc=example,dc=com
   IDSTORE_USERSEARCHBASE_DESCRIPTION=Default user container
   IDSTORE_GROUPSEARCHBASE_DESCRIPTION=Default group container
   IDSTORE_EMAIL_DOMAIN=example.com
   ## For ActiveDirectory use the values of "yes" or "no". i.e. IS_LDAP_SECURE=yes/no
   IS_LDAP_SECURE=false
   SSO_TARGET_APPINSTANCE_NAME=SSOTarget
   ## Path to expanded connector bundle: e.g. for OID and OUD
   CONNECTOR_MEDIA_PATH=/u01/oracle/user_projects/ConnectorDefaultDirectory/OID-12.2.1.3.0
   WLS_OIM_SYSADMIN_USER_PWD=<PASSWORD>
   IDSTORE_BINDDN_PWD=<PASSWORD>
   IDSTORE_OIMADMINUSER_PWD=<PASSWORD>

   Note:

   You can also specify the passwords directly in the file, if required. If you do not specify the passwords, you will be prompted for them at runtime.

   Parameters are:

   • OIM_WLSADMIN_PWD
   • IDSTORE_BINDDN_PWD
   • WLS_OIM_SYSADMIN_USER_PWD
   • ADMIN_USER_PWD
   • IDSTORE_OIMADMINUSER_PWD

   Save the file.

   Note:

   You should use the same values as you specified for these parameters in Creating Configuration Files.

3. Execute the script OIGOAMIntegration for configuring the connector.

   For example:

   kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   chmod 750 _OIGOAMIntegration.sh OIGOAMIntegration.sh

   ./OIGOAMIntegration.sh -configureLDAPConnector

Adding Missing Object Classes

If any users existed in LDAP prior to enabling the Oracle Identity Manager, then these new users may be missing the object classes used to control OIM/OAM integration. To add these missing object classes to these users, run the following commands:

Note:

To successfully execute this process, the ldapsearch binary is required to be in your user's PATH and the screen package is required to be installed on your host.

1. Change directory to /u01/oracle/idm/server/ssointg/config.

2. Edit the file addMissingObjectClasses.config updating the properties as shown below:

   Following is the template file:

   IDSTORE_DIRECTORYTYPE=<LDAP_TYPE>
   IDSTORE_HOST=<LDAP_HOST>
   IDSTORE_PORT=<LDAP_PORT>
   IDSTORE_BINDDN=<LDAP_ADMIN_USER>
   IDSTORE_USERSEARCHBASE=<LDAP_USER_SEARCHBASE>

   This is a sample of the file, as an example:

   IDSTORE_DIRECTORYTYPE=OUD
   IDSTORE_HOST=edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local
   IDSTORE_PORT=1389
   IDSTORE_BINDDN=oudadmin
   IDSTORE_USERSEARCHBASE=cn=Users,dc=example,dc=com

   Save the file.

3. Execute the script OIGOAMIntegration.

   For example:

   kubectl exec -n oigns -ti governancedomain-adminserver --/bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   ./OIGOAMIntegration.sh -addMissingObjectClasses

   You will be prompted to enter the password of the LDAP directory administrator account, if you have not provided them as inputs to the parameter file.

Integrating Oracle Identity Governance and Oracle Access Manager

You have to complete several tasks to integrate Oracle Identity Governance and Oracle Access Manager. These tasks include creating the WLS authentication providers, deleting OIMSignatureAuthenticator and recreating OUDAuthenticator, adding the administration role to the new administration group, and so on.

• Creating WLS Authentication Providers
  
• Deleting OIMSignatureAuthenticator
  
• Recreating OUDAuthenticator
  
• Adding the Administration Role to the New Administration Group
  
• Configuring SSO Integration in the Governance Domain
  
• Enabling OAM Notifications
  
• Updating the Value of MatchLDAPAttribute in oam-config.xml
  
• Updating the TapEndpoint URL
  

Creating WLS Authentication Providers

You must configure the WLS authentication providers to set SSO logout and security providers in the OIG domain. This enables both the SSO login and OIM client-based login to work appropriately.

1. Change directory to /u01/oracle/idm/server/ssointg/config.
2. Edit the configureWLSAuthnProviders.config file to set the following properties:

   This is the template file:

   OIM_WLSHOST: <OIG_DOMAIN_NAME>-adminserver.<OIGNS>.svc.cluster.local
   OIM_WLSPORT=<OIG_ADMIN_PORT>
   OIM_WLSADMIN=<OIG_WEBLOGIC_USER>
   OIM_WLSADMIN_PWD=<OIG_WEBLOGIC_PWD>
   OIM_SERVER_NAME=oim_server1
   ## DIRTYPE values can be [OID | OUD | AD]
   IDSTORE_DIRECTORYTYPE=<LDAP_TYPE>
   IDSTORE_HOST=<LDAP_HOST>
   IDSTORE_PORT=<LDAP_PORT>
   IDSTORE_BINDDN=<LDAP_ADMIN_USER>
   IDSTORE_BINDDN_PWD=<LDAP_ADMIN_PWD>
   IDSTORE_USERSEARCHBASE=<LDAP_USER_SEARCHBASE>
   IDSTORE_GROUPSEARCHBASE=<LDAP_GROUP_SEARCHBASE>

   This is a sample file:

   OIM_WLSHOST: governancedomain-adminserver.oigns.svc.cluster.local
   OIM_WLSPORT: 7101
   OIM_WLSADMIN=weblogic
   OIM_WLSADMIN_PWD=<password>
   OIM_SERVER_NAME=oim_server1
   IDSTORE_DIRECTORYTYPE=OUD
   IDSTORE_HOST=edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local
   IDSTORE_PORT=1389
   IDSTORE_BINDDN=cn=oudadmin
   IDSTORE_BINDDN_PWD=<password>
   IDSTORE_USERSEARCHBASE=cn=Users,dc=example,dc=com
   IDSTORE_GROUPSEARCHBASE=cn=Groups,dc=example,dc=com

   Save the file.

3. Execute the OIGOAMIntegration script for configuring the WebLogic security providers.

   kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   ./OIGOAMIntegration.sh -configureWLSAuthnProviders

Deleting OIMSignatureAuthenticator

The createWLSAuthenticator script creates a new security provider called OIMSignatureAuthenticator. This security provider is not required in Oracle Identity Manager 12c.

To delete the security provider:

1. Log in to the WebLogic Server Administration Console, if not already logged in.
2. Click Lock & Edit.
3. Click Security Realms on the left navigation pane.
4. Click the myrealm default realm entry.
5. Click the Providers tab.
6. Select the security provider OIMSignatureAuthenticator.
7. Click Delete.
8. Click Yes to confirm the deletion.
9. Click Activate Changes to propagate the changes.

Recreating OUDAuthenticator

If your target directory is OUD, then you must delete and recreate the OUDAuthenticator security provider.

To delete the security provider:

1. Log in to the WebLogic Server Administration Console, if not already logged in.
2. Click Lock & Edit.
3. Click Security Realms on the left navigation pane.
4. Click the myrealm default realm entry.
5. Click the Providers tab.
6. Select the security provider OUDAuthenticator.
7. Click Delete.
8. Click Yes to confirm the deletion.
9. Click Activate Changes to propagate the changes.

To recreate the security provider:

1. Log in to the WebLogic Server Administration Console using the URL.

   http://k8worker1.example.com:30711/console

2. Click Security Realms in the left navigational bar.

3. Click the myrealm default realm entry.

4. Click the Providers tab.

5. Click Lock & Edit in the Change Center.

6. Click the New button below the Authentication Providers table.

7. Enter a name for the provider.

   Use one of the following names, based on the LDAP directory service you are planning to use as your credential store:

   OUDAuthenticator for Oracle Unified Directory

8. From the Type drop-down list, select the authenticator type OracleUnifiedDirectoryAuthenticator for Oracle Unified Directory.

9. Click OK to return to the Providers screen.

10. On the Providers screen, click the newly created authenticator in the table.

11. Select SUFFICIENT from the Control Flag drop-down menu.

    Setting the control flag to SUFFICIENT indicates that if the authenticator can successfully authenticate a user, then the authenticator should accept that authentication and should not continue to invoke any additional authenticators.

    If the authentication fails, it will fall through to the next authenticator in the chain. Make sure all subsequent authenticators also have their control flags set to SUFFICIENT; in particular, check the DefaultAuthenticator and make sure that its control flag is set to SUFFICIENT.

12. Click Save to persist the change of the control flag setting.

13. Click the Provider Specific tab and enter the details specific to your LDAP server, as shown in the following table.

    Note:

    Only the required fields are discussed in this procedure. For information about all the fields on this page, consider the following resources:

    • To display a description of each field, click Help on the Provider Specific tab.
    • For more information on setting the User Base DN, User From Name Filter, and User Attribute fields, see Configuring Users and Groups in the Oracle Internet Directory and Oracle Virtual Directory Authentication Providers in Administering Security for Oracle WebLogic Server.

    Parameter	Sample Value	Value Description
    Host	For example: edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local	The LDAP server's server ID.
    Port	For example: 1389	The LDAP server's port number.
    Principal	For example: cn=oimLDAP,cn=systemids,dc=example,dc=com	The LDAP user DN used to connect to the LDAP server.
    Credential	Enter LDAP password.	The password used to connect to the LDAP server.
    SSL Enabled	Unchecked (clear)	Specifies whether SSL protocol is used when connecting to the LDAP server.
    User Base DN	For example: cn=users,dc=example,dc=com	Specify the DN under which your users start.
    All Users Filter	(&(uid=*)(objectclass=person))	Instead of a default search criteria for All Users Filter, search all users based on the uid value. If the User Name Attribute for the user object class in the LDAP directory structure is a type other than uid, then change that type in the User From Name Filter field. For example, if the User Name Attribute type is cn, then this field should be set to: (&(cn=*)(objectclass=person)))
    User From Name Filter	For example: (&(uid=%u)(objectclass=person))	If the User Name Attribute for the user object class in the LDAP directory structure is a type other than uid, then change that type in the settings for the User From Name Filter. For example, if the User Name Attribute type is cn, then this field should be set to: (&(cn=%u)(objectclass=person))).
    User Name Attribute	For example: uid	The attribute of an LDAP user object that specifies the name of the user.
    Use Retrieved User Name as Principal	Checked	Must be turned on.
    Group Base DN	For example: cn=groups,dc=example,dc=com	Specify the DN that points to your Groups node.
    All Groups Filter	(&(cn=*)(objectclass=groupOfUniqueNames))	Specify the group filter.
    GUID Attribute	entryuuid	This value is prepopulated with entryuuid when OracleUnifiedDirectoryAuthenticator is used for OUD. Check this value if you are using Oracle Unified Directory as your authentication provider.

14. Click Save to save the changes.

15. Return to the Providers page by clicking Security Realms in the right navigation pane, clicking the default realm name (myrealm), and then Providers.

16. Click Reorder and use the resulting page to reorder the list of providers so that they match the order given below:

    List of Authentication Providers

    • OAMIDAsserter
    • OUDAuthenticator
    • DefaultAuthenticator
    • OIMAuthenticationProvider
    • Trust Service Identity Asserter
    • DefaultIdentityAsserter

17. Click OK.

18. In the Change Center, click Activate Changes.

19. You have to restart the domain for the changes to take effect. You can restart by using the following commands:

    kubectl -n <OIGNS> patch domains <OIG_DOMAIN_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "Never" }]'

    After everything is stopped, it can be restarted using the following command:

    kubectl -n <OIGNS> patch domains <OIG_DOMAIN_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IfNeeded" }]'

    For example:

    kubectl -n oigns patch domains governancedomain --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "Never" }]'
    kubectl -n oigns patch domains governancedomain --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IfNeeded" }]'

20. After the restart, review the contents of the AdminServer.log file, available in the following location:

    /u01/oracle/user_projects/domains/logs/governancedomain

    Verify that no LDAP connection errors occurred. For example, look for errors such as the following:

    The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...
    

    If you see such errors in the log file, then check the authorization provider connection details to verify they are correct and try saving and restarting the Administration Server again.

21. After you restart and verify that no LDAP connection errors are in the log file, try browsing the users and groups that exist in the LDAP provider:

    In the Administration Console, navigate to the Security Realms > myrealm > Users and Groups page. You should be able to see all users and groups that exist in the LDAP provider structure.

Adding the Administration Role to the New Administration Group

This enables all users that belong to the group to be administrators for the domain.

To assign the Administration role to the new enterprise deployment administration group:

1. Log in to the WebLogic Administration Server Console by using the administration credentials that you provided in the Configuration Wizard.

   Do not use the credentials for the administration user that you created and provided for the new authentication provider.

2. In the left pane of the Administration Console, click Security Realms.
3. Click the default security realm (myrealm).
4. Click the Roles and Policies tab.
5. Expand the Global Roles entry in the table and click Roles.
6. Click the Admin role.
7. Click Add conditions.
8. Select Group from the Predicate List drop-down menu, and then click Next.
9. Enter WLSAdministrators in the Group Argument Name field, and then click Add.

   WLSAdministrators is added to the list box of arguments.

10. Click Finish to return to the Edit Global Role page.

    The WLSAdministrators group is now listed.

11. Click Save to finish adding the Admin Role to the WLSAdministrators group.
12. Validate that the changes were made by logging in to the WebLogic Administration Server Console by using the new weblogic_iam user credentials.

    If you can log in to the Oracle WebLogic Server Administration Console and Fusion Middleware Control with the credentials of the new administration user that you just provisioned in the new authentication provider, then you have configured the provider successfully.

Configuring SSO Integration in the Governance Domain

After deploying the connector, the next step in the process is the configuration of SSO in the domain. To configure SSO, perform the following steps:

1. Change directory to /u01/oracle/idm/server/ssointg/config

2. Edit the file configureSSOIntegration.config to update the properties in the section configureSSOIntegration, as shown below:

   This is the template file:

   NAP_VERSION=4
   COOKIE_EXPIRY_INTERVAL=120
   OAM_HOST=<OAM_LOGIN_LBR_HOST>
   OAM_PORT=<OAM_LOGIN_LBR_PORT>
   ACCESS_SERVER_HOST=<OAM_DOMAIN_NAME>-oap.<OAMNS>.svc.cluster.local
   ACCESS_SERVER_PORT=<OAM_OAP_PORT>
   OAM_SERVER_VERSION=12c
   WEBGATE_TYPE=ohsWebgate12c
   ACCESS_GATE_ID=Webgate_IDM
   ACCESS_GATE_PWD=<PASSWORD>
   COOKIE_DOMAIN=example.com
   OAM_TRANSFER_MODE=open
   OIM_LOGINATTRIBUTE=uid
   SSO_ENABLED_FLAG=true
   SSO_INTEGRATION_MODE=CQR
   OAM11G_WLS_ADMIN_HOST=<OAM_DOMAIN_NAME>-adminserver.<OAMNS>.svc.cluster.local
   OAM11G_WLS_ADMIN_PORT=30012
   OAM11G_WLS_ADMIN_USER=<OAM_WEBLOGIC_USER>
   OAM11G_WLS_ADMIN_PASSWD=<OAM_WEBLOGIC_PWD>
   OAM11G_IDSTORE_NAME=OAMIDSTORE
   ## Required if OAM_TRANSFER_MODE is not OPEN
   SSO_KEYSTORE_JKS_PASSWORD=<GLOBAL_PASSPHRASE>
   SSO_GLOBAL_PASSPHRASE=<GLOBAL_PASSPHRASE>
   OIM_WLSHOST=<OIG_DOMAIN_NAME>-adminserver.<OIGNS>.svc.cluster.local
   OIM_WLSPORT=<OIG_ADMIN_PORT>
   OIM_WLSADMIN=<OIG_WEBLOGIC_USER>
   IDSTORE_OAMADMINUSER_PWD=<LDAP_USER_PWD>
   OIM_SERVER_NAME=<OIM_SERVER_NAME>
   IDSTORE_OAMADMINUSER=<LDAP_OAMADMIN_USER>

   This is a sample file:

   NAP_VERSION=4
   COOKIE_EXPIRY_INTERVAL=120 
   OAM_HOST=login.example.com
   OAM_PORT=443
   ACCESS_SERVER_HOST=accessdomain-oap.oamns.svc.cluster.local
   ACCESS_SERVER_PORT=5575
   OAM_SERVER_VERSION=12c
   WEBGATE_TYPE=ohsWebgate12c
   ACCESS_GATE_ID=Webgate_IDM
   ACCESS_GATE_PWD=<password>
   COOKIE_DOMAIN=example.com
   OAM_TRANSFER_MODE=Simple
   OIM_LOGINATTRIBUTE=uid
   SSO_ENABLED_FLAG=true
   SSO_INTEGRATION_MODE=CQR
   OAM11G_WLS_ADMIN_HOST=accessdomain-adminserver.oamns.svc.cluster.local
   OAM11G_WLS_ADMIN_PORT=30012
   OAM11G_WLS_ADMIN_USER=weblogic
   OAM11G_WLS_ADMIN_PASSWD=<PASSWORD>
   OAM11G_IDSTORE_NAME=OAMIDSTORE
   ## Required if OAM_TRANSFER_MODE is not OPEN
   SSO_KEYSTORE_JKS_PASSWORD=<GLOBAL_PASSPHRASE>
   SSO_GLOBAL_PASSPHRASE=<GLOBAL_PASSPHRASE>
   OIM_WLSHOST=governancedomain-adminserver.oigns.svc.cluster.local
   OIM_WLSPORT=7101
   OIM_WLSADMIN=weblogic
   IDSTORE_OAMADMINUSER_PWD=<password>
   OIM_SERVER_NAME=oim_server1
   IDSTORE_OAMADMINUSER=oamadmin

   Save the file when done.

   Note:

   Substitute the variables with values applicable to your deployment. See Variables Used in this Chapter. The other specified values should be used as is.

3. Execute the OIGOAMIntegration script for configuring SSO Integration.

   For example:

   kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   chmod 750 _OIGOAMIntegration.sh OIGOAMIntegration.sh

   ./OIGOAMIntegration.sh -configureSSOIntegration

4. Restart the domains IAMAccessDomain and IAMGovernanceDomain.

Enabling OAM Notifications

After deploying the connector, the next step in the process is to tell OIM how to interact with OAM for terminating a user session after a user name expires or gets terminated. To complete this activity, you need to perform the following steps:

1. Change directory to /u01/oracle/idm/server/ssointg/config.

2. Edit the enableOAMSessionDeletion.config file to update the properties in the enableOAMNotifications section.

   This is the template of the file:

   OIM_WLSHOST: <OIG_DOMAIN_NAME>-adminserver.<OIGNS>.svc.cluster.local
   OIM_WLSPORT=<OIG_ADMIN_PORT>
   OIM_WLSADMIN=<OIG_WEBLOGIC_USER>
   OIM_WLSADMIN_PWD=<OIG_WEBLOGIC_PWD>
   IDSTORE_DIRECTORYTYPE=<LDAP_TYPE>
   IDSTORE_HOST=<LDAP_HOST>
   IDSTORE_PORT=<LDAP_PORT>
   IDSTORE_BINDDN=<LDAP_ADMIN_USER>
   IDSTORE_GROUPSEARCHBASE=<LDAP_GROUP_SEARCHBASE> 
   IDSTORE_SYSTEMIDBASE: cn=<LDAP_SYSTEMIDS>,<LDAP_SEARCHBASE> 
   IDSTORE_OAMADMINUSER: <LDAP_OAMADMIN_USER> 
   IDSTORE_OAMSOFTWAREUSER: <LDAP_OAMLDAP_USER>
   IDSTORE_USERSEARCHBASE: <LDAP_USER_SEARCHBASE>
   OIM_SERVER_NAME: <OIM_SERVER_NAME>

   Here is the sample file:

   OIM_WLSHOST: governancedomain-adminserver.oigns.svc.cluster.local
   OIM_WLSPORT: 7101
   OIM_WLSADMIN: weblogic
   OIM_WLSADMIN_PWD: <password>
   IDSTORE_DIRECTORYTYPE: OUD
   IDSTORE_HOST: edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local
   IDSTORE_PORT: 1389
   IDSTORE_BINDDN: cn=oudadmin
   IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com 
   IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com 
   IDSTORE_OAMADMINUSER: oamAdmin 
   IDSTORE_OAMSOFTWAREUSER: oamLDAP
   IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com
   OIM_SERVER_NAME: oim_server1

3. Execute the script OIGOAMIntegration for enabling notifications.

   For example:

   kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   cd /u01/oracle/idm/server/ssointg/bin

   export JAVA_HOME=/u01/jdk

   export APPSERVER_TYPE=wls

   export ORACLE_HOME=/u01/oracle

   export OIM_ORACLE_HOME=/u01/oracle/idm

   export WL_HOME=$ORACLE_HOME/wlserver

   chmod 750 _OIGOAMIntegration.sh OIGOAMIntegration.sh

   ./OIGOAMIntegration.sh -enableOAMSessionDeletion

Updating the Value of MatchLDAPAttribute in oam-config.xml

To complete the Oracle Identity Governance integration with Oracle Access Manager, one of the settings in the Oracle Access Manager's oam-config.xml file needs to be changed. As of version 12c, this file is stored in the database and should not be edited directly.

The procedure below shows how to use the REST API to change one of the values in the oam-config.xml file:

Note:

Ensure that the cURL package has been added to the host by executing which curl at the command line. If the package is not installed, an administrator must install the package by executing yum install curl.

1. Find the component number of the DAPModule, by executing the following:

   curl -i -u oamadmin:<LDAP_USER_PWD> http://k8worker1.example.com:30701/iam/admin/config/api/v1/config?path=/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules

   Example output:

   HTTP/1.1 200 OK
   Date: Tue, 09 Jul 2019 20:30:33 GMT
   Content-Length: 625
   Content-Type: text/xml
   X-ORACLE-DMS-ECID: 6f9baf65-751b-4fc9-b2e1-ade5b38063ff-00000427
   X-ORACLE-DMS-RID: 0
   Set-Cookie: JSESSIONID=g3LYbkLA2bs5-9zfoMBqKTBbk0mky_8URGgzFnbNkm8n3tK63tq4!1064195705; path=/; HttpOnly

   <Configuration xmlns="http://www.w3.org/2001/XMLSchema" schemaLocation="http://higgins.eclipse.org/sts/Configuration Configuration.xsd" Path="/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules">

   <Setting Name="DAPModules" Type="htf:map">
       <Setting Name="7DASE52D" Type="htf:map">
         <Setting Name="MAPPERCLASS" Type="xsd:string">oracle.security.am.engine.authn.internal.executor.DAPAttributeMapper</Setting>
         <Setting Name="MatchLDAPAttribute" Type="xsd:string”>cn</Setting>
         <Setting Name="name" Type="xsd:string">DAP</Setting>
       </Setting>
     </Setting>

   Note:

   The component number under the line that reads: "<Setting Name="DAPModules" Type="htf:map">" This will need to be used for the configuration change. In the above example, "7DASE52D" is the component number. The value which will need to be changed is the value of MatchLDAPAttribute. In the above example, "User Name" is the current value.
2. CD to /tmp and create a configuration file MatchLDAPAttribute_input.xml with the following contents:

   <Configuration>
     <Setting Name="MatchLDAPAttribute" Type="xsd:string" Path="/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules/7DASE52D/MatchLDAPAttribute">uid</Setting>
   </Configuration>

   Note:

   The component number noted from above is inserted between DAPModules and the MatchLDAPAttribute portions of the path. The configuration file will change the value of MatchLDAPAttribute from User Name to uid.
3. Insert the change back into the OAM configuration, by executing the following:

   curl -u oamadmin:<LDAP_USER_PWD> -H 'Content-Type: text/xml' -X PUT http://k8worker1.example.com:30701/iam/admin/config/api/v1/config -d @MatchLDAPAttribute_input.xml

4. Validate the change with the same command you originally used to query the component, noting the value of the MatchLDAPAttribute tag:

   curl -i -u oamadmin:<LDAP_USER_PWD> http://k8worker1.example.com:30701/iam/admin/config/api/v1/config?path=/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules

   Example output:

   HTTP/1.1 200 OK
   Date: Tue, 09 Jul 2019 20:30:33 GMT
   Content-Length: 625
   Content-Type: text/xml
   X-ORACLE-DMS-ECID: 6f9baf65-751b-4fc9-b2e1-ade5b38063ff-00000427
   X-ORACLE-DMS-RID: 0
   Set-Cookie: JSESSIONID=g3LYbkLA2bs5-9zfoMBqKTBbk0mky_8URGgzFnbNkm8n3tK63tq4!1064195705; path=/; HttpOnly

   <Configuration xmlns="http://www.w3.org/2001/XMLSchema" schemaLocation="http://higgins.eclipse.org/sts/Configuration Configuration.xsd" Path="/DeployedComponent/Server/NGAMServer/Profile/AuthenticationModules/DAPModules">

   <Setting Name="DAPModules" Type="htf:map">
       <Setting Name="7DASE52D" Type="htf:map">
         <Setting Name="MAPPERCLASS" Type="xsd:string">oracle.security.am.engine.authn.internal.executor.DAPAttributeMapper</Setting>
         <Setting Name="MatchLDAPAttribute" Type="xsd:string”>uid</Setting>
         <Setting Name="name" Type="xsd:string">DAP</Setting>
       </Setting>
     </Setting>

Updating the TapEndpoint URL

For OAM/OIM integration to work you must update the OAM TapEndpoint URL you do this by performing the following steps.

1. Log in to Oracle Fusion Middleware Control using the following URL:

   http://igdadmin.example.com/em

   Or

   http://k8worker1.example.com:30711/em

   The Administration Server host and port number were in the URL on the End of Configuration screen (Writing Down Your Domain Home and Administration Server URL). The default Administration Server port number is 7101.

2. Click WebLogic Domain, and click System MBean Browser.

   In the search box, enter SSOIntegrationMXBean, and click Search. The mbean is displayed.

3. Set the value of TapEndpointURL to

   https://login.example.com/oam/server/dap/cred_submit

4. Click Apply.

Running the Reconciliation Jobs

Run the Oracle Identity Governance domain to import the LDAP user names into the Oracle Identity Governance database.

To run the reconciliation jobs:

1. Log in to the OIM System Administration Console as the user xelsysadm.
2. Click Scheduler under System Configuration.
3. Enter SSO* in the search box.
4. Click the arrow for the Search Scheduled Jobs to list all the schedulers.
5. Select SSO User Full Reconciliation.
6. Click Run Now to run the job.
7. Repeat for SSO Group Create And Update Full Reconciliation.
8. Log in to the OIM Identity Console and verify that the user weblogic_iam is visible.

Configuring OIM Workflow Notifications to be Sent by Email

OIM uses the human workflow, which is integrated with the SOA workflow. The SOA server configures email to receive the notifications that are delivered to the user mailbox. The user can accept or reject the notifications.

Both incoming and outgoing email addresses and mailboxes dedicated to the portal workflow are required for the full functionality. See Configuring Human Workflow Notification Properties in Administering Oracle SOA Suite and Oracle Business Process Management Suite.

To configure the OIM workflow notifications:

1. Log in to the Fusion Middleware Control by using the administrators account. For example, weblogic_iam.
2. Expand the Target Navigation panel and navigate to SOA > soa-infra (soa_server1) service.
3. From the SOA infrastructure drop-down, select SOA Administration > Workflow Properties.
4. Set the Notification mode to Email. Provide the correct e-mail address for the notification service.
5. Click Apply and confirm when prompted.
6. Verify the changes.
7. Expand Target Navigation, select User Messaging Service, and then usermessagingdriver-email (soa_servern). Each SOA Managed Server that is running will have a driver. Only one of these entries should be selected.
8. From the User Messaging Email Driver drop-down list, select Email Driver Properties.
9. Click Create if the email driver does not exist already.
10. Click Test and verify the changes.
11. Click OK to save the email driver configuration.
12. Restart the SOA cluster. No configuration or restart is required for OIM.

Adding the wsm-pm Role to the Administrators Group

After you configure a new LDAP-based Authorization Provider and restart the Administration Server, add the enterprise deployment administration LDAP group (WLSAdministrators) as a member to the policy.Updater role in the wsm-pm application stripe.

1. Sign in to the Fusion Middleware Control by using the administrator's account. For example: weblogic_iam.
2. From the WebLogic Domain menu, select Security, and then Application Roles.
3. Select the wsm-pm application stripe from the Application Stripe drop-down menu.
4. Click the triangular icon next to the role name text box to search for all role names in the wsm-pm application stripe.
5. Select the row for the policy.Updater role to be edited.
6. Click the Application Role Edit icon to edit the role.
7. Click the Application Role Add icon on the Edit Application Role page.
8. In the Add Principal dialog box, select Group from the Type drop-down menu.
9. To search for the enterprise deployment administrators group, enter the group name WLSAdministrators in the Principal Name Starts With field and click the right arrow to start the search.
10. Select the appropriate administrators group in the search results and click OK.
11. Click OK on the Edit Application Role page.

Adding the WebLogic Administration Group to SOA Administrators

To manage SOA using the users in the LDAP administration group 'WLSAdministrators', you should add the name of the group to the SOA Administrators group.

To add the group:

1. Sign in to the Fusion Middleware Control by using the administrator's account. For example: weblogic.
2. In the navigation pane, click WebLogic Domain and from the Security menu, select Application Roles.
3. From the drop-down list, select soa-infra to set the application stripe. Click Search.
4. Click SOAAdmin. Ensure that you see Administrators in the membership box.
5. Click Edit. The Edit page is displayed.
6. Click Add in the Members box. The Add Principal search box is displayed.
   1. Enter the following:
      • Type: Group
      • Principal Name starts with: WLS
   2. Click Search.
   3. From the Results box, select WLSAdministrators and click OK.
      You will be redirected to the Edit screen. Ensure that the members are Administrators and WLSAdministrators.
   4. Click OK.

Adding the Oracle Access Manager Load Balancer Certificate to the Oracle Keystore Service

The Oracle Identity Governance to Business Intelligence Reports link inside of the Self Service application requires that the SSL certificate used by the load balancer be added to the Oracle Keystore Service Trusted Certificates.

To add the certificate, do the following:

1. Create a directory to hold user created keystores and certificates.

   kubectl exec -n <OIGNS> -ti <OIG_DOMAIN_NAME>-adminserver -- mkdir -p SHARED_CONFIG_DIR/keystores

   For example:

   kubectl exec -n oigns -ti governancedomain-adminserver -- mkdir -p /u01/oracle/user_projects/keystores

2. Obtain the certificate from the load balancer. You can obtain the load balancer certificate from using a browser, such as Firefox. However, the easiest way to obtain the certificate is to use the openssl command. The syntax of the command is as follows:

   openssl s_client -connect LOADBALANCER -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM>LOADBALANCER.pem

   For example:

   openssl s_client -connect login.example.com:443 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM >login.example.com.pem

   The openssl command saves the certificate to a file called login.example.com.pem in SHARED_CONFIG_DIR/keystores.

3. Copy the certificate to Kubernetes using the following command:

   kubectl cp <FILENAME> <NAMESPACE>/<DOMAIN_NAME>-adminserver:<SHARED_CONFIG_DIR>/keystores

   For example:

   kubectl cp login.example.com.pem oigns/$domain_name-adminserver:/u01/oracle/user_projects/keystores/login.example.com.pem

4. Load the certificate into the Oracle Keystore Service using WLST.
   1. Connect to the container using the command:

      kubectl exec -n oigns -ti governancedomain-adminserver -- /bin/bash

   2. Connect to WLST using the following command:

      ORACLE_HOME/oracle_common/common/bin/wlst.sh

   3. Connect to the Administration Server using the following command:

      connect('<OAM_WEBLOGIC_USER>','<OAM_WEBLOGIC_PWD>','t3://<OAM_DOMAIN_NAME>-adminserver.<OIGNS>.svc.cluster.local:30012')

      For example:

      connect('weblogic','<password>','t3://governancedomain-adminserver.oigns.svc.cluster.local:7101')

   4. Load the certificate using the following commands:

      svc = getOpssService(name='KeyStoreService')
      svc.importKeyStoreCertificate(appStripe='system',name='trust',password='', keypassword='',alias='<CertificateName>',type='TrustedCertificate', filepath='/<SHARED_CONFIG_DIR>/keystores/<LOADBALANCER>.pem')

   5. Synchronize the Keystore Service with the file system using the following command:

      syncKeyStores(appStripe='system', keystoreFormat='KSS')

      For example:

      connect('weblogic','password','t3://governancedomain-adminserver.oigns.svc.cluster.local:7101')
      svc = getOpssService(name='KeyStoreService')
      svc.importKeyStoreCertificate(appStripe='system',name='trust',password='', keypassword='',alias='login.example.com',type='TrustedCertificate', filepath='/u01/oracle/user_projects/keystores/login.example.com.pem')
      syncKeyStores(appStripe='system',keystoreFormat='KSS')
      exit()

You will need to restart the domain for the changes to take effect. The default password for the Node Manager keystores is COMMON_IAM_PASSWORD. You will be prompted to confirm that the certificate is valid.

Setting the Initial Server Count

When you first created the domain, you specified that only one Managed Server has to be started. This value ensured that the OIG bootstrap process was completed successfully. After you complete the configuration, you can increase the initial server count to the actual number you require.

When the domain is created, two files, namely domain.yaml and domain_oim_soa.yaml are also created. You used these files to initialize the domain in Kubernetes. After completing the initial configuration and the bootstrap process, you no longer need to use the domain.yaml file. The domain_oim_soa.yaml file will start the necessary servers.

To start the remaining servers and to ensure that so many servers continue to start in future, you need to update the domain file. To increase the server count, use the following command:

kubectl patch cluster -n <OIGNS> <OIG_DOMAIN_NAME>-${CLUSTER_NAME} --type=merge -p '{"spec":{"replicas":<INITIAL_SERVER_COUNT>}}'

If you want two SOA and two OIM Managed Servers, use the following commands:

kubectl patch cluster -n oigns governancedomain-soa-cluster --type=merge -p '{"spec":{"replicas":2}}'

kubectl patch cluster -n oigns governancedomain-oim-cluster --type=merge -p '{"spec":{"replicas":2}}'

Setting Challenge Questions

If you have integrated OAM and OIM, then after the environment is ready, you need to set up the challenge questions for your system users.

To set up the challenge questions, log in to Identity Self Service using the URL: https://prov.example.com/identity.

Log in with your user name and when prompted, add the challenge questions. You should set up these questions for the following users:

• xelsysadm
• weblogic_iam
• oamadmin

Integrating Oracle Identity Manager with Oracle Business Intelligence Publisher

Oracle Identity Manager comes with a number of prebuilt reports that can be used to provide information about Oracle Identity and Access Management.

Oracle Identity Manager reports are classified based on the functional areas such as Access Policy Reports, Request and Approval Reports, Password Reports, and so on. It is no longer named Operational and Historical. These reports are not generated through Oracle Identity Manager but by the Oracle Business Intelligence Publisher (BIP). Oracle Identity Manager reports provide a restriction for Oracle BI Publisher.

The setup of a highly available enterprise deployment of Oracle BI Publisher is beyond the scope of this document. For more information, see Understanding the Business Intelligence Enterprise Deployment Topology in the Enterprise Deployment Guide for Business Intelligence.

Note:

During BI configuration for Oracle Identity Manager, you must configure only Business Intelligence Publisher. If you select other components during BI Publisher configuration, such as Business Intelligence Enterprise Edition and Essbase, the integration with Oracle Identity Manager may not work. See Configuring Reports in Developing and Customizing Applications for Oracle Identity Governance

• Creating a User to Run BI Reports
  
• Configuring Oracle Identity Manager to Use BI Publisher
  
• Assigning the BIServiceAdministrator Role to idm_report
  
• Storing the BI Credentials in Oracle Identity Governance
  
• Creating OIM and BPEL Data Sources in BIP
  
• Deploying Oracle Identity Governance Reports to BI
  
• Enable Certification Reports
  
• Validating the Reports
  
• Adding the Business Intelligence Load Balancer Certificate to Oracle Keystore Trust Service
  
• Restarting the IAMGovernanceDomain
  You have to restart the domain for the changes to take effect.

Creating a User to Run BI Reports

You may ignore this section if you already have a user to run reports in your Business Intelligence domain.

If you need to create a user in your BI Publisher domain to run reports, use the following LDIF command to create a user in the LDAP directory.

1. Create a file called /workdir/OIG/report_user.ldif with the following contents:

   dn: cn=idm_report,cn=Users,dc=example,dc=com
   changetype: add
   orclsamaccountname: idm_report
   givenname: idm_report
   sn: idm_report
   userpassword: <password>
   mail: idm_report
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   objectclass: inetorgperson
   objectclass: orcluser
   objectclass: orcluserV2
   uid: idm_report
   cn: idm_report

2. Save the file.
3. Load the file into the LDAP directory using the following command:

   ldapmodify -D cn=oudadmin -h idstore.example.com -p 1389 report_user.ldif

Configuring Oracle Identity Manager to Use BI Publisher

You can set up Oracle BI Publisher to generate Oracle Identity Manager reports.

To configure Oracle Identity Manager to use the BI Publisher:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control using the URL:
   http://igdadmin.example.com/em
2. Click WebLogic Domain, and then select System MBean Browser.
3. Enter XMLConfig.DiscoveryConfig as the search criteria and click Search.
   The XMLConfig.DiscoveryConfig MBean is displayed.
4. Update the value of the Discovery Config BI publisher URL to the BIP URL. For example, http://bi.example.com
5. Click Apply.

Assigning the BIServiceAdministrator Role to idm_report

If you are using LDAP as your identity store in the Business Intelligence (BI) domain, you must have created an LDAP authenticator in the BI domain. You can view the user and group names stored within LDAP.

The Oracle Identity Manager (OIM) system administration account (for example, idm_report) needs to be assigned the BIServiceAdministrator role, to generate reports.

To assign this role:

1. Ensure that the OIM administrator user is visible in the domain by logging in to the BI publisher WebLogic Console using the following URL:

   http://biadmin.example.com/console

2. Click Security Realms, and then click myrealm.
3. Go to the Users and Groups tab.
4. Look at the list of users and ensure that the user OIM Administration User (idm_report) is in the list of users.
5. Sign in to the BI Fusion Middleware Control by using the URL http://biadmin.example.com/em and the administrator's account. For example: weblogic_bi.
6. From the WebLogic Domain menu, select Security, and then Application Roles.
7. From the Application Stripe drop-down list, select obi.
8. Click the triangular icon next to the role name text box to search for all role names in the obi application stripe.
9. Select the row for the BIServiceAdministrator role to edit.
10. Click the Application Role Edit icon to edit the role.
11. Click the Application Role Add icon on the Edit Application Role page.
12. In the Add Principal dialog box, select User from the Type drop-down menu.
13. To search for the idm_report user, enter the user name idm_report in the Principal Name Starts With field and click the right arrow to start the search.
14. Select the appropriate user in the search results and click OK.
15. Click OK on the Edit Application Role page.

Storing the BI Credentials in Oracle Identity Governance

To configure BIP credentials in Oracle Identity Manager:

1. Log in to the Oracle Enterprise Manager using the url
   http://igdadmin.example.com/em
2. In the left pane, expand the  Weblogic Domain. The domain name is displayed.
3. Right-click the domain name, and navigate to Security, and then Credentials. A list of maps in the credential store, including the oim map, is displayed.
4. Expand the oim map. A list of entries of type Password is displayed.
5. Edit the BIPWSKey key if it already exists, or create a new one with the following values:

   Table 19-7 Properties of a new CSF entry

   Attribute	Value
   Select Map	oim
   Key	BIPWSKey
   Type	Password
   Username	idm_report
   Password	idm_report password
   Description	Login credentials for BI Publisher web service

Creating OIM and BPEL Data Sources in BIP

Create OIM Datasource

Oracle BIP must be connected to the OIM and SOA database schemas to run a report.

In order to do this you need to create BIP datasources using the following procedure:

1. Login to the BI Publisher Home page using the URL https://bi.example.com/xmlpserver

2. Click the Administration link on the top of the BI Publisher Home page. The BI Publisher Administration page is displayed.

3. Under Data Sources, click JDBC Connection link. The Data Sources page is displayed.

4. In the JDBC tab, click Add Data Source to create a JDBC connection to your database. The Add Data Source page is displayed.

5. Enter values in the following fields:

   Table 19-8 OIM Add Data Source Attributes

   Attributes	Value
   Data Source Name	Specify the Oracle Identity Governance JDBC connection name. For example, OIM JDBC.
   Driver Type	Select Oracle 11g for an 11g database and Oracle 12c for a 12c database
   Database Driver Class	Specify a driver class to suit your database, such as oracle.jdbc.OracleDriver
   Connection String	Specify the database connection details in the format jdbc:oracle:thin:@HOST_NAME:PORT_NUMBER/SID. For example, jdbc:oracle:thin:@igddbscan:1521/oim.example.com
   User name	Specify the Oracle Identity Governance database user name for example IGD_OIM
   Password	Specify the Oracle Identity Governance database user password.

6. Click Test Connection to verify the connection.

7. Click Apply to establish the connection.

8. If the connection to the database is established, a confirmation message is displayed indicating the success.

9. Click Apply.

In the JDBC page, you can see the newly defined Oracle Identity Governance JDBC connection in the list of JDBC data sources.

Create BPEL Datasource

1. Login to the BI Publisher Home page using the URL https://bi.example.com/xmlpserver.

2. Click the Administration link on the BI Publisher home page. The BI Publisher Administration page is displayed.

3. Under Data Sources, click JDBC Connection link. The Data Sources page is displayed.

4. In the JDBC tab, click Add Data Source to create a JDBC connection to your database. The Add Data Source page is displayed.

5. Enter values in the following fields:

   Table 19-9 JDBC Add Data Source Attributes

   Attributes	Value
   Data Source Name	Specify the Oracle Identity Governance JDBC connection name. For example, BPEL JDBC.
   Driver Type	Oracle 12c
   Database Driver Class	Specify a driver class to suit your database, such as oracle.jdbc.OracleDriver
   Connection String	Specify the database connection details in the format jdbc:oracle:thin:@HOST_NAME:PORT_NUMBER/SID. For example, jdbc:oracle:thin:@igddbscan:1521/oim.example.com
   User name	Specify the Oracle Identity Governance database user name for example IGD_SOAINFRA.
   Password	Specify the Oracle Identity Governance database user password.

6. Click Test Connection to verify the connection.

7. Click Apply to establish the connection.

8. If the connection to the database is established, a confirmation message is displayed indicating the success.

9. Click Apply.

In the JDBC page, you can see the newly defined Oracle Identity Governance JDBC connection in the list of JDBC data sources.

Deploying Oracle Identity Governance Reports to BI

After BI Publisher is integrated with Oracle Identity Governance, you can deploy the predefined reports for using them. To deploy Oracle Identity Manager reports:

1. Copy and unzip the predefined report /u01/oracle/idm/server/reports/oim_product_BIPReports_12c.zip located on OIMHOST1 file to the directory Shared_Storage_location/biconfig/bidata.

   Note:

   The Shared_Storage_Location is defined in the ASERVER_HOME/config/fmwconfig/bienv/core/bi-environment.xml file.
2. Add folder level permission to the BIServiceAdministrator BI application role to view and run the predefined Oracle Identity Governance reports. To do so:

   • Login to Oracle BI Publisher https://bi.example.com/xmlpserver by using the WebLogic admin credentials.

   • Click the Catalog link at the top. The Oracle Identity Manager named folder under shared folders is displayed in the left pane. Select the Oracle Identity Manager named folder.

   • Click Permissions option under the Tasks window on the bottom left.

   • Click the plus sign and perform a blank search on the available role.

   • Select the BI Service Administrator role, and add to the right panel.

   • Click Ok.

3. Logout as WebLogic user.
4. Login as the Oracle Identity Manager system administrator user to BI Publisher console.
5. Run the Oracle Identity Manager reports.

Enable Certification Reports

Select or deselect the Enable Certification Reports option to enable or disable the certification reports. To enable the generation of certification reports, after configuring the BI Publisher credentials and URL, perform the following:

1. Log in to the Oracle Identity Self Service using the url: https://prov.example.com/identity.
2. Click the Compliance tab.
3. Click the Identity Certification box.
4. Select Certification Configuration. The Certification Configuration page is displayed.
5. Select the Enable Certification Reports.
6. Click Save.

Note:

By default, the Compliance tab is not shown. If you want to enable compliance functionality, you must fist set the OIGIsIdentityAuditorEnabled property to true in the Sysadmin Console (located in the Configuration Properties section).

Validating the Reports

We need to create the sample data source to generate reports against the sample data source.

Creating the Sample Reports

To view an example report data without running a report against the production JDBC Data Source, generate a sample report against the sample data source. Create the sample data source before you can generate the sample reports.

• Generating Reports Against the Sample Data Source
  
• Generating Reports Against the Oracle Identity Manager JDBC Data Source
  
• Generating Reports Against the BPEL-Based JDBC Data Source
  

Generating Reports Against the Sample Data Source

After you create the sample data source, you can generate sample reports against it by performing the following steps:

1. Login to Oracle BI Publisher using the url : https://bi.example.com/xmlpserver.
2. Click Shared Folders.
3. Click  Oracle Identity Manager Reports.
4. Select Sample Reports.
5. Click View for the sample report you want to generate.
6. Select an output format for the sample report and click View.

The sample report is generated.

Generating Reports Against the Oracle Identity Manager JDBC Data Source

To generate reports against the OIM JDBC data source, navigate to the Oracle Identity Manager reports by logging in to the Oracle BI Publisher, and select an output format for the report you want to generate.

To generate reports against the Oracle Identity Manager JDBC data source:

1. Log in to Oracle BI Publisher using the url :https://bi.example.com/xmlpserver.
2. Navigate to Oracle Identity Manager reports. To do so:

   • In the BI Publisher home page, under Browse or Manage, click Catalog Folders. Alternatively, you can click Catalog at the top of the page.

     The Catalog page is displayed with a tree structure on the left side of the page and the details on the right.

   • On the left pane, expand Shared Folders, and navigate to the Oracle Identity Manager. All the objects in the Oracle Identity Manager folder are displayed.

     You are ready to navigate to BI Publisher 12c and use the Oracle Identity Manager BI Publisher reports.

3. Click View under the report you want to generate.
4. Select an output format for the report and click View.

The report is generated.

Generating Reports Against the BPEL-Based JDBC Data Source

Some reports have a secondary data source, which is BPEL-based JDBC data source. This section describes how to generate reports against the BPEL-based JDBC data source.

Reports With Secondary Data Source

The following four reports have a secondary data source, which connects to the BPEL database to retrieve the BPEL data:

• Task Assignment History

• Request Details

• Request Summary

• Approval Activity

These reports have a secondary data source (BPEL-based JDBC data source) called BPEL JDBC. To generate reports against the BPEL-based JDBC data source:

1. Log in to Oracle BI Publisher using the url: https://bi.example.com/xmlpserver.
2. Navigate to the Oracle Identity Manager reports. To do so:

   • In the BI Publisher home page, under Browse or Manage, click Catalog Folders. Alternatively, you can click Catalog at the top of the page.

     The catalog page is displayed with a tree structure on the left side of the page and the details on the right.

   • On the left pane, expand Shared Folders, and navigate to the Oracle Identity Manager. All the objects in the Oracle Identity Manager folder is displayed.

     Navigate to the BI Publisher 12c and use the Oracle Identity Manager BI Publisher reports.

3. Select the report you want to generate and click Open.
4. Select an output format for the report, and click Apply.

The report is generated based on the BPEL-based JDBC data source.

Adding the Business Intelligence Load Balancer Certificate to Oracle Keystore Trust Service

The Oracle Identity Governance to Business Intelligence Reports link inside of the Self Service application requires that the SSL certificate used by the load balancer be added to the Oracle Keystore Service Trusted Certificates.

To add the certificate:

1. Create a directory to hold user created keystores and certificates.

   kubectl exec -n <OIGNS> -ti <OIG_DOMAIN_NAME>-adminserver -- mkdir -p SHARED_CONFIG_DIR/keystores

   For example:

   kubectl exec -n oigns -ti governancedomain-adminserver -- mkdir -p /u01/oracle/user_projects/keystores

2. Obtain the certificate from the load balancer. You can obtain the load balancer certificate from using a browser, such as Firefox. However, the easiest way to obtain the certificate is to use the openssl command. The syntax of the command is as follows:

   openssl s_client -connect LOADBALANCER -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM>LOADBALANCER.pem

   For example:

   openssl s_client -connect bi.example.com:443 -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM>bi.example.com.pem

   The openssl command saves the certificate to a file called bi.example.com.pem in SHARED_CONFIG_DIR/keystores.

3. Copy the certificate to Kubernetes using the following command:

   kubectl cp <FILENAME> <OIGNS>/<OIG_DOMAIN_NAME>-adminserver:<SHARED_CONFIG_DIR>/keystores

   For example:

   kubectl cp bi.example.com.pem oigns/$governancedomain-adminserver:/u01/oracle/user_projects/keystores/bi.example.com.pem

4. Load the certificate into the Oracle Keystore Service using WLST.
   1. Connect to WLST using the following command:

      /u01/oracle/oracle_common/common/bin/wlst.sh

   2. Connect to the Administration Server using the following command:

      connect('<AdminUser>','<AdminPwd>','t3://<Adminserverhost>:<Adminserver port>')

      For example:

      connect('weblogic','<password>','t3://governancedomain-adminserver.oigns.svc.cluster.local:7101')

   3. Load the certificate using the following commands:

      svc = getOpssService(name='KeyStoreService')
      svc.importKeyStoreCertificate(appStripe='system',name='trust',password='', keypassword='',alias='<CertificateName>',type='TrustedCertificate', filepath='/<SHARED_CONFIG_DIR>/keystores/<LOADBALANCER>.pem')

   4. Synchronize the Keystore Service with the file system using the following command:

      syncKeyStores(appStripe='system', keystoreFormat='KSS')

      For example:

      connect('weblogic','password','t3://governancedomain-adminserver.oigns.svc.cluster.local:7101')
      svc = getOpssService(name='KeyStoreService')
      svc.importKeyStoreCertificate(appStripe='system',name='trust',password='', keypassword='',alias='bi.example.com',type='TrustedCertificate', filepath='/u01/oracle/user_projects/keystores/bi.example.com.pem')
      syncKeyStores(appStripe='system',keystoreFormat='KSS')
      exit()

You will need to restart the domain for the changes to take effect. The default password for the JDK is changeit. The default password for the Node Manager keystores is COMMON_IAM_PASSWORD. You will be prompted to confirm that the certificate is valid.

Restarting the IAMGovernanceDomain

You have to restart the domain for the changes to take effect.

You can restart by using the following commands:

kubectl -n <OIGNS> patch domains <OIG_DOMAIN_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "NEVER" }]'

After everything is stopped, it can be restarted using the following command:

kubectl -n <OIGNS> patch domains <OIG_DOMAIN_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IF_NEEDED" }]'

For example:

kubectl -n oigns patch domains governancedomain --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "NEVER" }]'
kubectl -n oigns patch domains governancedomain --type='json' -p='[{"op": "replace", "path": "/spec/serverStartPolicy", "value": "IF_NEEDED" }]'

Enabling Design Console Access

You cannot access the Design Console that is installed as part of the installation because it is inside a container and requires access to an external X Window environment.

If you want to use the Design Console, you must create a standalone installation and point it to the deployment.

The Design Console interacts with OIG using the T3 protocol. This protocol is not enabled by default.

To enable access to the Design Console:

1. Expose the OIM servers' T3 port using Ingress or NodePort.
2. Update the T3 channel inside the WebLogic Server to allow requests to a named Kubernetes worker node.
3. Add a Java switch to allow external access to the T3 port.

The following sections explain the steps to add the add the Java switch.

• Creating an Ingress Service to Expose the T3 Port
  
• Creating a NodePort Service to Expose the T3 Port
  
• Updating the T3 Channel
  
• Adding the Java Property to the domain_oim_soa.yaml File
  
• Accessing the OIG Deployment from the Design Console
  

Creating an Ingress Service to Expose the T3 Port

A T3 channel is already created as part of the deployment. To can expose this T3 port using Ingress:

1. Create a file called design-console-ingress.yaml in the working directory, with the following contents:

   # Load balancer type. Supported values are: NGINX
   type: NGINX
   # Type of Configuration Supported Values are : NONSSL,SSL
   # tls: NONSSL
   tls: NONSSL
   # TLS secret name if the mode is SSL
   secretName: dc-tls-cert
   
   # WLS domain as backend to the load balancer
   wlsDomain:
     domainUID: governancedomain
     oimClusterName: oim_cluster
     oimServerT3Port: 14002

2. Create the Ingress by using the following commands:

   cd $WORKDIR/sample

   helm install oig-designconsole-ingress kubernetes/design-console-ingress --namespace oigns --values $WORKDIR/design-console-ingress.yaml

3. Verify that the Ingress has been created by using the following command:

   kubectl get ingress -n oigns

Creating a NodePort Service to Expose the T3 Port

A T3 channel is already created as part of the deployment. You need to create a NodePort service to interact with T3 channel.

Note:

T3 is exposed from only one Managed Server/Pod in the cluster at a given time.

1. Create the /workdir/OIG/oim_t3_nodeport.yaml file with the following content:

   kind: Service
   apiVersion: v1
   metadata:
     name: <OIG_DOMAIN_NAME>-oim-t3-nodeport
     namespace: <OIGNS>
   spec:
     type: NodePort
     selector:
       weblogic.clusterName: oim_cluster
       weblogic.domainUID: <OIG_DOMAIN_NAME>
       weblogic.serverName: oim_server1
     ports:
       - targetPort: 14002
         port: 14002
         nodePort: <OIG_OIM_T3_PORT_K8>
         protocol: TCP
     sessionAffinity: ClientIP

   For example:

   kind: Service
   apiVersion: v1
   metadata:
     name: governancedomain-oim-t3-nodeport
     namespace: oigns
   spec:
     type: NodePort
     selector:
       weblogic.clusterName: oim_cluster
       weblogic.domainUID: governancedomain
       weblogic.serverName: oim_server1
     ports:
       - targetPort: 14002
         port: 14002
         nodePort: 30142
         protocol: TCP
     sessionAffinity: ClientIP

2. Create the service using the command:

   kubectl apply -f /workdir/OIG/oim_t3_nodeport.yaml

   You can check that the service is created successfully by using the following command:

   kubectl get service -n <OIGNS>

   For example:

   kubectl get service -n oigns

   The output appears as follows:

   service/governancedomain-oim-t3-nodeport created 

Updating the T3 Channel

After you create the NodePort Service, you have to bind WebLogic Server to it.

To bind the service:

1. Log in to the WebLogic Console using the http://igdadmin.example.com/console URL.
2. Navigate to Environment, click Servers, and then select oim_server1.
3. Click Protocols, and then click Channels.
4. Click the default T3 channel called T3Channel.
5. Click Lock and Edit.
6. Set the External Listen Address to one of the Kubernetes worker node. For example: K8WORKER1.example.com.
7. Set the External Listen Port to the Kubernetes service port you defined earlier. See Creating a NodePort Service to Expose the T3 Port. For example: 30142.
8. Click Save.
9. Click Apply Changes.

Adding the Java Property to the domain_oim_soa.yaml File

To add the Java property:

1. Edit the domain_oim_soa.yaml domain file located inside the WebLogic Kubernetes Operator directory. For example: /workdir/OIG/samples/create-oim-domain/domain-home-on-pv/output/weblogic-domains/<OIG_DOMAIN_NAME>.
2. Locate the section which starts with the line: - clusterName: oim_cluster.
3. In this section, append the property -Dweblogic.rjvm.allowUnknownHost=true to the USER_MEM_ARGS value. For example: After editing, the file appears as follows:

   - clusterName: oim_cluster
       serverService:
         precreateService: true
       serverStartState: "RUNNING"
       serverPod:
         # Instructs Kubernetes scheduler to prefer nodes for new cluster members where there are not
         # already members of the same cluster.
         affinity:
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
               - weight: 100
                 podAffinityTerm:
                   labelSelector:
                     matchExpressions:
                       - key: "weblogic.clusterName"
                         operator: In
                         values:
                           - $(CLUSTER_NAME)
                   topologyKey: "kubernetes.io/hostname"
         env:
         - name: USER_MEM_ARGS
           value: "-Djava.security.egd=file:/dev/./urandom -Xms4096m -Xmx8192m -Dweblogic.rjvm.allowUnknownHost=true"
       replicas: 2

4. Save the file.
5. Apply the changes using the following command:

   kubectl apply -f domain_oim_soa.yaml

6. Restart the domain for the changes to take effect.

Accessing the OIG Deployment from the Design Console

After you have performed a standalone deployment of the Design Console, you can access the console by using the following URL:

http://K8WORKER1.example.com:30142/

Note:

The http protocol is used rather than the usual T3 protocol because you are using a WebLogic Channel.

Centralized Monitoring Using Grafana and Prometheus

If you are using a centralized Prometheus and Grafana deployment to monitor your infrastructure, you can send Oracle Identity Governance data to this application. If you have not yet deployed Prometheus and Grafana, see Installing Prometheus and Grafana.

To use the centralized Prometheus and Grafana for monitoring your infrastructure, perform the following steps:

• Downloading and Compiling the Monitoring Application
  
• Deploying the Monitoring Application into the WebLogic Domain
  
• Configuring the Prometheus Operator
  
• Discovering the Prometheus Service
  

Downloading and Compiling the Monitoring Application

To download and configure the monitoring application for the Oracle Identity Governance cluster:

1. Change the directory to the sample scripts which set up monitoring:

   cd <WORKDIR>/samples/monitoring-service/scripts

   For example:

   cd /workdir/OAM/samples/monitoring-service/scripts

2. Run the get-wls-exporter.sh script.

   Before you run the script, set the environment variables that determine your environment setup:

   export adminServerPort=<OIG_ADMIN_PORT>

   export wlsMonitoringExporterTosoaCluster=true

   export soaManagedServerPort=8001

   export wlsMonitoringExporterTooimCluster=true

   export oimManagedServerPort=14100

   export domainNamespace=<OIGNS>

   export domainUID=<OIG_DOMAIN_NAME>

   export weblogicCredentialsSecretName=<OIG_DOMAIN_NAME>-credentials

   For example:

   export adminServerPort=7101

   export wlsMonitoringExporterTosoaCluster=true

   export soaManagedServerPort=8001

   export wlsMonitoringExporterTooimCluster=true

   export oimManagedServerPort=14100

   export domainNamespace=oigns

   export domainUID=governancedomain

   export weblogicCredentialsSecretName=governancedomain-credentials

   Execute the script using the following command:

   ./get-wls-exporter.sh

   The output appears as follows:

     
   % Total    % Received % Xferd   Average Speed   Time    Time       Time  Current
                                   Dload   Upload  Total   Spent      Left  Speed
     0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
   100 2196k  100 2196k    0     0  1138k      0  0:00:01  0:00:01 --:--:-- 6365k
   created /home/opc/workdir/OIG/samples/monitoring-service/scripts/wls-exporter-deploy dir
   adminServerName is empty, setting to default "AdminServer"
   soaClusterName is empty, setting to default "soa_cluster"
   oimClusterName is empty, setting to default "oim_cluster"
   created /tmp/ci-rsqE8LWMAw
   /tmp/ci-rsqE8LWMAw ~/workdir/OIG/samples/monitoring-service/scripts
   in temp dir
     adding: WEB-INF/weblogic.xml (deflated 61%)
     adding: config.yml (deflated 60%)
   ~/workdir/OIG/samples/monitoring-service/scripts
   created /tmp/ci-xD6iyUUBut
   /tmp/ci-xD6iyUUBut ~/workdir/OIG/samples/monitoring-service/scripts
   in temp dir
     adding: WEB-INF/weblogic.xml (deflated 61%)
     adding: config.yml (deflated 60%)
   ~/workdir/OIG/samples/monitoring-service/scripts
   created /tmp/ci-l0Caci13DM
   /tmp/ci-l0Caci13DM ~/workdir/OIG/samples/monitoring-service/scripts
   in temp dir
     adding: WEB-INF/weblogic.xml (deflated 61%)
     adding: config.yml (deflated 60%)
   ~/workdir/OIG/samples/monitoring-service/scripts

Deploying the Monitoring Application into the WebLogic Domain

The earlier section created a number of WAR files containing the monitoring application. See Downloading and Compiling the Monitoring Application. These files need to be deployed inside the WebLogic domain. Oracle provides a script to deploy the files. Before you run the script, copy the files to the container containing the WebLogic Administration Server.

To deploy the application:

1. Change directory to the sample file location:

   cd <WORKDIR>/samples/monitoring-service/scripts

   For example:

   cd /workdir/OIG/samples/monitoring-service/scripts

2. Copy files to the Administration Server container by using the following commands:

   kubectl cp <WORKDIR>/samples/monitoring-service/scripts/wls-exporter-deploy  <OIGNS>/<OIG_DOMAIN_NAME>-adminserver:/u01/oracle

   kubectl cp <WORKDIR>/samples/monitoring-service/scripts/deploy-weblogic-monitoring-exporter.py  <OIGNS>/<OIG_DOMAIN_NAME>-adminserver:/u01/oracle/wls-exporter-deploy

   For example:

   kubectl cp /workdir/OIG/samples/monitoring-service/scripts/wls-exporter-deploy  oigns/governancedomain -adminserver:/u01/oracle

   kubectl cp /workdir/OIG/samples/monitoring-service/scripts/deploy-weblogic-monitoring-exporter.py  oigns/governancedomain-adminserver:/u01/oracle/wls-exporter-deploy

3. Deploy the application using the following command:

   kubectl exec -it -n <OIGNS> <OIG_DOMAIN_NAME>-adminserver -- /u01/oracle/oracle_common/common/bin/wlst.sh \
   -domainName <OIG_DOMAIN_NAME> \
   -adminServerName AdminServer \
   -adminURL <OIG_DOMAIN_NAME>-adminserver:<OIG_ADMIN_PORT> \
   -username <OIG_WEBLOGIC_USER> \
   -password <OIG_WEBLOGIC_PWD> \
   -oimClusterName oim_cluster \
   -wlsMonitoringExporterTooimCluster true \
   -soaClusterName soa_cluster \
   -wlsMonitoringExporterTosoaCluster true

   For example:

   kubectl exec -it -n oigns governancedomain-adminserver -- /u01/oracle/oracle_common/common/bin/wlst.sh \
   -domainName governancedomain \
   -adminServerName AdminServer \
   -adminURL accessdomain-adminserver:7101 \
   -username weblogic \
   -password MyPassword \
   -oimClusterName oim_cluster \
   -wlsMonitoringExporterTooimCluster true \
   -soaClusterName soa_cluster \
   -wlsMonitoringExporterTosoaCluster true

   The output appears as follows:

   Initializing WebLogic Scripting Tool (WLST) ...
   
   Welcome to WebLogic Server Administration Scripting Shell
   
   Type help() for help on available commands
   
   Connecting to t3://governancedomain-adminserver:7101 with userid weblogic ...
   Successfully connected to Admin Server "AdminServer" that belongs to domain "governancedomain".
   
   Warning: An insecure protocol was used to connect to the server.
   To ensure on-the-wire security, the SSL port or Admin port should be used instead.
   
   Deploying .........
   Deploying application from /u01/oracle/wls-exporter-deploy/wls-exporter-adminserver.war to targets AdminServer (upload=true) ...
   <Aug 22, 2022 10:52:21 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, wls-exporter-adminserver [archive: /u01/oracle/wls-exporter-deploy/wls-exporter-adminserver.war], to AdminServer .>
   .Completed the deployment of Application with status completed
   Current Status of your Deployment:
   Deployment command type: deploy
   Deployment State : completed
   Deployment Message : no message
   Starting application wls-exporter-adminserver.
   <Aug 22, 2022 10:52:29 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating start operation for application, wls-exporter-adminserver [archive: null], to AdminServer .>
   .Completed the start of Application with status completed
   Current Status of your Deployment:
   Deployment command type: start
   Deployment State : completed
   Deployment Message : no message
   Deploying .........
   Deploying application from /u01/oracle/wls-exporter-deploy/wls-exporter-soa.war to targets soa_cluster (upload=true) ...
   <Aug 22, 2022 10:52:32 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, wls-exporter-soa [archive: /u01/oracle/wls-exporter-deploy/wls-exporter-soa.war], to soa_cluster .>
   ..Completed the deployment of Application with status completed
   Current Status of your Deployment:
   Deployment command type: deploy
   Deployment State : completed
   Deployment Message : no message
   Starting application wls-exporter-soa.
   <Aug 22, 2022 10:52:42 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating start operation for application, wls-exporter-soa [archive: null], to soa_cluster .>
   .Completed the start of Application with status completed
   Current Status of your Deployment:
   Deployment command type: start
   Deployment State : completed
   Deployment Message : no message
   Deploying .........
   Deploying application from /u01/oracle/wls-exporter-deploy/wls-exporter-oim.war to targets oim_cluster (upload=true) ...
   <Aug 22, 2022 10:52:45 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, wls-exporter-oim [archive: /u01/oracle/wls-exporter-deploy/wls-exporter-oim.war], to oim_cluster .>
   .Completed the deployment of Application with status completed
   Current Status of your Deployment:
   Deployment command type: deploy
   Deployment State : completed
   Deployment Message : no message
   Starting application wls-exporter-oim.
   <Aug 22, 2022 10:52:52 AM GMT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating start operation for application, wls-exporter-oim [archive: null], to oim_cluster .>
   .Completed the start of Application with status completed
   Current Status of your Deployment:
   Deployment command type: start
   Deployment State : completed
   Deployment Message : no message
   Disconnected from weblogic server: AdminServer
   
   
   Exiting WebLogic Scripting Tool.
   
   <Aug 22, 2022 10:52:55 AM GMT> <Warning> <JNDI> <BEA-050001> <WLContext.close() was called in a different thread than the one in which it was created.>

Configuring the Prometheus Operator

Prometheus enables you to collect metrics from the WebLogic Monitoring Exporter. The Prometheus Operator identifies the targets by using service discovery. To get the WebLogic Monitoring Exporter end point discovered as a target, you must create a service monitor that points to the service.

The exporting of metrics from wls-exporter requires basicAuth. Therefore, a Kubernetes secret is created with the user name and password that are base64 encoded. This secret is used in the ServiceMonitor deployment. The wls-exporter-ServiceMonitor.yaml file has basicAuth with credentials as username: <OIG_WEBLOGIC_USER> and password: <OIG_WEBLOGIC_PWD> in base64 encoded.

1. Run the following command to get the base64 encoded version of the weblogic username:

   echo -n "weblogic” | base64

   The output appears as follows:

   d2VibG9naWM=

2. Run the following command to get the base64 encoded version of the weblogic password:

   echo -n "<OIG_WEBLOGIC_PWD>" | base64

   The output appears as follows:

   V2VsY29tZTE=

3. Copy the template file <WORKDIR>/samples/monitoring-service/manifests/wls-exporter-ServiceMonitor.yaml.template to <WORKDIR>/samples/monitoring-service/manifests/wls-exporter-ServiceMonitor.yaml.
4. Update the <WORKDIR>/samples/monitoring-service/manifests/wls-exporter-ServiceMonitor.yaml location and change the user and password values to the values returned in Step 2.
   Also, change the values of the following to match the OAM namespace, domain name, and Prometheus release name. For example:

   • namespace: oigns
   • weblogic.domainName: governancedomain
   • release: kube-prometheus
     You can get the release name by using the command:

     kubectl get prometheuses.monitoring.coreos.com --all-namespaces -o jsonpath="{.items[*].spec.serviceMonitorSelector}"

   For example:

   apiVersion: v1
   kind: Secret
   metadata:
     name: basic-auth
     namespace: oigns
   data:
     password: V2VsY29tZTE=
     user: d2VibG9naWM=
   type: Opaque
   ---
   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: wls-exporter
     namespace: oigns
     labels:
       k8s-app: wls-exporter
       release: monitoring
   spec:
     namespaceSelector:
       matchNames:
       - oigns
     selector:
       matchLabels:
         weblogic.domainName: governancedomain
     endpoints:
     - basicAuth:
         password:
           name: basic-auth
           key: password
         username:
           name: basic-auth
           key: user
       port: default
       relabelings:
         - action: labelmap
           regex: __meta_kubernetes_service_label_(.+)
       interval: 10s
       honorLabels: true
       path: /wls-exporter/metrics

5. Update the <WORKDIR>/samples/monitoring-service/manifests/prometheus-roleSpecific-domain-namespace.yaml and <WORKDIR>/samples/monitoring-service/manifests/prometheus-roleBinding-domain-namespace.yaml files and change the namespace to match the OIG namespace. For example:

   prometheus-roleSpecific-domain-namespace.yaml

    apiVersion: rbac.authorization.k8s.io/v1
   items:
   - apiVersion: rbac.authorization.k8s.io/v1
     kind: Role
     metadata:
       name: prometheus-k8s
       namespace: oigns
     rules:
     - apiGroups:
       - ""
       resources:
       - services
       - endpoints
       - pods
       verbs:
       - get
       - list
       - watch
   kind: RoleList

   prometheus-roleBinding-domain-namespace.yaml

   apiVersion: rbac.authorization.k8s.io/v1
   items:
   - apiVersion: rbac.authorization.k8s.io/v1
     kind: RoleBinding
     metadata:
       name: prometheus-k8s
       namespace: oigns
     roleRef:
       apiGroup: rbac.authorization.k8s.io
       kind: Role
       name: prometheus-k8s
     subjects:
     - kind: ServiceAccount
       name: prometheus-k8s
       namespace: monitoring
   kind: RoleBindingList

6. Run the following command to enable Prometheus:

   kubectl apply -f

   The output appears as follows:

   rolebinding.rbac.authorization.k8s.io/prometheus-k8s created
   role.rbac.authorization.k8s.io/prometheus-k8s created
   secret/basic-auth created
   servicemonitor.monitoring.coreos.com/wls-exporter created

Discovering the Prometheus Service

After you deploy ServiceMonitor, wls-exporter is discovered by Prometheus and is able to collect the metrics.

1. Access the following URL to view the Prometheus service discovery:

   http://<K8_WORKER1>:32101/service-discovery

2. Click <OIGNS>/wls-exporter/0, and then click Show More. Verify that all the targets are listed.

Centralized Log File Monitoring Using Elasticsearch and Kibana

If you are using Elasticsearch and Kibana, you can configure a Logstash pod to send the log files to the centralized Elasticsearch/Kibana console. Before you configure the Logstash pod, ensure that you have access to a centralized Elasticsearch deployment.

• OIG persistent volume, so it can be loaded by the Logstash pod to hunt for log files.
• The location of the log files in the persistent volumes.
• The location of the centralized Elasticsearch.

To configure the Logstash pod, perform the following steps. The assumption is that you have an Elasticsearch running inside the Kubernetes cluster, in a namespace called elkns.

• Creating a Secret for Elasticsearch
  
• Creating a Configuration Map for ELK Certificate
  
• Creating a Configuration Map for Logstash
  
• Creating a Logstash Deployment
  

Creating a Secret for Elasticsearch

Logstash requires credentials to connect to the elasticsearch deployment. These credentials are stored in Kubernetes as a secret.

If your Elasticsearch uses an API key for authentication, then use the following command:

kubectl create secret generic elasticsearch-pw-elastic -n <OIGNS> --from-literal password=<ELK_APIKEY>

For example:

kubectl create secret generic elasticsearch-pw-elastic -n oigns --from-literal password=afshfashfkahf5f

If Elasticsearch uses a user name and password for authentication, then use the following command:

kubectl create secret generic elasticsearch-pw-elastic -n <OIGNS> --from-literal password=<ELK_PWD>

For example:

kubectl create secret generic elasticsearch-pw-elastic -n oigns --from-literal password=mypassword

You can find the Elasticsearch password using the following command:

kubectl get secret elasticsearch-es-elastic-user -n <ELKNS> -o go-template='{{.data.elastic | base64decode}}'

Creating a Configuration Map for ELK Certificate

If you have configured a production ready Elasticsearch deployment, you would have configured SSL. Logstash needs to trust the Elasticsearch certificate to be able to communicate with it. To enable this trust, you should create a configuration map with the contents of the Elasticsearch certificate.

You would have already saved the Elasticsearch self-signed certificate. See Copying the Elasticsearch Certificate. If you have a production certificate you can use that instead.

1. Create the configuration map using the certificate, run the following command:

   kubectl create configmap elk-cert --from-file=<WORKDIR>/ELK/elk.crt -n <OIGNS>

   For example:

   kubectl create configmap elk-cert --from-file=/workdir/ELK/elk.crt -n oigns

Creating a Configuration Map for Logstash

Logstash looks for log files in the OAM installations and sends them to the centralized Elasticsearch. The configuration map is used to instruct Logstash where the log files reside and where to send them.

1. Create a file called <WORKDIR>/OIG/logstash_cm.yaml with the following contents:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: oig-logstash-configmap
     namespace: <OIGNS>
   data:
     logstash.yaml: |
     #http.host: "0.0.0.0"
     logstash-config.conf: |
       input {
         file {
           path => "/u01/oracle/user_projects/domains/logs/governancedomain/AdminServer*.log"
           tags => "Adminserver_log"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/logs/governancedomain/soa_server*.log"
           tags => "soaserver_log"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/logs/governancedomain/oim_server*.log"
           tags => "Oimserver_log"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/governancedomain/servers/AdminServer/logs/AdminServer-diagnostic.log"
           tags => "Adminserver_diagnostic"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/governancedomain/servers/**/logs/soa_server*-diagnostic.log"
           tags => "Soa_diagnostic"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/governancedomain/servers/**/logs/oim_server*-diagnostic.log"
           tags => "Oimserver_diagnostic"
           start_position => beginning
         }
         file {
           path => "/u01/oracle/user_projects/domains/governancedomain/servers/**/logs/access*.log"
           tags => "Access_logs"
           start_position => beginning
         }
       }
       filter {
         grok {
           match => [ "message", "<%{DATA:log_timestamp}> <%{WORD:log_level}> <%{WORD:thread}> <%{HOSTNAME:hostname}> <%{HOSTNAME:servername}> <%{DATA:timer}> <<%{DATA:kernel}>> <> <%{DATA:uuid}> <%{NUMBER:timestamp}> <%{DATA:misc}> <%{DATA:log_number}> <%{DATA:log_message}>" ]
         }
       if "_grokparsefailure" in [tags] {
           mutate {
               remove_tag => [ "_grokparsefailure" ]
           }
       }
       }
       output {
         elasticsearch {
           hosts => ["<ELK_HOST>"]
           cacert => '/usr/share/logstash/config/certs/elk.crt'
           index => "oiglogs-000001"
           ssl => true
           ssl_certificate_verification => false
           user => "<ELK_USER>"
           index => "oiglogs-000001"
           password => "${ELASTICSEARCH_PASSWORD}"
         }
       }

2. Save the file.
3. Create the configuration map using the following command:

   kubectl create -f <WORKDIR>/OIG/logstash_cm.yaml

   For example:

   kubectl create -f /workdir/OIG/logstash_cm.yaml

4. Validate that the configuration map has been created by using the following command:

   kubectl get cm -n <OIGNS>

   You should see oig-logstash-configmap in the list of configuration maps.

Creating a Logstash Deployment

After you create the configuration map, you can create the Logstash deployment. This deployment resides in the OAM namespace.

1. Determine the mount point of the OIG persistent volume by using the following command:

   kubectl describe domains <OIG_DOMAIN_NAME> -n <OIGNS> | grep "Mount Path"

   For example:

   kubectl describe domains governancedomain -n oigns | grep "Mount Path"

   Make a note of this value. You will require it for the file that is created in the next step.

2. Create a file called <WORKDIR>/OIG/logstash.yaml with the following contents:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: oig-logstash
     namespace: <OIGNS>
   spec:
     selector:
       matchLabels:
         k8s-app: logstash
     template: # create pods using pod definition in this template
       metadata:
         labels:
           k8s-app: logstash
       spec:
         imagePullSecrets:
         - name: dockercred
         containers:
         - command:
           - logstash
           image: logstash:<ELK_VER>
           imagePullPolicy: IfNotPresent
           name: oig-logstash
           env:
           - name: ELASTICSEARCH_PASSWORD
             valueFrom:
               secretKeyRef:
                 name: elasticsearch-pw-elastic
                 key: password
           ports:
           - containerPort: 5044
             name: logstash
           volumeMounts:
           - mountPath: <MOUNT_PATH>
             name: weblogic-domain-storage-volume
           - name: shared-logs
             mountPath: /shared-logs
           - mountPath: /usr/share/logstash/pipeline/
             name: oig-logstash-pipeline
           - mountPath: /usr/share/logstash/config/certs
             name: elk-cert
         volumes:
         - configMap:
             defaultMode: 420
             items:
             - key: logstash-config.conf
               path: logstash-config.conf
             name: oig-logstash-configmap
           name: oig-logstash-pipeline
         - configMap:
             defaultMode: 420
             items:
             - key: ca.crt
               path: elk.crt
             name: elk-cert
         - name: weblogic-domain-storage-volume
           persistentVolumeClaim:
             claimName: <OIG_DOMAIN_NAME>-domain-pvc
         - name: shared-logs
           emptyDir: {}

   Note:

   If you are using your own registry, include the registry name in the image tag. If you have created a regcred secret for your registry, replace the imagePullSecrets name with the secret name you created. For example: regcred.
3. Save the file.
4. Create the Logstash deployment by using the following command:

   kubectl create -f <WORKDIR>/OIG/logstash.yaml

   For example:

   kubectl create -f /workdir/OIG/logstash.yaml

5. You can now create a pod called logstash by using the following command:

   kubectl get pod -n oigns

   Your logs will now be available in the Kibana console.

Backing Up the Configuration

As a best practice, Oracle recommends you to back up the configuration after you have successfully extended a domain or at another logical point. Back up only after you have verified that the installation is successful so far. This is a quick backup to enable immediate restoration in case of problems in later steps.

In a Kubernetes environment, it is sufficient to back up the persistent volume and the database.

The backup destination is the local disk. You can discard this backup when the enterprise deployment setup is complete. After the enterprise deployment setup is complete, you can initiate the regular deployment-specific Backup and Recovery process.

For information about backing up your configuration, see Performing Backups and Recoveries for an Enterprise Deployment.

Running the OIM Bulkload Utility from a Container

If you want to run the oimbulkload utility from a container, create a new container image based on the Oracle Database Instant Client which also has a JDK and the oimbulkload utility installed.

Before you begin you must download a Java Development Kit RPM image.

This section includes the following topics:

• Creating a Working Directory
  
• Obtaining JDK Release 8
  
• Compiling the wlfullclient jar File in the Container
  
• Copying the Bulkload Directory from the OIG Container
  
• Creating a Dockerfile
  
• Checking the Working Directory
  
• Building the Image
  
• Starting the Image
  

Creating a Working Directory

Create a working directory to hold all of the objects you need to build the image.

For example:

mkdir -p /workdir/bulkload

Obtaining JDK Release 8

To obtain a copy of JDK release 8:

1. Download the RPM for java JDK release 8 from Java SE 8 Archive Downloads page.
2. Copy the downloaded JDK to your working directory /workdir/bulkload.

Compiling the wlfullclient jar File in the Container

The oimbulkload utility is dependent on the wlfullclient.jar file. You should generate this file inside the OIG Administration Server image by using the following command:

kubectl exec -it -n <OIGNS> <OIG_DOMAIN_NAME>-adminserver -- bash -c 'cd /u01/oracle/wlserver/server/lib ; java -jar wljarbuilder.jar'

For example:

kubectl exec -it -n oigns governancedomain-adminserver -- bash -c 'cd /u01/oracle/wlserver/server/lib ; java -jar wljarbuilder.jar'

This command creates a file in the image, called wlfullclient.jar.

Note:

This file exists only until the adminserver pod is restarted. It is not required after you create the bulk load image.

Copying the Bulkload Directory from the OIG Container

The oimbulkload utility is made up of a number of files in the Oracle container image. You should copy these files to your work directory, in a subdirectory called u01, by using the following commands:

export MW_HOME=/u01/oracle

kubectl exec -it -n oigns governancedomain-adminserver -- bash -c 'cd /u01/oracle/wlserver/server/lib ; java -jar wljarbuilder.jar'
kubectl cp oigns/governancedomain-adminserver:/u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/javax.management.j2ee.jar u01/oracle/oracle_common/modules/javax.management.j2ee.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/modules/com.bea.core.diagnostics.flightrecorder.jar u01/oracle/wlserver/modules/com.bea.core.diagnostics.flightrecorder.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/modules/com.oracle.weblogic.rjvm.jar u01/oracle/wlserver/modules/com.oracle.weblogic.rjvm.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/modules/com.oracle.weblogic.security.crypto.utils.jar u01/oracle/wlserver/modules/com.oracle.weblogic.security.crypto.utils.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/clients/com.oracle.webservices.wls.jaxws-owsm-client.jar u01/oracle/oracle_common/modules/clients/com.oracle.webservices.wls.jaxws-owsm-client.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/idmdf/idmdf-common.jar u01/oracle/idm/server/idmdf/idmdf-common.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/idmdf/event-recording-client.jar u01/oracle/idm/server/idmdf/event-recording-client.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/thirdparty/spring-context-5.1.3.RELEASE.jar u01/oracle/oracle_common/modules/thirdparty/spring-context-5.1.3.RELEASE.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/client/oimclient.jar u01/oracle/idm/server/client/oimclient.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/oracle.jrf/jrf-api.jar u01/oracle/oracle_common/modules/oracle.jrf/jrf-api.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/org.apache.commons.logging_1.2.jar u01/oracle/oracle_common/modules/org.apache.commons.logging_1.2.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/server/lib/wlthint3client.jar u01/oracle/wlserver/server/lib/wlthint3client.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/wlserver/server/lib/wlfullclient.jar u01/oracle/wlserver/server/lib/wlfullclient.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/apps/oim.ear/APP-INF/lib/OIMServer.jar u01/oracle/idm/server/apps/oim.ear/APP-INF/lib/OIMServer.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/apps/oim.ear/APP-INF/lib/iam-platform-utils.jar u01/oracle/idm/server/apps/oim.ear/APP-INF/lib/iam-platform-utils.jar
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/idm/server/config u01/oracle/idm/server/config
kubectl cp oigns/governancedomain-adminserver:$MW_HOME/oracle_common/modules/thirdparty/spring-core-5.1.3.RELEASE.jar u01/oracle/oracle_common/modules/thirdparty/spring-core-5.1.3.RELEASE.jar
chmod +x u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/scripts/*.sh

Note:

There is no '/' in front of u01 by design.

Creating a Dockerfile

A Dockerfile is used to determine how the image is built. This file resides in the work directory regardless of whether you are using Docker or podman to build the image. It has the following contents:

FROM  ghcr.io/oracle/oraclelinux7-instantclient:21

ADD /jdk-8u202-linux-x64.rpm /jdk-8u202-linux-x64.rpm
RUN yum install -y https://yum.oracle.com/repo/OracleLinux/OL7/oracle/instantclient21/x86_64/getPackage/oracle-instantclient-{basic,tools,jdbc}-21.5.0.0.0-1.x86_64.rpm jdk-8u202-linux-x64.rpm tar
RUN mkdir -p /usr/lib/oracle/21/client64/rdbms /usr/lib/oracle/21/client64/jdbc
RUN cp -r /usr/lib/oracle/21/client64/lib /usr/lib/oracle/21/client64/jdbc

COPY u01 ./u01
ENV PATH=$PATH:/usr/lib/oracle/21/client64/bin
ENV JAVA_HOME=/usr
ENV MW_HOME=/u01/oracle
ENV OIM_ORACLE_HOME=/u01/oracle/idm
ENV ORACLE_HOME=/usr/lib/oracle/21/client64

Save the file.

Checking the Working Directory

At the end of this process, you will have the following files in the work directory:

• jdk-8u202-linux-x64.rpm
• u01 with various subdirectories
• Dockerfile

Building the Image

To build the image:

1. Use the following command:

   podman build -t <REGISTRY>/database/bulkload:latest -f Dockerfile

   Or

   docker build -t <REGISTRY>/database/bulkload:latest -f Dockerfile

   For example:

   podman build -t iad.ocir.io/mytenancy/database/bulkload:latest -f Dockerfile

   This command:

   • Pull the latest database instant client container from GitHub.
   • Extends the image with the instant client tools.
   • Modifies the structure of the container so it looks like a database home directory
   • Installs the JDK.
   • Copies the oimbulkload utility and its dependencies into the image.
   • Sets up the default environment variables in the image for JAVA_HOME, MW_HOME, OIM_ORACLE_HOME, and ORACLE_HOME.
2. After you have created the image, view it in your local repository tagged with your container registry, using the following command:

   podman images

3. If required, push the image to the container registry by using the command:

   podman  push iad.ocir.io/mytenancy/database/bulkload:latest

Starting the Image

You can now start the image in Kubernetes and use it to perform bulk load activities. The following steps show how to start the image and use an NFS mounted filesystem for your csv files.

• Creating a Pod File
  
• Starting the Bulkload Pod
  
• Running the Bulkload Utility
  

Creating a Pod File

Create a file called bulkload.yaml with the following contents:

apiVersion: v1
kind: Pod
metadata:
  name: bulkload
  namespace: <OIGNS>
  labels:
    app: dbclient
spec:
  restartPolicy: OnFailure
  volumes:
    - name: oigbulkpv
      nfs:
        server: <PVSERVER>
        path: <OID_BULK_SHARE>
  containers:
  - name: bulkload
    image: iad.ocir.io/mytenancy/database/bulkload:latest
    volumeMounts:
      - name: oigbulkpv
        mountPath: /u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/csv_files
    command: ["/bin/bash", "-ec", "while :; do echo '.'; sleep 5 ; done"]
  imagePullSecrets:
    - name: <REGISTRY_SECRET_NAME>

For example:

apiVersion: v1
kind: Pod
metadata:
  name: bulkload
  namespace: oigns
  labels:
    app: dbclient
spec:
  restartPolicy: OnFailure
  volumes:
    - name: oigbulkpv
      nfs:
        server: nfsserver.example.com
        path: /exports/IAMPVS/oigbulkpv
  containers:
  - name: bulkload
    iad.ocir.io/mytenancy/database/bulkload:latest
    volumeMounts:
      - name: oigbulkpv
        mountPath: /u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/csv_files
    command: ["/bin/bash", "-ec", "while :; do echo '.'; sleep 5 ; done"]
  imagePullSecrets:
    - name: regcred

Starting the Bulkload Pod

You can now start the bulkload pod by using the command:

kubectl create -f bulkload.yaml

When the pod has started, you see it running in the OIG namespace by using the command:

kubectl get pods -n oigns 

1. Enter the text of the first step here.
2. Enter the text of the second step here.

Running the Bulkload Utility

Before you run the oimbulkload utility, you must first connect to the container by using the command:

kubectl exec -it -n <OIGNS> bulkload –- bash

For example:

kubectl exec -it -n oigns bulkload -- bash

The bulk load utility is located at /u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/.

To start the oimbulkload utility, use the command:

cd /u01/oracle/idm/server/db/oim/oracle/Utilities/oimbulkload/
./oim_blkld.sh

When running, the tool asks you to provide certain pieces of information depending on the type of load you are using. Here is a summary of some of the information you may be asked for:

• JAVA_HOME=/usr
• MW_HOME=/u01/oracle
• OIM_ORACLE_HOME=/u01/oracle/idm
• ORACLE_HOME=/usr/lib/oracle/21/client64
• Host where the Governance Server is running = governancedomain-cluster-oim-cluster.oigns. svc.cluster.local
• Port where the Governance Server is running = 14000

For instructions on running oimbulkload utility, see Using the Bulk Load Utility in Developing and Customizing Applications for Oracle Identity Governance.