Oracle by Example brandingDeploying Oracle Identity Governance on Oracle Cloud Infrastructure

section 0Before You Begin

This tutorial shows you how to deploy the Oracle Identity Governance (OIG) 12.2.1.4.0 application on Oracle Cloud Infrastructure.

Background

The Oracle Identity Governance application is available on the Oracle Cloud Infrastructure Marketplace and allows you to quickly deploy an instance of Oracle Identity Governance.

At present this image can be only be used for testing and development purposes and should only be used with non-sensitive data. In the current OCI MarketPlace release, SSL is not enabled at the Load Balancer or any other integration point.

OIG on OCI is deployed in a Kubernetes (K8S) cluster using the Oracle Kubernetes Engine (OKE). Lifecycle operations are performed with the Oracle WebLogic Server Kubernetes Operator.

What Do You Need?

  • An Oracle Cloud Infrastructure account
  • A basic understanding of OCI

section 1Database Prerequisites

Before deploying OIG on OCI MarketPlace the following prerequisites must be met:

  1. An Oracle Database instance must exist with connectivity from OCI. If you need to create a database in OCI there are multiple ways you can perform this task. One such way is outlined in Creating Bare Metal and Virtual Machine DB Systems.

    The database must be a supported version for OIG as outlined in Oracle Fusion Middleware 12c certifications and must meet the requirements as per Database Requirements when using Oracle Identity Governance. For the purposes of OCI MarketPlace deployments the parameters processes and open_cursors should be set to 2000.

    The database must be made publicly accessible and be in the same region where the OIG stack will be installed.
  2. Once the database is provisioned, create an Ingress rule to allow external communication to the database port on 1521. This is a requirement so OIG can create RCU schemas in the database. To create an Ingress rule:
    1. Access the OCI console, and from the Navigation Menu select Networking > Virtual Cloud Networks.
    2. Under the Name column click the link that corresponds to your virtual network vcn-xxxx.
    3. Under Resources, select Security Lists.
    4. Under Security Lists click the relevant Security List for example: Default Security List vcn-xxxx.
    5. Under Ingress Rules click Add Ingress Rules.
    6. In the Add Ingress Rules window accept the default values, but change the following fields:

      Name Value
      SOURCE CIDR 0.0.0.0/0
      DESTINATION PORT RANGE 1521
    7. Click Add Ingress Rules.
  3. Obtain the public IP address of the database host. In the OCI Console navigate to Oracle Database > Bare Metal, VM and Exadata > DB Systems. Click the link for your DB System, and under the Resources list click Nodes. This public IP address will be used later when configuring the DB connection details during OIG provisioning.
  4. If using an Oracle database with CDB enabled then you must obtain the connection string for the PDB administration service. To find this connection string follow the section titled: To derive the connection string for a PDB administration service or an application service. This PDB connection string will be used later as the value for the OIG_DB_URL parameter during OIG provisioning. Using SQL*Plus or SQL Developer test a connection to the database using the PDB connect string.

    Note: If you are unsure of the name of the PDB administration service see Viewing Information About PDBs.
  5. Connect to the database and run xaview.sql against both the default database administration service *and* PDB administration service. For example in sqlplus:
    $ export ORACLE_SID=<SID>
    $ ORACLE_HOME/bin/sqlplus / as sysdba
    $ SQL> @/u01/app/oracle/product/12.2.0/db_1/rdbms/admin/xaview.sql
    The output will look similar to the following:
    DROP VIEW d$xatrans$
*
ERROR at line 1:
ORA-00942: table or view does not exist

DROP VIEW d$pending_xatrans$
*
ERROR at line 1:
ORA-00942: table or view does not exist

View created.
Synonym created.
View created.
Synonym created.
SQL>
    For the PDB run:
    SQL> alter session set container=<PDB>;
    SQL> @/u01/app/oracle/product/12.2.0/db_1/rdbms/admin/xaview.sql
    where <PDB> is the name of the PDB administration service e.g. pdb1

    The output will be similar to the previous.

section 2OCI Prerequisites

Before deploying OIG on OCI MarketPlace the following OCI prerequisites must be met:

  1. OIG requires two (2) or more compute nodes for the Node Pool and three (3) compute nodes for the Bastion in the respective Availability Domains. To check you have enough compute nodes available:
    1. Access the OCI console and from the Navigation Menu navigate to Governance & Administration > Limits, Quota and Usage.
    2. From the SERVICE drop down menu select Compute.
    3. From the SCOPE menu select the appropriate Availability Domain.
    4. From the COMPARTMENT menu select the compartment you wish to deploy to.
    5. Check the Available column and make sure you have sufficient computes available for the Node Shape you wish to deploy.
    For more information on the compute shapes available refer to Compute Shapes.
  2. OIG requires two (2) Virtual Cloud Network (VCN) resources to be available:
    1. From the SERVICE drop down menu select Virtual Cloud Network.
    2. From the SCOPE menu select your tenancy.
    3. From the RESOURCE menu select Virtual Cloud Networks Count.
    4. Check the Available column and make sure at least two (2) VCN's are available.
  3. OIG requires one 100Mbps Load Balancer resource to be available:
    1. From the SERVICE drop down menu select LbaaS.
    2. From the SCOPE menu select your tenancy.
    3. From the RESOURCE menu select 100Mbps Load Balancer Count.
    4. Check the Available column and make sure at least one (1) Load Balancer is available.
  4. OIG requires one (1) OKE Cluster resource to be available.
    1. From the SERVICE drop down menu select Container Engine.
    2. From the SCOPE menu select your tenancy.
    3. From the RESOURCE menu select Cluster Count.
    4. Check the Available column and make sure one (1) or more are available.
  5. OIG requires one (1) File System resource and one (1) Mount Target resource to be available:
    1. From the SERVICE drop down menu select File Storage.
    2. From the SCOPE menu select your Availability Domain.
    3. Check the Available column and make sure at least one (1) resource is available for both File System Count and Mount Target Count.
    For more information on resources see Compartment Quotas.

section 3Provision OIG on OCI Marketplace

  1. Access the OCI Marketplace.
  2. Search for the listing Oracle Identity Governance. Select the Oracle Identity Governance for Enterprise application.
  3. In the Oracle Identity Governance listing, check the Version Details show Version: 12.2.1.4.0.
  4. Launch the installation into your tenancy by selecting Get App.
  5. Select the OCI region and sign-in to your tenancy.
  6. In the upper right of the screen select the compartment where the OIG Instance will be deployed. Note: Do not select the default (root) compartment.
  7. Click Launch Stack.
  8. In the Stack Information screen, edit the Name as appropriate and add a Description if required and click Next.
  9. In the Configure Variables screen enter the variables as below:




    Name Value
    REGION The region should be the same as mentioned in the URL of the OCI console
    NODE_POOL_NODE_IMAGE_NAME Choose one of the following images:
    Oracle-Linux-7.9-2020.11.10-1
    Oracle-Linux-7.9-2020.10.26-0
    Oracle-Linux-7.8-2020.05.26-0
    Oracle-Linux-7.6
    NODE_POOL_NODE_SHAPE Choose the shape for the node pool computes, for example VM.Standard.E2.2
    NUMBER_OF_NODES

    Two (2) or more. This will be the size of the node pool in the OKE cluster.

    As per the OCI Prerequisites section, make sure you check the availability of the compute resources in the Availability Domain chosen for the NODE_POOL_NODE_SHAPE. For example if you specify two (2) nodes make sure two (2) compute resources of the chosen VM Shape are available.
    BASTION_SHAPE Choose the shape for the bastion, for example:
    VM.Standard2.1

    As per the OCI Prerequisites section, make sure you check the availability of the compute resources in the Availability Domain chosen for the bastion node. Three (3) compute resources of the chosen VM Shape are required.
    OIG_DB_URL The connection string for host:port/servicename for the database service. If using a CDB based DB then make sure you use the PDB value determined earlier in the prerequisite section e.g.
    <ipaddress>:1521/pdb1.oimdb.ocik8
    OIG_DB_SYS_USER Name of the Database Admin User e.g. SYS
    OIG_DB_SYS_USER_PASSWORD Password of the Database Admin User
    OIG_RCU_SCHEMA_PREFIX Schema Prefix for RCU. This can be a value of your choice e.g. OIG

    Ensure that this schema name is not already present in the DB.
    OIG_RCU_SCHEMA_PASSWORD Choose a complex password for the RCU Schema that meets the password criteria defined in your database.
    OIG_WEBLOGIC_DOMAIN_USER Weblogic Admin User Name e.g. weblogic
    OIG_WEBLOGIC_DOMAIN_USER_PASSWORD Weblogic Admin Password
    Show Advanced Options

    Select the checkbox to show the advanced options.

    If you want to auto-generate the SSH keys then leave the
    Auto-generate public ssh     checkbox selected, otherwise uncheck it if you want to use your own SSH key pair.
    SSH_PRIVATE_KEY_PATH This field should only to be updated if Auto-generate public ssh is unchecked.

    Enter the key in base64 format:
    -----BEGIN OPENSSH PRIVATE KEY-----
    b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABA
    AACFwAAAAdzc2gtcnNhAAAAAwEAAQAAAgEAvGcnE/MsJP7rwZG6m
    etc..
    JkmR/dwfVoEZjhXJrhGIgtaHMKpCyFSeN6wZ1gkDmKiUMU54IJ4Em
    -----END OPENSSH PRIVATE KEY-----
    SSH PUBLIC KEY

    This field should only to be updated if Auto-generate public ssh is unchecked.

    Select Choose SSH Key Files if you want to either drop the public key file or
    upload it from the local machine.

    Select Paste SSH Keys to paste in the key. Enter the key in the following format:
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA..etc..

    The rest of the variables can remain as per their default values but make sure enough resources are available as per the OCI Prerequisites section.

    Once the variables are updated as per above, click Next.
  10. In the Review screen verify the configuration variables and select Create.

    This will trigger a job that will be displayed in the OCI console. The job will show as IN PROGRESS and in the Logs section at the bottom of the screen, details of the deployment progress are displayed. The job will take approximately 45 minutes to complete. Once the job is successful the job status will show SUCCEEDED.
  11. If the job fails with status FAILED, refer to the Troubleshooting section later in this tutorial.

section 4Connecting via SSH to the Bastion Host

To connect via SSH to the bastion host:

  1. Access the OCI console, and from the Navigation Menu select Resource Manager > Stacks.
  2. Select the relevant compartment from the drop down list. A list of stacks in the compartment will be displayed. Select the stack just created e.g. OIG.
  3. In the Jobs section click the View State link for the job.
  4. In the View State window search for the string ‘bastion_ip’ using the browser search (CTRL F). Note down the ipaddress, for example: bastion_ip": "X.X.X.X".
  5. If you used your own SSH key pair move to step 7. If you used the auto-generated SSH keys, in the same window search for ‘private_key_path’. Copy the value in between the quotes, and save to a file (e.g priv.key), for example:
    -----BEGIN RSA PRIVATE KEY-----\nXXXXXXXXXXXXYYYYYYYYYYYYYYPPPPPPPPPPP++YYYYY
    YYYYTTTTTTTTTTT\IIIIIIIIIhhhhjjuuuuuu/VVVuuuuuuuuuuu908888/zdS1UCdLr/Q2q9yd12
    etc.....................................................................
+Qjl5\nxOByCUtZ8TbRbQMgEA/6G6wzVQ+mjCPy0n0ykxhWaHVj22ytfxKtApNLjwhtlZm
    \npD58jI0CgYEAv3GvEcfVPg92KmN8OH+hSrkLzz22bemNqioRvKi2mXBwfk0xu0kK\nvTdjVqwbD
    lCeAhISJxXdsT3J83pyeaGm6TrxBwUptJ8SzlZgFptpJffE1acAq8m\nXd7RoF2rBqZ5HHYYYYYkl
    kkk90zedjxPoJW6XxC3ljingatsgJzAixIMSc8=\n-----END RSA PRIVATE KEY-----\n
  6. Issue the following command to convert remove the “\n” characters:
    $ sed -i 's/\\n/\n/g' priv.key
    $ chmod 400 cluster.key
    Note: Use GitBash to perform the above command if running on a Windows environment or edit in a text editor and remove all "\n" characters.
    Note: On Windows do not run chmod 400 in GitBash. Change the properties of the file to read-only instead.

    Open the priv.key file and validate the “\n” characters are removed.
  7. Connect to the bastion host using the private key file:
    $ ssh -i priv.key opc@<bastion_ip>
    The login should be successful.

section 5Validating the OIG Setup

In this section you confirm everything is running and can access the OIG consoles.

  1. Run the following commands in the bastion host to check everything in the OIG stack is running correctly: 
    $ kubectl get nodes
    If the cluster is up and running, the output should look similar to the following:
    NAME          STATUS      ROLES      AGE     VERSION 

10.0.10.2     Ready       node       86m     v1.18.10
10.0.10.3     Ready       node       86m     v1.18.10

    To check the pods are running:

    $ kubectl get pods -n oigcluster
    The output should look similar to the following:
    NAME                                                READY   STATUS      RESTARTS   AGE
oigcluster-adminserver                                1/1   Running     0          59m
oigcluster-create-fmw-infra-sample-domain-job-2m6zr   0/1   Completed   0          82m
oigcluster-oim-server1                                1/1   Running     0          53m
oigcluster-soa-server1                                1/1   Running     0          56m
    Note: It may take several minutes for all the pods to appear as above and be in READY state.

    To check the load balancer status:
    $ kubectl get svc -n nginx
    The output should look similar to the following:
    NAME                                     TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)                      AGE
nginx-ingress-ingress-nginx-controller   LoadBalancer   10.X.X.X       150.X.X.X    80:30282/TCP,443:32664/TCP   85m
    Make note of the EXTERNAL-IP of the load balancer. This public IP address is used to connect to Oracle Identity Governance and its associated consoles.

    Note: You can also find the public IP address of the load balancer by navigating to Networking > Load Balancers in the OCI console.

  2. Launch a browser, access the following URL’s and log in with the associated username and passwords:
    Console URL Login Details
    WebLogic Console* http://<external-ip>/consoleweblogic/<password>
    Oracle Enterprise Manager Console* http://<external-ip>/em weblogic/<password>
    Oracle Identity Self Service http://<external-ip>/identity xelsysadm/<password>
    Oracle SOA Infra http://<external-ip>/soa-infraweblogic/<password>

    * Note: WebLogic Console and Oracle Enterprise Manager Console should only be used to monitor the servers in the OIG install. To control the AdminServer and OIG and SOA Managed Servers (start/stop) you must use kubectl commands. For more details see the tutorial Starting and Stopping OIG using kubectl .

section 6Layout of Resources Created in OCI for the OIG Stack

This section provides details on how you can view the resources created in OCI for the OIG Stack.

  1. To see the list of resources created in OCI for the OIG stack, access the OCI console and from the Navigation Menu select Developer Services > Resource Manager > Stacks > Stack_Name >Stack Details > Job_Name > Job Details > Associated Resources.
  2. To see the Virtual Machines created while using the OIG stack, from the Navigation Menu select Compute > Instances.
  3. The following table shows the mapping of OCI resources to VCN and Subnets:

    Input VM Shapes

    Resources

    VCN

    Subnets

    NODE_POOL_NODE_SHAPE

    2 Kubernetes worker nodes(VM)

    tfVcnForClusters

    tfRegionalSubnetForNodePool

     

    BASTION_SHAPE

    1 monitoringnode(VM)

    1 oke-bastion(VM)

    oke-oke vcn

    oke-bastion

    1 mountnode
    (This is where the FS is mounted) (VM)

    tfVcnForClusters

     tflbRegionalSubNet

    N/A

    1 Load Balancer (Default 100 MBPS)*

    tfVcnForClusters

    tflbRegionalSubNet

    The Resource, VCN, and Subnets names assume the default values were not changed during the OIG provisioning configuration.

    * Note: The Load Balancer is HTTP only


    The following diagram outlines the OIG OCI Resources:


    Description of layout.jpg follows
    Description of the illustration layout.jpg

section 7Troubleshooting

To troubleshoot a failed OIG deployment:

  1. Revisit the Database Prerequisites section and make sure all prerequisites have been followed. Test that a connection to the database can be made via the PDB connect string in SQL*Plus or similar client tool.
  2. Revisit the OCI Prerequisites section and make sure all steps have been followed and enough resources are available.
  3. Delete the failed deployment by following the section Deleting the OIG Stack.
  4. Retry the deployment by following the section Provision OIG on OCI Marketplace.
  5. In case further debugging is required check the following:

    Note: Some of the steps below may not be possible depending at what stage the deployment failed.

    1. In the Job that failed, view the Logs section at the bottom of the screen.
    2. Connect to the bastion host as per the section Connecting via SSH to the Bastion Host and in $HOME view the idmcli.log.
    3. To view logs for an individual pod, run the following on the bastion host to list the pods: 
      kubectl get pods -n oigcluster
      Run the following command to view the log for the desired pod: 
      kubectl logs <pod> -n oigcluster
    4. To view the OIG Domain logs run the following on the bastion host: 
      kubectl -n oigcluster exec -it oigcluster-adminserver bash
      This will take you into a bash shell inside the OIGcluster-adminserver pod. From here you can navigate to the logs directory and look at the OIG server logs: 
      [oracle@oigcluster-adminserver oigcluster]$ cd /u01/oracle/user_projects/domains/logs/oigcluster
[oracle@oigcluster-adminserver oigcluster]$ ls *.log *.out
      AdminServer.log               oim_server1.out
AdminServer.out               oim_server1_nodemanager.log
AdminServer_nodemanager.log   oim_server1_nodemanager.out
AdminServer_nodemanager.out   soa_server1.log
introspector_nodemanager.log  soa_server1.out
introspector_nodemanager.out  soa_server1_nodemanager.log
oigcluster.log                soa_server1_nodemanager.out
oim_server1.log
[oracle@oigcluster-adminserver oigcluster]$


section 8Deleting the OIG Stack

To delete the OIG stack, or to clean up from a failed deployment, perform the following operations:

Note: If cleaning up a failed deployment steps 1-4 may not be possible if the deployment failed before creating the bastion host. If this is the case, go direct to step 5.

  1. Connect via SSH to the bastion host.
  2. Run the following command to delete the OIG OCI components:
    $ ./idmcli_unix install oig k8s --config config/idmcli.yaml -d
    The output will look similar to the following: 
    Using config file: config/idmcli.yaml
    Running Task ➡ Prereq Validations..
    Task ➡ Prereq Validations: ✅
    Task ➡ Delete Nginx Ingress: ✅
    Task ➡ Delete Nginx Chart: ✅
    Task ➡ Delete Nginx Namespace: ✅
    Task ➡ ShutDown Servers: ✅
    Task ➡ Delete Domain Dir: ✅
    Task ➡ Delete Domain CRD: ✅
    Task ➡ Delete Domain Credentials: ❌
    Task ➡ Delete Operator Chart: ✅
    Task ➡ Delete PV: ✅
    Task ➡ Delete Operator Namespace: ✅
    Task ➡ Delete Domain Namespace: ✅
    $
  3. To delete the RCU schema from the database copy and paste the following: 
    image=$(cat config/idmcli.yaml| grep '^image *:' | sed 's/.* //' )
    oigDBURL=$(cat config/idmcli.yaml| grep '^oigDBURL *:' | sed 's/.* //' )
    oigDBSysPassword=$(cat config/idmcli.yaml| grep '^oigDBSysPassword *:' | sed 's/.* //' )
    oigDBUser=$(cat config/idmcli.yaml| grep '^oigDBUser *:' | sed 's/.* //' )
    oigDBPassword=$(cat config/idmcli.yaml| grep '^oigDBPassword *:' | sed 's/.* //' )
    kubectl -n default run -it droprcu \
        --generator=run-pod/v1 \
        --restart=Never \
        --rm --image $image \
        --env "DB_SYS_PWD=$oigDBSysPassword" \
        --env "DB_SCHEMA_PWD=$oigDBPassword" \
        --env "CONNECTION_STRING=$oigDBURL" \
        --env "RCU_PREFIX=$oigDBUser" \
        -- bash -c 'echo $$DB_SYS_PWD > /tmp/pwd.txt; echo $$DB_SCHEMA_PWD >> /tmp/pwd.txt ; /u01/oracle/oracle_common/bin/rcu -silent -dropRepository -connectString $$CONNECTION_STRING -dbUser sys -dbRole sysdba -schemaPrefix $$RCU_PREFIX -selectDependentsForComponents true -component MDS -component OIM -component SOAINFRA -component OPSS -f < /tmp/pwd.txt'
    The output will look similar to the following:
    If you don't see a command prompt, try pressing enter.
    RCU Logfile: /tmp/RCU2020-06-17_13-20_1848062729/logs/rcu.log

    Processing command line ....
Repository Creation Utility - Checking Prerequisites
Checking Global Prerequisites
Repository Creation Utility - Checking Prerequisites
Checking Component Prerequisites
Repository Creation Utility - Drop
Repository Drop in progress.
        Percent Complete: 2
        Percent Complete: 12
        Percent Complete: 14
Dropping Audit Services(IAU)
    ...
etc
...
Repository Creation Utility - Drop : Operation Completed
    pod "droprcu" deleted
$
  4. Access the OCI console and from the Navigation Menu select Developer Services > Resource Manager > Stacks. Click the OIG stack to delete.
  5. In the OIG stack page select Destroy. A Destroy job will be created and run.
  6. Once the job has completed successfully select More Actions > Delete Stack.
  7. Ensure that clusters are deleted by navigating to Developer Services > Kubernetes Clusters (OKE). If not, manually delete the clusters.
  8. When the clusters are terminated, the instances should also be automatically terminated. Navigate to Compute > Instances and check the instances are deleted. If not deleted, terminate those manually.
  9. Check the load balancer and file storage by navigating to Networking > Load Balancers. If resources still exist, manually terminate them.
  10. Check the VCN’s are destroyed by clicking on the Virtual Cloud Networks link on the same page. If not destroyed, then manually terminate the VCNs. If there are problems terminating the VCN’s then follow the Troubleshooting section Subnet or VCN Deletion.
  11. Check if the Identity Policies are removed by navigating to Identity & Security > Policies. If not destroyed then delete manually.
  12. On the same page click the Dynamic Groups link and check the Dynamic Groups are removed. If not destroyed then delete manually.
  13. When the above steps are completed, wait a few minutes to ensure all resources are cleaned up. Then check the limits to ensure those resources are now free by navigating to Governance & Administration > Limits, Quota and Usage.

next stepNext Tutorial

Starting and Stopping OIG using kubectl

next stepWant to Learn More?

Cloud Infrastructure MarketPlace
Oracle Identity Governance

feedbackFeedback

To provide feedback on this tutorial, please contact Identity Management User Assistance.