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.

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

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/myemail@email.com

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.

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/myemail@email.com --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

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

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

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

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/my.user@example.com
      #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/myemail@email.com --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

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

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

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
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

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

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

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

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:myuser@example.com

    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

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

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:

    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

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
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

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

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

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

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