21 Installing and Configuring Oracle Advanced Authentication and Oracle Adaptive Risk Management

Oracle Advanced Authentication and Risk Management (OAA and OARM) authenticates users by using multi-factor authentication. It integrates with Oracle Access Manager for OAuth authentication.

For details about installing Oracle Access Manager, see Installing and Configuring Oracle Access Manager. If you have an existing OAM deployment, you can use the same deployment. Unlike the traditional Oracle Identity and Access Management products, Oracle Advanced Authentication is deployed as a series of microservices.

In this release, Oracle uses a standalone container image to install and configure OAA. The container image is started manually in the Kubernetes cluster.

This chapter includes the following topics:

• About Oracle Advanced Authentication
  Oracle Advanced Authentication (OAA) is a standalone microservice that supports establishing and asserting the identity of users.
• About Oracle Adaptive Risk Management (OARM)
  Oracle Adaptive Risk Management (OARM) is an integrated system that aggregates risk data associated with users and user activities, analyzes and evaluates business risks posed by users and their activities, and provides advice to be acted upon to mitigate them.
• 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.
• Characteristics of the OAA Installation
  This section lists the key characteristics of the OAA installation that you are about to create. Review these characteristics to understand the purpose and context of the procedures that are used to configure OAA.
• Kubernetes Services
  If you are using NodePort Services, the Kubernetes services are created as part of the OAA installation.
• Before You Begin
  Before you begin the installation, you have to ensure that all the required tasks listed in this topic are complete.
• Creating Users and Groups in LDAP
  Oracle Advanced Authentication requires two groups to be set up within LDAP.
• Adding Existing Users to the OAA User Group
  If you want to configure your existing users to use OAA, you should add them to the newly created OAA-App-User group.
• Creating Kubernetes Namespaces
  The Kubernetes namespaces are used to store the OAA Objects.
• Creating a Container Registry Secret
  If you are using a container registry and want to pull the Oracle container images on demand, you must create a secret that contains the login details of the container registry.
• Creating a Kubernetes Secret for Docker Hub Images
  This secret allows Kubernetes to pull an image from hub.docker.com which contains third-party images such as helm, kubectl, and logstash commands. These commands are used by the OUD cron job to test for pods that are stuck in the 'Terminating' state, and restart them if necessary.
• Creating a GitHub Secret
  OAA is dependent on some containers in GitHub. If you want to pull these images directly from GitHub, you should create a secret with your GitHub credentials.
• Starting the Management Container
  Before starting the Management Container, ensure that you have created the persistent volumes.
• Granting the Management Container Access to the Kubernetes Cluster
  The OAA Management Container has built-in commands to interact with the Kubernetes cluster. You must provide the Management Container with details on how to access the Kubernetes cluster.
• Creating the Helm Configuration File
  The OAA installation procedure is dependent on a helmconfig file being present. This file is almost always an empty file.
• Creating the OAA Server Certificates
  You need to create certificates for use by OAA. OAA is configured by using only SSL communications.
• Creating the OAA Property File
  The OAA deployment is dependent on the values in a property file. This file is used for creating the database schemas and to deploy OAA itself. The steps to create the file is performed inside the OAA-MGMT pod.
• Creating the OAA Override File
  The OAA Override file is used to determine the number of each type of container that is started. In a highly available deployment, there should be a minimum of two for each container type.
• Creating the Database Schemas
  Oracle Advanced Authentication automatically creates the schemas in the database.
• Enabling OAuth
  Oracle Access Manager should have OAuth enabled to act as an OAuth server for OAA.
• Validating OAuth
  At this stage, it is important to ensure that OAuth is available and that Oracle HTTP is directing requests to the OAuth Server.
• Deploying Oracle Advanced Authentication
  To deploy the OAuth application, you should perform the steps inside the OAA-MGMT pod.
• Resolving Timeouts
  Your deployment may fail if it takes longer than the expected time to pull the container images from the container registry. You will see the error in the deployment log.
• Importing the OAA Policy Snapshot
  The snapshot populates the database schemas with the seed data. You should perform the steps to import inside the OAA-MGMT pod.
• Adding the OAA Certificate to the OHS Wallet
  You should ensure that Oracle HTTP Server trusts the OAA servers. To build the trust, you have to add the OAA certificate to the Oracle HTTP Server wallet.
• Validating OAA
  After deploying OAA, ensure that OAA is working by accessing the OAA Administration Console.
• Configuring Email/SMS Servers
  OAA has built-in email/SMS integration. You have to configure OAA to use the Email SMTP client and the SMS client.
• Integrating Oracle Advanced Authentication with Oracle Access Manager
  This procedure explains the procedure to configure OAA with OAM such that when you access a protected resource, you are presented first with the OAM credential collector, and then the session is handed off to OAA for pin code validation.

About Oracle Advanced Authentication

Oracle Advanced Authentication (OAA) is a standalone microservice that supports establishing and asserting the identity of users. OAA provides strong authentication using Multiple Authentication Factors (MFA). A wide range of authentication (challenge) factors is available out-of-the-box for establishing the identity of users.

OAA supports integration with Oracle Access Management (OAM) to provide MFA capabilities.

Features of OAA

• Runs as a standalone microservice on a Kubernetes platform and is deployed using Helm charts.
• Supports integration with the following clients to enable Multi-factor Authentication (MFA):
  • Clients that provide web-based user login flows, such as Oracle Access Management (OAM). OAA integrates with OAM through the Trusted Authentication Protocol (TAP).
  • Clients that provide API-based user login flows, such as Oracle Radius Agent (ORA). OAA integrates with ORA through REST APIs. This type of integration enables clients to manage its own user flow orchestration.
• Provides OAAAuthnPlugin for integrating with OAM. The plug-in also enables migration of user data from the identity store on OAM to OAA.
• Provides web UI (Administration UI Console) for administrators to create and manage client registrations, assurance levels, and rules. Administrators can also achieve all the administration tasks using the REST APIs.
• Provides web UI (User Preferences UI) for end-users to manage and register their challenge factors. User self-registration and management can also be performed using REST APIs.
• Web UIs are secured by OAM OAuth and OpenID Connect (OIDC).
• Provides the following challenge-factors out-of-the-box:
  • TOTP (Time-based One Time Password) with Oracle Mobile Authenticator (OMA), Google, and Microsoft
  • OTP (One Time Password) with E-MAIL and SMS
  • Yubikey OTP
  • FIDO2
  • Knowledge-based Authentication (KBA)
  • Push notifications

About Oracle Adaptive Risk Management (OARM)

Oracle Adaptive Risk Management (OARM) is an integrated system that aggregates risk data associated with users and user activities, analyzes and evaluates business risks posed by users and their activities, and provides advice to be acted upon to mitigate them.

The system works best when integrated with Oracle Advanced Authentication (OAA), which executes risk mitigation actions to Block, Challenge, or Allow user activities based on the risk assessment associated with it.

The system can also work in a stand-alone mode where it can be consulted for remedial actions by consuming applications. OARM system is highly extensible owing to its microservices-based architecture, allowing additional capabilities to be added without having to indulge in a costly upgrade process.

Features of OARM

• OARM system revolves around user activities, which are secured using business friendly rules.
• OARM is shipped with an out-of-the-box user authentication activity, which is baked in with a rich set of rules that can readily be used to secure the business. The system also provides the capability to augment the user authentication activity with additional rules, remove rules not applicable to business, or add net new user activities to be monitored. OARM supports seeding data feeds from certified external sources that would also be used in risk analytics. This, combined with OARM's profiling capability, provides the right mix of seed data for running analytics.
• Configuration of rules and managing and monitoring user activities can be achieved with an intuitively designed Administration Console. The Administration Console allows administrators to implement rules applicable to their organization without being concerned with the nuances of the underlying system.
• OARM, in conjunction with OAA, provides a large set of modern, multi-factor challenge methods enabling administrators to choose challenge mechanisms that fit their business requirements. OAA also makes integration of OARM with existing Identity Management systems such as Oracle Access Management Suite (OAM), very easy to achieve.

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 21-1 The Variables to be Changed

Variable	Sample Value	Description
<REGISTRY_ADDRESS>	iad.ocir.io/<mytenancy>	The location of the registry.
<REGISTRY_SECRET_NAME>	regcred	The name of the Kubernetes secret you created with the stored registry credentials. See Creating a Container Registry Secret.
<REG_USER>	mytenancy/oracleidentitycloudservice/[e-mail]	The name of the user you use to log in to the registry.
<REG_PWD>	<password>	The registry user password.
<OAA_MGT_REPOSITORY>	oracle/oaa-mgmt local/oracle/oaa-mgmt container-registry.oracle.com/middleware/oaa-mgmt_cpu <REGISTRY_ADDRESS>/oracle/oaa-mgmt	The name of the OAA management image file. If you have downloaded and staged a container image, this value will be: oracle/local/oaa-mgmt. If you use OLCNE, the value will be local/oaa-mgmt. If you use the Oracle container registry, the value will be container-registry.oracle.com/middleware/local/oaa-mgmt_cpu. If you use a container registry, the value will be the name of the registry with the product name: <REGISTRY_ADDRESS>/oaa-mgmt.
<OAAMGT_VER>	12.2.1.4.1_20220419	The version of the image you want to use.
<PVSERVER>	1.1.1.1	The name or IP address of the NFS server hosting the persistent volumes.
<OAANS>	oaans	The Kubernetes namespace to hold OAA objects.
<WORKDIR>	/workdir/OAA	The location where you want to create the working directory for OAA.
<OAA_CONFIG_SHARE>	/exports/IAMPVS/oaaconfigpv	The NFS mount location for the OAA configuration persistent volume.
<OAA_CRED_SHARE>	/exports/IAMPVS/oaacredpv	The NFS mount location for the OAA credential persistent volume.
<OAA_LOG_SHARE>	/exports/IAMPVS/oaalogpv	The NFS mount of the OAA logs persistent volume.
<OAA_VAULT_SHARE>	/exports/IAMPVS/oaavaultpv	The NFS mount of the OAA vault persistent volume.
<OAA_DB_SID>	iamdb11	The ORACLE_SID of the database instance that you are using. This value is required because the schemas are created by using the Oracle Data Pump Import program (impdp).
<OAA_KEYSTORE_PWD>	oaapassword	The password to be used for OAA keystores.
<UMS_SERVER_URL>	http://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001/ucs/messaging/webservice	The URL of the email server. If you are using Oracle Unified Messaging (either standalone or as part of OIG): If OIG is inside the Kubernetes cluster: http://<OIG_DOMAIN_NAME>-cluster-soa-cluster.<OIG>.svc.cluster.local:8001/ucs/messaging/webservice If OIG is outside the Kubernetes cluster: http://igdinternal.example.com/ucs/messaging/webservice
<UMS_ADMIN_USER>	weblogic	The user name of the SMTP service. For instance, in a Unified Messaging System (UMS) installation, it is the name of the WebLogic administration user.
<UMS_ADMIN_ PASSWORD>	<password>	The password of the <UMS ADMIN USER> account.
<SSL_COUNTRY>	US	Your country code.
<SSL_STATE>	California	The name of your state or locality.
<SSL_CITY>	Redwood	The name of your city.
<SSL_ORG>	Oracle Corporation	The name of your organization.
<LDAP_OAMADMIN_USER>	oamadmin	The name of the user who administers OAM.
<LDAP_USER_PWD>	<mypassword>	Password to be assigned to all the LDAP user accounts.
<OAA_OAM_TAP_PARTNER>	OAM-OAA-TAP	The name you want to give to the partner application.
<OAM_LOGIN_LBR_PROTOCOL>	https	The type of access protocol used for the login load balancer. In an SSL terminated environment, this value will be https.
<OAM_LOGIN_LBR_HOST>	login.example.com	The name of your login load balancer virtual name.
<OAM_LOGIN_LBR_PORT>	443	The port of the login load balancer virtual name.
<OAA_ADMIN_K8>	30410	The NodePort Service of the OAA administration pod.
<OAMNS>	oamns	The domain namespace to be used to store OAM objects.
<OAM_DOMAIN_NAME>	accessdomain	The name of the domain to be created.
<OIG_DOMAIN_NAME>	governancedomain	The name of the domain to be created.
<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.

Characteristics of the OAA Installation

This section lists the key characteristics of the OAA installation that you are about to create. Review these characteristics to understand the purpose and context of the procedures that are used to configure OAA.

Table 21-2 Key Characteristics of the OAA Installation

Characteristics of OAA	More Information
Each microservice is deployed into a pod in the Kubernetes cluster.	See About the Kubernetes Deployment.
Places the OAA components in a dedicated Kubernetes namespace.	See About the Kubernetes Deployment.
Uses a vault which can be file-based or OCI-based.	See Creating a Vault.
Uses the Kubernetes services to interact with microservices.	See Creating the Kubernetes Services.
Uses the Kubernetes persistent volumes to hold configuration information.	See Creating the Kubernetes Persistent Volume.
Each Kubernetes pod is built from a pre-built Oracle container image.	See Identifying and Obtaining Software Distributions for an Enterprise Deployment.
Requires Oracle Access Manager to be installed and configured.	See Installing and Configuring Oracle Identity Governance.
Installation can be standalone or integrated.	See Oracle Advanced Authentication.

Kubernetes Services

If you are using NodePort Services, the Kubernetes services are created as part of the OAA installation.

Table 21-3 Kubernetes NodePort Services

Service Name	Type	Service Port	Mapped Port
edg-cache-proxy	NodePort	32394	20000
edg-cache-rest	NodePort	30418	8080
edg-oaa	NodePort	31867 30343	80 443
edg-oaa-admin-ui	NodePort	32405	443
edg-oaa-policy	NodePort	32387	443
edg-email	NodePort	30800	443
edg-fido	NodePort	30017	80
edg-kba	NodePort	31836	443
edg-sms	NodePort	31350	443
edg-spui	NodePort	31573	443
edg-totp	NodePort	30230	443
edg-yotp	NodePort	30548	443
edg-push	NodePort	30550	443
edg-risk	NodePort	30560	443
edg-risk-cc	NodePort	30570	443

Before You Begin

Before you begin the installation, you have to ensure that all the required tasks listed in this topic are complete.

The following tasks have to complete:

• Obtain the required Oracle container images staged on each of the Kubernetes worker nodes, or hosted in a container registry to which you have access. For a list of the container images, see Procuring Software for an Enterprise Deployment.
• Configured Oracle HTTP Server as described in Installing and Configuring Oracle HTTP Server.
• Configured Oracle Unified Directory as describer in Installing and Configuring Oracle Unified Directory.
• Configured Oracle Access Manager as described in Installing and Configuring Oracle Access Manager.
• Added the missing OAM policies for OIRI as described in Adding the Missing Policies to OAM.
• Enabled WebGate as described in Configuring Single Sign-On for an Enterprise Deployment.

Note:

If you are adding to an existing deployment, you should revisit the above sections to ensure that you have the entries in place for Oracle Advanced Authentication.

Creating Users and Groups in LDAP

Oracle Advanced Authentication requires two groups to be set up within LDAP.

• OAA-Admin-Role, which is used to authenticate users who are permitted to access the OAA Admin Console.
• OAA-App-User, which contains the list of users who are permitted to access the OAA User Preference Console.

Note:

• A user can be part of only one group at a time.
• All existing users should be part of the existing OAA-APP-User group if they are part of OAA.

To create the users and groups:

1. Create an LDIF file called /workdir/OAA/oaam_admin.ldif with the following contents:

   Note:

   This example is for an OAM enabled directory.

   dn: cn=oaaadmin,cn=Users,dc=example,dc=com
   changetype: add
   objectClass: orclUserV2
   objectClass: oblixorgperson
   objectClass: person
   objectClass: inetOrgPerson
   objectClass: organizationalPerson
   objectClass: oblixPersonPwdPolicy
   objectClass: orclAppIDUser
   objectClass: orclUser
   objectClass: orclIDXPerson
   objectClass: top
   objectClass: OIMPersonPwdPolicy
   givenName: oaaadmin
   uid: oaaadmin
   orclIsEnabled: ENABLED
   sn: oaaadmin
   userPassword: <Password>
   mail: [e-mail]
   orclSAMAccountName: oaaadmin
   cn: oaaadmin
   obpasswordchangeflag: false
   ds-pwp-password-policy-dn: cn=FAPolicy,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com
   
   dn:cn=OAA-Admin-Role,cn=Groups,dc=example,dc=com
   changetype: add
   objectClass: top
   objectClass: groupofuniquenames
   uniqueMember: cn=oaaadmin,cn=Users,dc=example,dc=com
   
   dn:cn=OAA-App-User,cn=Groups,dc=example,dc=com
   changetype: add
   objectClass: top
   objectClass: groupofuniquenames
   

   Save the file.

2. Copy the file to your LDAP container. For example:

   kubectl cp workdir/OAA/oaam_admin oudns/edg-oud-ds-rs-0:/u01/oracle/config-input

3. Connect to the OUD container using the command:

   kubectl -n oudns exec -it -c oud-ds-rs edg-oud-ds-rs-0 -- /bin/bash

4. Load the LDIF file into the OUD directory using the command:

   /u01/oracle/oud/bin/ldapmodify -h edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local -p 1389 -D cn=oudadmin -w password -f /u01/oracle/config-input/oaam_admin.ldif

Adding Existing Users to the OAA User Group

If you want to configure your existing users to use OAA, you should add them to the newly created OAA-App-User group.

1. Run the following commands in the LDAP instance:

   echo "dn:cn=OAA-App-User,cn=Groups,dc=us,dc=oracle,dc=com" > /u01/oracle/config-input/update_group.ldif

   echo "changetype: modify" >> /u01/oracle/config-input/update_group.ldif

   echo "add: uniqueMember" >> /u01/oracle/config-input/update_group.ldif

   /u01/oracle/oud/bin/ldapsearch -h edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local -p 1389 -D cn=oudadmin -w password -b cn=Users,dc=us,dc=oracle,dc=com "cn=*" dn | grep -v oaaadmin | grep -v "dn: cn=Users,dc=us,dc=oracle,dc=com" | grep cn| awk ' { print "uniqueMember: "$2 } ' >> /u01/oracle/config-input/update_group.ldif

   The above commands create an LDIF file which using which you can add all of your existing users to the OAA-App-User group.

2. Review the generated /u01/oracle/config-input/update_group.ldif file and remove any users you do not want to add to the group.
3. When ready to use the LDIF file, run the following command:

   /u01/oracle/oud/bin/ldapmodify -h edg-oud-ds-rs-lbr-ldap.oudns.svc.cluster.local -p 1389 -D cn=oudadmin -w password -f /u01/oracle/config-input/update_group.ldif

Creating Kubernetes Namespaces

The Kubernetes namespaces are used to store the OAA Objects.

Use the following command to create a namespace for OAA:

kubectl create namespace <OAANS>

For example:

kubectl create namespace oaans

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 that contains the login details of the container registry.

This step is not required if you have staged the container images locally. Oracle strongly recommends the use of a container registry.

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

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

For example:

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

Note:

You should create a registry secret in the OAA namespace.

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. These commands are used by the OUD cron job to test for pods that are stuck in the 'Terminating' state, and restart them if necessary.

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

For example:

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

Creating a GitHub Secret

OAA is dependent on some containers in GitHub. If you want to pull these images directly from GitHub, you should create a secret with your GitHub credentials.See Logging in to GitHub.

To create a secret called gitcred in your namespace, use the following command:

kubectl create secret -n oaans docker-registry gitcred --docker-server=ghcr.io --docker-username=mygituser --docker-password="mytoken"

You should create this secret in the 'oaa' namespace.

Starting the Management Container

Before starting the Management Container, ensure that you have created the persistent volumes.

See Creating File Systems and Mount Targets.

To start the Management Container:

1. Create a file called oaa-mgmt.yaml with the following content:

   apiVersion: v1
   kind: Pod
   metadata:
     name: oaa-mgmt
     namespace: <OAANS>
     labels:
       app: oaamgmt
   spec:
     restartPolicy: OnFailure
     volumes:
       - name: oaaconfigpv
         nfs:
           server: <PVSERVER>
           path: <OAA_CONFIG_SHARE>
       - name: oaacred
         nfs:
           server: <PVSERVER>
           path: <OAA_CRED_SHARE>
       - name: oaalogpv
         nfs:
           server: <PVSERVER>
           path: <OAA_LOG_SHARE>
       - name: oaavaultpv
         nfs:
           server: <PVSERVER>
           path: <OAA_VAULT_SHARE>
     containers:
     - name: oaamgmt
       image: <OAA_MGT_REPOSITORY>:<OAAMGT_VER>
       volumeMounts:
         - name: oaaconfigpv
           mountPath: /u01/oracle/scripts/settings
         - name: oaacred
           mountPath: /u01/oracle/scripts/creds
         - name: oaalogpv
           mountPath: /u01/oracle/logs
         - name: oaavaultpv
           mountPath: /u01/oracle/service/store/oaa
       command: ["/bin/bash", "-ec", "tail -f /dev/null"]
     imagePullSecrets:
       - name: <REGISTRY_SECRET_NAME>

   For example:

   apiVersion: v1
   kind: Pod
   metadata:
     name: oaa-mgmt
     namespace: oaans
     labels:
       app: oaamgmt
   spec:
     restartPolicy: OnFailure
     volumes:
       - name: oaaconfigpv
         nfs:
           server: 0.0.0.0
           path: /exports/IAMPVS/oaaconfigpv
       - name: oaacred
         nfs:
           server: 0.0.0.0
           path: /exports/IAMPVS/oaacredpv
       - name: oaalogpv
         nfs:
           server: 0.0.0.0
           path: /exports/IAMPVS/oaalogpv
       - name: oaavaultpv
         nfs:
           server: 0.0.0.0
           path: /exports/IAMPVS/oaavaultpv
     containers:
     - name: oaamgmt
       image: iad.ocir.io/mytenancy/oaa-mgmt:12.2.1.4.1_20220419
       volumeMounts:
         - name: oaaconfigpv
           mountPath: /u01/oracle/scripts/settings
         - name: oaacred
           mountPath: /u01/oracle/scripts/creds
         - name: oaalogpv
           mountPath: /u01/oracle/logs
         - name: oaavaultpv
           mountPath: /u01/oracle/service/store/oaa
       command: ["/bin/bash", "-ec", "tail -f /dev/null"]
     imagePullSecrets:
       - name: regcred

2. Start the Management CLI Container using the following command:

   kubectl create -f oaa-mgmt.yaml

3. Connect to the running container using the following command:

   kubectl exec -n oaans -ti oaa-mgmt /bin/bash

Note:

When the examples instruct you to "use the following command from within the OAA-MGMT", it means that you should connect to the running container as described in this section, and then run the commands as specified.

Granting the Management Container Access to the Kubernetes Cluster

The OAA Management Container has built-in commands to interact with the Kubernetes cluster. You must provide the Management Container with details on how to access the Kubernetes cluster.

To provide access, perform the following steps on any node which has a working kubectl command:

• Creating a Kubernetes Service Secret
  
• Creating a Kubernetes Service Account
  
• Generating the ca.crt Certificate
  
• Creating a Kubernetes Configuration File for OAA
  
• Copying Files to the OAA-MGMT Container
  
• Validating the kubectl Command
  

Creating a Kubernetes Service Secret

If you are using Kubernetes 1.24 release or later, then you need to create a secret for the Kubernetes service account using the following command:

kubectl create -f <WORKDIR>/create_svc_secret.yaml

For example:

kubectl create -f /workdir/OIRI/create_svc_secret.yaml

Here, <WORKDIR>/create_svc_secret.yaml has the following content:

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
 name: oaa-service-account
 namespace: <OAANS>
 annotations:
  kubernetes.io/service-account.name: "oaa-service-account"

Creating a Kubernetes Service Account

Create a Kubernetes service account in the OAA namespace by using the following command:

kubectl apply -f <WORKDIR>/create_svc.yaml

For example:

kubectl apply -f /workdir/OAA/create_svc.yaml

Here, <WORKDIR>/create_svc.yaml has the following content:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: oaa-service-account
  namespace: <OAANS>
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: oaa-ns-role
  namespace: <OAANS>
rules:
- apiGroups: ["*"]
  resources: ["*","secrets"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oaa-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:persistent-volume-provisioner
subjects:
- namespace: <OAANS>
  kind: ServiceAccount
  name: oaa-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: oaa-clusteradmin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- namespace: <OAANS>
  kind: ServiceAccount
  name: oaa-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: oaa-rolebinding
  namespace: <OAANS>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: oaa-ns-role
subjects:
- namespace: <OAANS>
  kind: ServiceAccount
  name: oaa-service-account

Generating the ca.crt Certificate

Obtain the Kubernetes certificate using the following commands:

Set up the environment variables for the OAA namespace, and a working directory.

OAANS=oaans
WORKDIR=/workdir/OAA

For Kubernetes releases up to 1.23, use the command:

TOKENNAME=`kubectl -n $OAANS get serviceaccount/oaa-service-account -o jsonpath='{.secrets[0].name}'`

For Kubernetes releases 1.24 or later, use the commands:

TOKENNAME=oaa-service-account

TOKEN=`kubectl -n $OAANS get secret $TOKENNAME -o jsonpath='{.data.token}'| base64 --decode`

kubectl -n $OAANS get secret $TOKENNAME -o jsonpath='{.data.ca\.crt}'| base64 --decode > $WORKDIR/ca.crt

Creating a Kubernetes Configuration File for OAA

Generate a Kubernetes configuration file to instruct OAA on how to interact with kubectl.

Set up environment variables for the OAA namespace, and a working directory.

Note:

Ensure that you have set KUBECONFIG to the Kubernetes configuration file before starting.

OAANS=oaans
WORKDIR=/workdir/OAA
TOKEN=`kubectl -n $OAANS get secret $TOKENNAME -o jsonpath='{.data.token}'| base64 --decode`
K8URL=`grep server: $KUBECONFIG | sed 's/server://;s/ //g'`

kubectl config --kubeconfig=$WORKDIR/oaa_config set-cluster oaa-cluster --server=$K8URL --certificate-authority=$WORKDIR/ca.crt --embed-certs=true

kubectl config --kubeconfig=$WORKDIR/oaa_config set-credentials oaa-service-account --token=$TOKEN

kubectl config --kubeconfig=$WORKDIR/oaa_config set-context oaa --user=oaa-service-account --cluster=oaa-cluster

kubectl config --kubeconfig=$WORKDIR/oaa_config use-context oaa

These commands generate a file called oaa_config in the <WORKDIR> location. This file contains the Kubernetes cluster details.

Copying Files to the OAA-MGMT Container

Copy the ca.crt (see Generating the ca.crt Certificate) and oaa_config (see Creating a Kubernetes Configuration File for OAA) files to the OAA-MGMT Container, using the following commands:

OAANS=oaans
WORKDIR=/workdir/OAA

kubectl cp $WORKDIR/ca.crt $OAANS/oaa-mgmt:/u01/oracle/scripts/creds

kubectl cp $WORKDIR/oaa_config $OAANS/oaa-mgmt:/u01/oracle/scripts/creds/k8sconfig

From oaa-mgmt, run the following command:

chmod 400 /u01/oracle/scripts/creds/k8sconfig

Validating the kubectl Command

Validate that the kubectl command works from inside the Kubernetes container by using the following command from the OAA-MGMT container:

kubectl get pod -n $OAANS

For example:

kubectl get pod -n oaans

The command should show you the running oaa-mgmt pod.

Creating the Helm Configuration File

The OAA installation procedure is dependent on a helmconfig file being present. This file is almost always an empty file.

To create the helmconfig file:

1. Access the OAA-MGMT pod by using the following commands:

   kubectl -n oaans exec -it oaa-mgmt -- /bin/bash

2. From inside the OAA-MGMT pod, create a file called /u01/oracle/scripts/creds/helmconfig with the following contents:

   apiVersion: ""
   generated: "0001-01-01T00:00:00Z"
   repositories:
   - caFile: ""
     certFile: ""
     keyFile: ""
     name: idm-helm
     password: ""
     url:
     username: ""

3. Save the file.

Creating the OAA Server Certificates

You need to create certificates for use by OAA. OAA is configured by using only SSL communications.

To create the certificates, perform the following steps:

• Obtaining the OAM Certificate
  
• Creating the OAA Trust Store
  
• Creating the Server Certificate
  
• Adding the OAM Certificate to the Trust Store
  
• Copying the Certificate Files to the Mgmt Pod
  

Obtaining the OAM Certificate

The OAM server is configured using SSL and this will most likely be terminated at the load balancer, especially if you have followed the instructions in this guide for deploying OAM. See Installing and Configuring Oracle Access Manager. For OAA to successfully communicate with OAM, it has to trust OAM. To build this trust, you have to add the OAM certificate into the OAA trust store you will create in the next step.

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 >/workdir/OAA/LOADBALANCER.pem

For example:

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

The openssl command saves the certificate to a file called login.example.com.pem in the /workdir/OAA directory.

Creating the OAA Trust Store

To create the OAA trust store:

1. Create a key file.

   export WORKDIR=/workdir/OAA
   openssl genrsa -out $WORKDIR/ca.key 4096

2. Create a root certificate.

   openssl req -new -x509 -days 3650 -key $WORKDIR/ca.key -out $WORKDIR/ca.crt -subj "/C=<COUNTRY>/ST=<STATE>/L=<CITY>/O=<ORG>/CN=CARoot"

   For example:

   openssl req -new -x509 -days 3650 -key $WORKDIR/ca.key -out $WORKDIR/ca.crt -subj "/C=US/ST=California/L=Redwood/O=Oracle Corporation/CN=CARoot"

3. Generate the trust store.

   openssl pkcs12 -export -out $WORKDIR/trust.p12 -nokeys -in $WORKDIR/ca.crt -passout pass:<OAA_KEYSTORE_PWD>

   Make a note of the password you assign to the trust store; you will require it later.

4. Verify the root certificate and trust store.

   You can verify that you create the root certificate and trust store using the following commands:

   openssl rsa -in $WORKDIR/ca.key -check

   openssl x509 -in $WORKDIR/ca.crt -text  -noout

   openssl pkcs12 -nokeys -info -in $WORKDIR/trust.p12

   When prompted, enter the password of the trust store.

Creating the Server Certificate

To create the server certificate:

1. Create the server key.

   openssl genrsa -out $WORKDIR/oaa.key 4096

2. Create the server certificate.

   openssl req -new -key $WORKDIR/ssl/oaa.key -out $WORKDIR/ssl/cert.csr -subj "/C=$SSL_COUNTRY/ST=$SSL_STATE/L=$SSL_CITY/O=$SSL_ORG/CN=$OAM_LOGIN_LBR_HOST"

   For example:

   openssl req -new -key $WORKDIR/oaa.key -out $WORKDIR/cert.csr -subj "/C=US/ST=California/L=Redwood/O=Oracle Corporation/CN=login.example.com"

3. Create the self signing request.

   openssl x509 -req -days 1826 -in $WORKDIR/cert.csr -CA $WORKDIR/ca.crt -CAkey $WORKDIR/ca.key -set_serial 01 -out $WORKDIR/oaa.crt

4. Convert to the PKCS12 format.

   openssl pkcs12 -export -out $WORKDIR/cert.p12 -inkey $WORKDIR/oaa.key -in $WORKDIR/oaa.crt -chain -CAfile $WORKDIR/ca.crt -passout pass:<OAA_KEYSTORE_PWD>

Adding the OAM Certificate to the Trust Store

To establish a trust between OAA and OAM, the load balancer certificate for OAM should be added to the trust store.

1. 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 >/workdir/OAA/LOADBALANCER.pem

   For example:

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

   The openssl command saves the certificate to a file called login.example.com.pem in the /workdir/OAA directory.

2. Convert OAA certificate to the Privacy-Enhanced Mail (PEM) format.

   export WORKDIR=/workdir/OAA

   openssl x509 -in $WORKDIR/oaa.crt -out $WORKDIR/oaa.pem -outform PEM

3. Export the existing Certificate Authority to a certificate bundle.

   openssl pkcs12 -in $WORKDIR/trust.p12 -out $WORKDIR/bundle.pem -cacerts -nokeys -passin pass:<OAM_KEYSTORE_PWD>

4. Copy the OAM certificate into the certificate bundle.

   cat $WORKDIR/login.example.com.pem >> $WORKDIR/bundle.pem

5. Create a new trust store from the certificate bundle.

   openssl pkcs12 -export -in $WORKDIR/bundle.pem -nokeys -out $WORKDIR/trust.p12 -passout pass:<OAA_KEYSTORE_PWD>

Copying the Certificate Files to the Mgmt Pod

Copy the files to the Mgmt pod using the following commands:

kubectl cp $WORKDIR/trust.p12 oaans/oaa-mgmt:/u01/oracle/scripts/creds/trust.p12

kubectl cp $WORKDIR/cert.p12 oaans/oaa-mgmt:/u01/oracle/scripts/creds/cert.p12

Creating the OAA Property File

The OAA deployment is dependent on the values in a property file. This file is used for creating the database schemas and to deploy OAA itself. The steps to create the file is performed inside the OAA-MGMT pod.

Complete the following steps to create the property file:

• Copying the Template File
  
• Updating the Property File
  

Copying the Template File

Copy the supplied template files to the correct location:

cp /u01/oracle/installsettings/installOAA.properties /u01/oracle/scripts/settings/installOAA.properties

cp /u01/oracle/installsettings/oaaoverride.yaml /u01/oracle/scripts/settings/oaaoverride.yaml

Updating the Property File

Update the values in the property file as described in this section. If you are modifying a parameter, ensure that the parameter is not put within a comment in the property file.

You should update the /u01/oracle/scripts/settings/installOAA.properties file.

• Database Parameters
  
• Common Deployment Parameters
  
• Ingress Parameters
  
• File Based Vault
  
• OCI Based Vault
  
• Generic Parameters
  
• Sample installOAA.properties File
  

Database Parameters

Table 21-4 Database Parameters

Parameter	Sample Value	Comments
database.createschema	true	Set this value to create the OAA schemas.
database.host	dbscan.example.com	Set this value to the database server SCAN address.
database.port	1521	The database listener port.
database.svc	oaaedg.example.com	The name of the OAA database service.
database.syspassword	-	Set this value to the SYS password of the database. Ensure that the parameter is not put within a comment.
database.schema	EDGOAA	The database schema prefix to use.
database.tablespace	EDGOAA_OAA_TB	The name of the tablespace to be created. Include the schema prefix to aid manageability.
database.schemapassword	-	The password to be assigned to the OAA database schema.
database.name	-	Ensure that there is no value added to this parameter.

Common Deployment Parameters

Table 21-5 Common Deployment Parameters

Parameter	Sample Value	Comments
common.deployment.name	edg	The name of the deployment as it will appear in Helm. Note: Do not use oaa because it is reserved for system use.
common.kube.namespace	oaans	The name of the namespace you will use to hold your OAA objects.
common.deployment.keystorepassphrase	-	The password you used when you created your server certificate. See Creating the Server Certificate.
common.deployment.truststorepassphrase	-	The password you used when you created the trust store. See Creating the OAA Trust Store.
common.deployment.overridefile	/u01/oracle/scripts/settings/oaaoverride.yaml	Ensure that this value is not put within a comment.
common.deployment.import.snapshot	true	The October release does not seed the database schemas. You must set this value to true in this release. Note: After importing the snapshot, set this value to false to ensure that future upgrades do not overwrite the data.
common.deployment.import.snapshot.file	/u01/oracle/scripts/oarm-12.2.1.4.1-base-snapshot.zip	The October release does not seed the database schemas. You must set this value to the location of a snapshot file that exists in the management container. The file mentioned is the default value. If you want to download the latest version from My Oracle Support, see Doc ID 2723908.1.
oauth.domainname	OAADomain	Use the same value you added in OHS Rewrite Rules. See Step 4 of Configuring Oracle HTTP Server for Oracle Advanced Authentication and Oracle Adaptive Risk Management.
oauth.identityprovider	OAMIDSTORE	The name of the OAM ID Store. See Creating a Configuration File.
oauth.clientpassword	-	The password you want to use for OAM Oauth interactions.
oauth.adminurl	http://accessdomain-adminserver.oamns.svc.cluster.local:7001 http://iadadmin.example.com/	The URL you use to access the Oracle Access Manager Administration Server. If OAM is inside the Kubernetes cluster, you should use the internal OAM service name otherwise you should use the OAM adminsitration URL.
oauth.basicauthzheader	-	The encoded username and password value of the OAM Administration user (*).
oauth.identityuri	https://login.example.com:443/	The public entry point into OAM.
oauth.redirecturl	https://login.example.com:443/	The public entry point into OAM.
install.global.serviceurl	https://login.example.com:443/	The main entry point for the OAA application for runtime operations.
install.oaa-admin-ui.serviceurl	http://iadadmin.example.com:80	The main entry point for the OAA application for administrative operations.

(*) To encode a username and password, use the following command:

echo -n <LDAP_OAMADMIN_USER>:<LDAP_USER_PWD> | base64

For example:

echo -n oamadmin:mypassword | base64

Ingress Parameters

If you use an Ingress controller, the installation creates the Ingress services for you. Provide these values to configure OAA for Ingress.

Table 21-6 Ingress Parameters

Parameter	Value	Description
install.global.ingress.enabled	true	Set this value to true to create the Ingress services.
install.global.ingress.runtime.host	login.example.com	Set this value to the name of the virtual host used for runtime operations.
install.global.ingress.admin.host	iadadmin.example.com	Set this value to the name of the virtual host used for administration operations.

File Based Vault

You have two choices for creating a vault for OAA. You can use either a file based vault or an OCI vault. Oracle recommends you to use the OCI vault. However, if yo want to use the file based vault, you have to set the following parameters in the property file:

Table 21-7 Parameters for the File Based Vault

Parameter	Value	Comments
vault.deploy.name	oaavault	The name of the vault.
vault.provider	fks	The type of vault. Fks is a file-based vault.
vault.fks.server	0.0.0.0	The name or IP address of the NFS server.
vault.fks.path	/exports/IAMPVS/oaavaultpv	The NFS export name of the file system.
vault.fks.key	-	The password to be used for accessing the vault.

OCI Based Vault

If you want to use an OCI based vault, you have to set the following parameters in the property file:

Note:

Each of the vault.oci parameters listed in Table 21-8 should be encoded in Base64. To encode in Base64, run the following command:

echo -n "value" | base64

Table 21-8 Parameters for the OCI Based Vault

Parameter	Value	Comments
vault.deploy.name	oaavault	The name of the vault.
vault.provider	oci	The type of vault. oci is an oci-based vault.
vault.oci.uasoperator	-	To obtain this value, encode the value of the API key that you downloaded at the time of creating the vault. See Creating a Vault.
vault.oci.tenancyId	-	To obtain this value, log in to the OCI console, navigate to Profile and click Tenancy. Use the OCID value encoded as Base64.
vault.oci.userId	-	To obtain this value, log in to the OCI console, navigate to Profile and click Username. Use the OCID value encoded as Base64.
vault.oci.compartmentId	-	To obtain this value, log in to the OCI console, navigate to Identity and Security and click Compartments. Select the compartment in which you created the vault and use the OCID value encoded as Base64.
vault.oci.fpId	-	To obtain this value, log in to the OCI console, navigate to Profiles, select User Settings and then click API Keys. Use the value of the fingerprint for the API Key you created earlier. See Creating a Vault.
vault.oci.vaultId	-	To obtain this value, log in to the OCI console, navigate to Identity and Security and select Vault. Click the vault you created earlier. See Creating a Vault. Use the OCID value encoded as Base64.
vault.oci.keyId	-	To obtain this value, log in to the OCI console, navigate to Identity and Security, select Vault, and then click the vault you created earlier. See Creating a Vault. Click the key you created earlier. For example, masterkey. Use the OCID value encoded as Base64.

Generic Parameters

Table 21-9 Generic Parameters

Parameter	Value	Comments
install.global.repo	iad.ocir.io/mytenancy	The name of the container registry.
install.global.imagePullSecrets\[0\].name	regcred	The name of the Kubernetes secret with the container registry credentials.
install.global.imagePullSecrets\[1\].name	gitcred	The name of the Kubernetes secret with the GitHub credentials.
install.global.image.tag	12.2.1.4.1-20220127	The version of OAA you want to install.
install.global.oauth.logouturl	https://login.example.com:443/oam/server/logout	The OAM logout URL.
install.global.uasapikey	-	The password you want to use for the OAA REST APIs.
install.global.policyapikey	-	The password you want to use for the Policy REST APIs.
install.global.factorsapikey	-	The password you want to use for the Factors REST APIs.
install.global.riskapikey	-	The password you want to use for the Risk REST APIs.
install.oaa-admin-ui.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.oaa-policy.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.spui.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.totp.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.fido.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.push.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.email.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.sms.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.yotp.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.oaa-kba.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.risk.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.
install.risk.riskcc.service.type	ClusterIP NodePort	The type of Kubernetes service to create. Use ClusterIP if you are using ingress. Otherwise, use NodePort.

Sample installOAA.properties File

##################################### 1. Common Deployment configuration#########################################
#Common configuration options
#If enabled and set to true, helm installation will only display generated values and will not actually perform the installation.
#common.dryrun=true
#Name of the helm deployment. It is unique per kubernetes cluster and namespace. Should be all lowercase.
common.deployment.name=edg
#Override file to override any char values. Must be in yaml format.
common.deployment.overridefile=/u01/oracle/scripts/settings/oaaoverride.yaml
#Kubernetes context if there are multiple contexts available
#common.kube.context=idmoci
#Kubernetes deployment namespace where all the services will be installed.
common.kube.namespace=oaans
#Certificate store used in all the services 
common.deployment.sslcert=/u01/oracle/scripts/creds/cert.p12
#Trust store used in all the services
common.deployment.trustcert=/u01/oracle/scripts/creds/trust.p12
#Passphrase for cert.p12 file. If the value for the passphrase is not present in properties below, it will be prompted during installation.
common.deployment.keystorepassphrase=myPassword
#Passphrase for trust.p12 file. If the value for the passphrase is not present in properties below, it will be prompted during installation.
common.deployment.truststorepassphrase=myPassword
#If the flag is enabled then trust certificate in the JRE truststore
common.deployment.importtruststore=true
#The flag to disable the generation of secret in the keystore provided in the property common.deployment.sslcert. Following secret keys are generated and are required for installation to work which can also be pre-seeded in the keystore.
#spui-enckey , aes256_config_key_alias and aes256_db_key_alias
common.deployment.generate.secret=true
#Deployment mode. Possible values are OAA, Risk or Both. Default mode is Both which will install OAA integrated with Risk. 
common.deployment.mode=Both
#Base64 encoded config key from the migrating system. If enabled the value will be placed in the vault and used for migration of legacy data
#common.migration.configkey=
#Base64 encoded db key from the migrating system. If enabled the value will be placed in the vault and used for migration of db data.
#common.migration.dbkey=
#If the integation is required with OIM set the following property to true. This also enables the forgot password functionality.  
#common.oim.integration=true
#Key for Apple push notification service. Only needed when push factor is enabled.
#common.deployment.push.apnsjksfile=
#Deprecated. By default policy snapshot import is not enabled. Kindly refer document to import it post installation.
#common.deployment.import.snapshot=true
##################################### 2. Database configuration#########################################
# Database setting for OAA
#The installation supports the following ways to install and configure the database:
#1. Installing database along with installing services on kubernetes cluster 
#2. Installing database outside the installation of services and providing the database configuration below.
#In case of 2, set database.createschema=false
#If set to true schema will be created along with the installation.
database.createschema=true
#Host IP or name where Oracle DB is running. If hostname is provided then it should be resolvable from the container.
database.host=db-scan.example.com
#Database port 
database.port=1521
#Database sysdba user required to create the schema. If database.createschema is set to false, the property is not required.
database.sysuser=sys
#Sys password will not be prompted if value is provided for the property database.syspassword. If database.createschema is set to false, the property is not required.
database.syspassword=sysPassword
#Schema name to be created in the database. The value is required.
database.schema=EDG_OAA
#Name of the tablespace. If database.createschema is set to false, the property is not required.
database.tablespace=EDG_OAA_TBS
#Schema password will not be prompted if value is provided for the property database.schemapassword
database.schemapassword=schemaPassword
#Database service name 
database.svc=edgoaa.example.com
#Name of the database. In case of OCI database service, the name is present in the OCI console. If name is not present, use value of database.svc property.
database.name=iamdb1

##################################### 3. OAUTH configuration#########################################
#Oauth setting for OAA. Oauth is required for enabling spui , admin and fido.
# If oauth.enabled is set as false, install.spui.enabled , install.oaa-admin-ui.enabled and install.fido.enabled should also be set to false otherwise helm installation
# will fail. Setting the property to true enables OAM Oauth integration during installation of services.
oauth.enabled=true
#Create OAuth Domain in OAM
oauth.createdomain=true
#Create OAuth Resource in OAM 
oauth.createresource=true
#Create OAuth client in OAM
oauth.createclient=true
#OAuth domain name used when creating the OAuth domain in OAM
oauth.domainname=OAADomain
#OAuth domain identity provider configured for OAuth in OAM
oauth.identityprovider=OAMIDSTORE
#OAuth client name
oauth.clientname=OAAClient
#Grants for OAuth client created during installation. CLIENT_CREDENTIALS is required for validation to pass.
oauth.clientgrants="PASSWORD","CLIENT_CREDENTIALS","JWT_BEARER","REFRESH_TOKEN","AUTHORIZATION_CODE","IMPLICIT"
#OAuth Client Type of new OAuth client
oauth.clienttype=PUBLIC_CLIENT
#Client password must conform to regex ^[a-zA-Z0-9.\-\/+=@_ ]*$ with a maximum length of 500
oauth.clientpassword=myPassword
#OAuth resouce name for new OAuth resource
oauth.resourcename=OAAResource
#Default score of OAuth resource
oauth.resourcescope=viewResource
#Post authentication redirecturl is required. Used for validating configuration of OAuth services in OAM by generating a access token.
oauth.redirecturl=https://login.example.com:443
#Application id protected by oauth. The value can be any valid string. It is required to setup runtime integration between OAM and OAA.  
oauth.applicationid=myoaaprotectedapp1
#OAM Admin URL where OAuth API are enabled.
oauth.adminurl=http://accessdomain-adminserver.oamns.svc.cluster.local:7001
#Base64 encoded authorization header of OAM Admin server
oauth.basicauthzheader=EncodedOAMPassord
#OAM Managed server providing runtime support for OAuth Services
oauth.identityuri=https://login.example.com:443

##################################### 4. Vault configuration#########################################
#Following vaules are possible for vault.provider : oci , fks
#If oci is the provider the oci related configuration may be required to perform the vault initialization
#Name to be used in vault for this deploymemt. If name is already present in the vault, it will be reused.
vault.deploy.name=oaavault
#Flag to control the vault creation. If vault is initialized outside the installation, it should be set to false.
vault.create.deploy=true
#Provider type of vault. Supported provider types are oci, fks.
vault.provider=fks

#oci vault configuration required for the vault. Check vault documentation on how to obtain value for following properties.
#vault.oci.uasoperator=
#vault.oci.tenancyId=
#vault.oci.userId=
#vault.oci.fpId=
#vault.oci.compartmentId=
#vault.oci.vaultId=
#vault.oci.keyId=

#fks related configuration. Check the documentation on how to obtain value for properties below.
#NFS server ip or resolvable hostname. 
vault.fks.server=dbdevfssmnt-shared01.dev2fss1iad.databasede2iad.oraclevcn.com
#Path on NFS server to be mapped to folder in the running containers.
vault.fks.path=/export/IAMPVS/oaavaultpv
#Base64 encoded vault password.
vault.fks.key=TWFuYWdlcjE=
#The value in this property need to be same as the value passed through the helm chart. Do not change it
vault.fks.mountpath=/u01/oracle/service/store/oaa

##################################### 5. Chart configuration#########################################
#Note: Any property  that starts with install. will be provided as input to the helm chart using --set parameter.
#Container image repositories where the images can be pulled by the cluster nodes.
install.global.repo=iad.ocir.io/mytenancy
#Kubernetes secret reference to be used while pulling the docker images from the protected docker registries.
install.global.imagePullSecrets\[0\].name=regcred
install.global.imagePullSecrets\[1\].name=gitcred
#Chart Database properties
install.riskdb.service.type=ExternalName
#Image tags to be used
install.global.image.tag=12.2.1.4.1_20220419
#Oauth logout URL
install.global.oauth.logouturl=https://login.example.com:443/oam/server/logout

#Installation api key
#Rest Api key for OAA service.
install.global.uasapikey=myPassword
#Rest Api key for policy service.
install.global.policyapikey=myPassword
#Rest API key for all factor services.
install.global.factorsapikey=myPassword
#Rest API key for risk and risk customer care services.
install.global.riskapikey=myPassword

#In case of OCI vault, the following configuration can be overridden if provided for read-only users during helm installation.
#If the value is not provided in the properties below then it will be picked from vault section.
#All the values in the section below is optional.
#install.global.vault.mapId=b2NpZDEudmF1bHRzZWNyZXQub2MxLmlhZC5hbWFhYWFhYWRjeHl1dXFha2xmejVkbW9rcnpkajZva2Rtdmt0bGp2Y2tyZGIyd3B0emt6bHlkbTN1emEK
#install.global.vault.oci.uasoperator=
#install.global.vault.oci.tenancyId=
#install.global.vault.oci.userId=
#install.global.vault.oci.fpId=

##################################### 6. Optional configuration#########################################
##Ingress properties that can be used to enable ingress for services begin deployed.
#Deprecated property. Will be removed in future. Use install.global.ingress.enabled instead.
#install.ingress.enabled=true
#Enable ingress for all services.
install.global.ingress.enabled=true
#Ingress resource hostname. Should be all lowercase. If provided, dedicated hostname will be used to access the deployment. Otherwise can use any hostname or IP Address.
#Following configurations are deprecated. Use install.global.ingress.runtime.host and install.global.ingress.admin.host for specifying runtime and admin host
#install.global.ingress.hosts\[0\].host=oaainstall-host
#install.global.ingress.hosts\[1\].host=oaaadmin-host

#Runtime host used for accessing runtime services including all factors, oaa ,spui and risk.
install.global.ingress.runtime.host=login.example.com
#Admin host used for accessing admin, policy and risk-cc services.
install.global.ingress.admin.host=iadadmin.example.com

##Following properties are picked from database related properties if not present below.
#install.global.dbhost=
#install.global.dbport=
#install.global.dscredentials=
#install.global.dbservicename=

##Following properties are picked from oauth related properties if not present below.
#install.global.oauth.oidcidentityuri=
#install.global.oauth.oidcaudience=
#install.global.oauth.oidcclientid=

#if load balancer/ingress url is present, then configure the url here. All UI service will be behind this load balancer/ingress.
#In case ingress installation is set to true, the appropriate service url will be fetch after ingress installation
# and will be used as service url. If provided, service url from the property below will have higher priority.
install.global.serviceurl=https://login.example.com:443
#Service URL of oaa admin, if different from the service url of global oauth. 
install.oaa-admin-ui.serviceurl=http://iadadmin.example.com:80

#If oauth.enabled is set to false, uncomment following properties. Also when deployment mode is Risk spui, fido and oaa-kba services are not required.
#install.spui.enabled=false
#install.fido.enabled=false
#install.oaa-admin-ui.enabled=false
#install.oaa-kba.enabled=false

#Also authentication factor Services are enabled by default. To disable them uncomment the lines below.
#When deployment mode is Risk, the following configurations is not required.
#install.totp.enabled=false
#install.push.enabled=false
#install.sms.enabled=false
#install.yotp.enabled=false
#install.email.enabled=false

#Default service type for services is NodePort. When deployment mode is Risk following service are not deployed :
#OAA, SPUI, All Factors (fido, push, yotp, email ,sms, totp and kba)
install.service.type=ClusterIP
install.oaa-admin-ui.service.type=ClusterIP
install.oaa-policy.service.type=ClusterIP
install.spui.service.type=ClusterIP
install.totp.service.type=ClusterIP
install.fido.service.type=ClusterIP
install.push.service.type=ClusterIP
install.email.service.type=ClusterIP
install.sms.service.type=ClusterIP
install.yotp.service.type=ClusterIP
install.risk.service.type=ClusterIP
install.oaa-kba.service.type=ClusterIP
install.risk.riskcc.service.type=ClusterIP
#Properties used to install ingress using the ingress chart present in helmcharts folder

##################################### 7. Ingress configuration#########################################
#To install the ingress controller along with the services set the following flag to true. 
ingress.install=false
#Kubernetes name space which will be used to install ingress
ingress.namespace=ingress-nginx
#Admissions controller can be installed seperately. 
#Ingress admissions name is not present the controller.admissionWebhooks.enabled will be set to false in the nginx ingress chart. 
#ingress.admissions.name=ingress-nginx-controller-admission
#Ingress class name that would be used for installation. Must not be existing
ingress.class.name=ingress-nginx-class
ingress.service.type=NodePort

#anything starting with ingress.install can be additionally supplied to set the ingress chart value.
#ingress.install.releaseNameOverride=base

##################################### 8. OAA management configuration#########################################
#NFS volumes
#install.mount.config.path=<NFS_CONFIG_PATH>
#install.mount.config.server=<NFS_CONFIG_SERVER>
#install.mount.creds.path=<NFS_CREDS_PATH>
#install.mount.creds.server=<NFS_CREDS_SERVER>
#install.mount.logs.path=<NFS_LOGS_PATH>
#install.mount.logs.server=<NFS_LOGS_SERVER>
#OAA mgmt chart release name, default can be used for most installations
install.mgmt.release.name=oaamgmt
#Location of kube credentials to use for installation.
#If not provide credentials in $KUBECONFIG or ~/.kube/config will be used
#install.kube.creds=<LOCAL_PATH>/<KUBE_CREDS>
#SSL certificates
#common.local.sslcert=<LOCAL_PATH>/<LOCAL_CERT_FILE>
#common.local.trustcert=<LOCAL_PATH>/<LOCAL_TRUST_FILE>
common.deployment.import.snapshot=false
common.deployment.import.snapshot.file=/u01/oracle/scripts/oarm-12.2.1.4.1-base-snapshot.zip

Creating the OAA Override File

The OAA Override file is used to determine the number of each type of container that is started. In a highly available deployment, there should be a minimum of two for each container type.

To set the number of containers to be started, update the /u01/oracle/scripts/settings/oaaoverride.yaml file to increase the replicaCount for each type of container to the required quantity.

You can use this file to specify the resource requirements. By declaring resource requirements, you ensure that a particular OAA pod is started only on a worker node that has sufficient capacity to service a pod with these resource requirements. You can also use the HorizontalPodAutoscaler resource (see Deploying the Kubernetes HorizontalPodAutoscaler Resource), which allows the number of pods of a given type to scale up and down as demand dictates.

Note:

Add any missing entries that you require.

The example below shows resource requirements added for the oaa and spui containers.

Sample oaaoverride.yaml file:

#override file for ooa installation

#if database is external to the cluster set the flag to ExternalName
riskdb:
  service:
    type: ExternalName

#replica count of oaa service
replicaCount: 2

#The following properties define the dependency spui service and can be overridden here.
spui:
  replicaCount: 2
  resources:
    requests:
      cpu: 100m
      memory: 1Gi

#The following properties define the dependency totp service and can be overridden here.
totp:
  replicaCount: 2

#The following properties define the dependency yotp service and can be overridden here.
yotp:
  replicaCount: 2

#The following properties define the dependency fido service and can be overridden here.
fido:
  replicaCount: 2

#The following properties define the dependency oaa-admin-ui service and can be overridden here.
oaa-admin-ui:
  replicaCount: 2

#The following properties define the dependency email service and can be overridden here.
email:
  replicaCount: 2

#The following properties define the dependency push service and can be overridden here.
push:
  replicaCount: 2

#The following properties define the dependency sms service and can be overridden here.
sms:
  replicaCount: 2

#The following properties define the dependency oaa-policy service and can be overridden here.
oaa-policy:
  replicaCount: 2

#The following properties define the dependency oaa-risk service and can be overridden here.
risk:
  replicaCount: 2

#The following properties define the dependency oaa-risk service and can be overridden here.
risk-cc:
  replicaCount: 2
# Resource Requirement for OAA container.
#
resources:
  requests:
   cpu: 100m
   memory: 1Gi

Creating the Database Schemas

Oracle Advanced Authentication automatically creates the schemas in the database.

Enabling OAuth

Oracle Access Manager should have OAuth enabled to act as an OAuth server for OAA.

To enable OAuth:

1. Log in to the OAM Administration Console using the http://iadadmin.example.com/oamconsole URL. Log in using your OAM Administration user name, for example, oamadmin.
2. From the Welcome page, click Configuration, and then click Available Services.
3. Click Enable Service next to OAuth and OpenIDConnect Service (or ensure that the green status check mark appears).

Validating OAuth

At this stage, it is important to ensure that OAuth is available and that Oracle HTTP is directing requests to the OAuth Server.

You can perform a quick test by running the following command:

curl -s -k --location --request GET https://login.example.com/oauth2/rest/token

You should see the Method Not Allowed message. This means that you have successfully sent a request to the OAuth Server but it has rejected the request. If you do not see this message, ensure the following:

• You have successfully enabled OAuth in the OAM console.
• You have the appropriate Oracle HTTP Server entries in the virtual hosts files.
• You have the OAuth policies defined in OAM.

Deploying Oracle Advanced Authentication

To deploy the OAuth application, you should perform the steps inside the OAA-MGMT pod.

1. Edit the /u01/oracle/scripts/settings/installOAA.properties file.

   Set the value of the database.createschema property to false.

2. Run the following command:

   cd /u01/oracle/scripts/settings/

   /u01/oracle/OAA.sh -f installOAA.properties

   This command will deploy the OAA and OARM containers. It will also set up OAuth in the OAM Server. If the command fails, rectify the issue and edit the /u01/oracle/logs/status.info file to change the value from false to true. You can then rerun the command.

Resolving Timeouts

Your deployment may fail if it takes longer than the expected time to pull the container images from the container registry. You will see the error in the deployment log.

The error appears as follows:

NAME: oaainstall
LAST DEPLOYED: Thu Apr 29 20:24:09 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
Error: timed out waiting for the condition
TEST SUITE:     oaainstall-email-sanity-check
Last Started:   Thu Apr 29 20:24:12 2021
Last Completed: Thu Apr 29 20:29:12 2021
Phase:          Failed
NOTES:
Get the Oracle Advance Authentication(OAA) Service URL by running these commands:
  bash -c 'export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services oaainstall-oaa) && export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}") && echo "" && echo https://$NODE_IP:$NODE_PORT/health'
Helm test failed
Fail to install OAA. Please check the log file

You can run the following command to check the status of the pods:

kubectl get pods

The output appears as follows:

NAME                                       READY   STATUS          RESTARTS   AGE
edg-email-66944cd9d8-7vp7g                 1/1     Running         0          41m
edg-email-66944cd9d8-t8gcc                 1/1     Running         0          41m
edg-fido-66b969fb6f-9zcnr                  1/1     Running         0          41m
edg-fido-66b969fb6f-mzj2n                  1/1     Running         0          41m
edg-oaa-86cd6b4ff6-pxrmm                   1/1     Running         0          41m
edg-oaa-86cd6b4ff6-svlpk                   1/1     Running         0          41m
edg-oaa-admin-ui-764c555cf4-6xtzv          1/1     Running         0          41m
edg-oaa-admin-ui-764c555cf4-rxs2c          1/1     Running         0          41m
edg-oaa-kba-6d6d7bcd59-rwm5q               1/1     Running         0          41m
edg-oaa-policy-7cc99c7bc5-8tpzz            1/1     Running         0          41m
edg-oaa-policy-7cc99c7bc5-rsvqr            1/1     Running         0          41m
edg-push-794c8d89d-6xcjt                   1/1     Running         0          41m
edg-push-794c8d89d-b9xl4                   1/1     Running         0          41m
edg-risk-768fddd6b5-6k4p4                  1/1     Running         0          41m
edg-risk-768fddd6b5-wrcjh                  1/1     Running         0          41m
edg-risk-cc-77fcd64cb5-7nfft               1/1     Running         0          41m
edg-risk-cc-77fcd64cb5-bfzfn               1/1     Running         0          41m
edg-sms-7bdbf58d66-kk6qq                   1/1     Running         0          41m
edg-sms-7bdbf58d66-lp8jj                   1/1     Running         0          41m
edg-spui-59649cd778-5rbgb                  1/1     Running         0          41m
edg-spui-59649cd778-nkl8s                  1/1     Running         0          41m
edg-totp-7dc888b994-m854x                  1/1     Running         0          41m
edg-totp-7dc888b994-zgfkw                  1/1     Running         0          41m
edg-yotp-569fbbc7df-27zgm                  1/1     Running         0          41m
edg-yotp-569fbbc7df-9qsx7                  1/1     Running         0          41m
oaa-mgmt                                   1/1     Running         0          45m

If you give it time, the pods will eventually start. You can avoid the timeout by adjusting its value in the /u01/oracle/helmcharts/oaa/values.yaml file, inside the OAA Management container. The section are:

test:
  # test.image -- image name that will be used to test sanity of installation.
  image: shared/oracle/linux:8-slim
  # test.timeoutsecs time for which sanity tests will run before timing out.
  timeoutsecs: 480
  # test.waitsecs time interval between sanity checks.
  waitsecs: 50

Importing the OAA Policy Snapshot

The snapshot populates the database schemas with the seed data. You should perform the steps to import inside the OAA-MGMT pod.

To import the OAA policy snapshot:

1. Ensure that the settings/installOAA.properties file has entries for the following:

   common.deployment.import.snapshot=true
   common.deployment.import.snapshot.file=/u01/oracle/scripts/oarm-12.2.1.4.1-base-snapshot.zip

2. Import the snapshot using the following commands:

   cd ~/scripts

   ./importPolicySnapshot.sh -f settings/installOAA.properties

   The snapshot is applied if you see the message:

   Successfully applied snapshot:

   Note:

   If you see an error similar to 504 Gateway Time-out, then reissue the importPolicySnapshot.sh file. The step should succeed the second time.
3. Reset the Snapshot flag to false to ensure that future upgrades do not overwrite the data.

   Update the settings/installOAA.properties file and set common.deployment.import.snapshot=false

Adding the OAA Certificate to the OHS Wallet

You should ensure that Oracle HTTP Server trusts the OAA servers. To build the trust, you have to add the OAA certificate to the Oracle HTTP Server wallet.

To add the wallet:

1. If you have not already done so, create an Oracle Wallet on each Oracle HTTP Server. See Creating an Oracle HTTP Server Wallet
2. Obtain the OAA certificate using the following command:

   openssl s_client -connect <K8WORKER>:<OAA_ADMIN_K8> -showcerts </dev/null 2>/dev/null|openssl x509 -outform PEM > oaa.pem

   Where:

   • <K8WORKER> is one of the Kubernetes worker nodes.
   • <OAA_ADMIN_K8> is the NodePort Service of the OAA Administration pod. You can find the NodePort Service using the following command:

     kubectl get service -n oaans | grep NodePort | grep oaa-admin | awk '{ print $5 }'

3. Add the certificate to the wallet using the following commands:

   export ORACLE_HOME=/u02/private/oracle/products/ohs/

   export OHS_DOMAIN_HOME=/u02/private/oracle/config/domains/ohsDomain

   export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/oracle_common/bin:$PATH

   orapki wallet add -wallet $OHS_DOMAIN_HOME /ohswallet -trusted_cert -cert oaa.pem -auto_login_only

Validating OAA

After deploying OAA, ensure that OAA is working by accessing the OAA Administration Console.

To validate OAA, log in to the OAA Administration Console using the http://iadadmin.example.com/oaa-admin URL.

You should be redirected to the OAM Credential Collection page. Enter the user name and password for oaaadmin. If all is well, you will be asked to accept the OAuth authentication. When you click Allow, you will see the OAA Administration page.

Configuring Email/SMS Servers

OAA has built-in email/SMS integration. You have to configure OAA to use the Email SMTP client and the SMS client.

You can configure the OAA Email/SMS client using cURL. The curl command is:

curl --location --insecure --request PUT 'https://K8Worker:K8Port/oaa/runtime/config/property/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Encoded OAA User>' \
-d '[
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientURL",
        "value": "<UMS_SERVER_URL>"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientName",
        "value": "<UMS_ADMIN_USER>"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientPass",
        "value": "<UMS_ADMIN_PASSWORD>"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientURL",
        "value": "<UMS_SERVER_URL>"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientName",
        "value": "<UMS_ADMIN_USER>"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientPass",
        "value": "<UMS_ADMIN_PASSWORD>"
    }

]'

For example:

curl --location --insecure --request PUT 'http://k8worker1.example.com:32502/oaa/runtime/config/property/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic b2FhLW9hYTphcGlrZXl0b2Jlc2V0ZHVyaW5naW5zdGFsbGF0aW9u' \
-d '[
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientURL",
        "value": "http://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001/ucs/messaging/webservice
"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientName",
        "value": "weblogic"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientPass",
        "value": "password"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientURL",
        "value": "http://governancedomain-cluster-soa-cluster.oigns.svc.cluster.local:8001/ucs/messaging/webservice
"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientName",
        "value": "weblogic"
    },
    {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientPass",
        "value": "password"
    }

]'

Integrating Oracle Advanced Authentication with Oracle Access Manager

This procedure explains the procedure to configure OAA with OAM such that when you access a protected resource, you are presented first with the OAM credential collector, and then the session is handed off to OAA for pin code validation.

This integration is in addition to using OAM as an OAuth Server.

The integration procedure includes the following steps:

• Registering OAA as OAM TAP Partner
  
• Configuring the OAM Agent in OAA
  
• Restarting the OAM Domain
  
• Creating an OAM Authentication Module for OAA
  
• Creating an OAM Authentication Scheme for OAA
  
• Creating the OAM Authorization Policy
  
• Validating the OAM-OAA Integration
  

Registering OAA as OAM TAP Partner

OAA should be registered with OAM as a Trusted Authentication Protocol (TAP) partner to ensure that OAM trusts OAA.

1. Connect to the OAM Administration pod using the following command:

   kubectl exec -n oamns -it accessdomain-adminserver /bin/bash

2. Start the WebLogic Scripting Tool (WLST) using the following command:

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

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

   connect('WeblogicAdminUser','<WeblogicAdminPassword>','t3://<domain_name>domain-adminserver.<namespace>:<Admin_Port>'

   For example:

   connect('weblogic','<password>','t3://accessdomain-adminserver.oamns.svc.cluster.local:30701')

4. Run the following command to regsiter the OAA TAP partner:

   registerThirdPartyTAPPartner(partnerName = "<OAA_OAM_TAP_PARTNER>", keystoreLocation= "<K8_WORKDIR>/OAMOAAKeyStore.jks", password="<OAA_KEYSTORE_PWD>", tapTokenVersion="v2.0", tapScheme="TAPScheme", tapRedirectUrl="<OAM_LOGIN_LBR_PROTOCOL>://<OAM_LOGIN_LBR_HOST>:<OAM_LOGIN_LBR_PORT>/oam/pages/login.jsp")

   For example:

   registerThirdPartyTAPPartner(partnerName = "OAM-OAA-TAP", keystoreLocation= "/u01/oracle/user_projects/workdir/OAMOAAKeyStore.jks", password="keystorepassword", tapTokenVersion="v2.0", tapScheme="TAPScheme", tapRedirectUrl="https://login.example.com:443/oam/pages/login.jsp")

5. Copy the resulting keystore file to your work directory:

   kubectl cp oamns/accessdomain-adminserver:/u01/oracle/user_projects/workdir/OAMOAAKeyStore.jks /workdir/OAA

Configuring the OAM Agent in OAA

To configure the OAM Agent:

1. Log in to the OAA Administration Console with you administrator credentials:

   http://iadadmin.example.com/oaa-admin

2. Under Quick Actions, select Create OAM Integration.
3. In the Create Agent, Details tab, enter the following:
   • Name: <OAA_OAM_TAP_PARTNER> - The name of the partner should be same as the TAP partner name that you registered earlier. For example: OAM-OAA-TAP. See Registering OAA as OAM TAP Partner.
   • Description: OAM TAP partner for OAA.
   • Client Type: OAM.
   • Client ID: Click Re-Generate.
   • Client Secret: Click Re-Generate.
   • Private Key File: Either drag and drop the /workdir/OAA/OAMOAAKeyStore.jks key file, or click + to select the file from the file system.
   • Private Key Password: The password (<OAA_KEYSTORE_PWD>) you specified for the keystore at the time of registering the TAP partner.
4. Copy the values of Client ID and Client Secret to a safe place as these are required later, at the time of configuring OAM.
5. Click Save.
6. In the Agents screen, click the name of the agent you just created. For example: OAM-OAA-TAP
7. Click the Assurance Levels tab.
8. Click Create to create a new assurance level.
9. In the Create Assurance Level screen, enter the following details, and click Create:
   • Name: OAM-OAA-Level
   • Description: OAM-OAA-Level for OAM Integration.
10. Under Define Policy, select the factors to assign to the assurance level. For example: Oracle Mobile Authenticator and Email Challenge.
11. Click Save.

Restarting the OAM Domain

You should restart the OAM domain to enable the OAM Managed Servers to use the OAA plug-in.

Use the following commands to restart the domain:

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

After all the Kubernetes pods (with the exception of the helper pod) in the namespace have stopped, you can restart the domain by using the following command:

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

Note:

Check that all the Kubernetes pods (with the exception of the helper pod) in the namespace have stopped by using the following command:

kubectl -n <OAMNS> get all

All the Kubernetes pods (with the exception of the helper pod) in the namespace will be stopped when there are no entries for the Administration Server or the Managed Servers. For example:

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

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

Creating an OAM Authentication Module for OAA

After you have imported the OAA plug-in into OAM, you have to create an OAM Authentication Module:

1. Log in to the OAM Administration Console using the http://iadadmin.example.com/oamconsole URL.
2. In the OAM console, select Application Security, select Plug-ins, and then select Authentication Modules.
3. In the Authentication Modules tab, click Create Authentication Module, and then click Create Custom Authentication Module.
4. In the Authentication Module page, click the General tab and enter the following information:
   • Name: OAA-MFA-Auth-Module
   • Description: OAA MFA Authentication Module
5. Click the Steps link and in the Steps tab, click Add.
   In the Add New Step page, enter the following details and click OK:

   • Step Name: UserIdentificationStep
   • Description: Identify the User
   • Plug-in Name: UserIdentificationPlugIn

   Click Add again, enter the following details, and then click OK:

   • Step Name: User OAA MFA Step
   • Description: MFA with OAA
   • Plug-in Name: OAAAuthnPlugin

   Click Add again, enter the following details, and then click OK:

   • Step Name: PasswordValidation
   • Description: Validate user password on OAM
   • Plug-in Name: UserAuthenticationPlugin
6. Click User OAA MFA Step and specify the following information:
   • OAA_URL: <SPUI_URL/authn/v1>, for example, https://login.example.com:443/oaa/rui/authn/v1.
   • TAP_AGENT: <partner_name> - This value should be same as the name given at the time of registering the TAP partner with OAM. For example: OAM-OAA-TAP. See Registering OAA as OAM TAP Partner.
   • APPLICATION_ID: <app_id> - This is the name of the OAA group to associate with the OAM user names that are migrated to OAA. For example: myoaaprotectedapp1. This value must match with the value of oauth.applicationid used in the installOAA.properties file, when installing OAA.
   • IDENTITY_STORE_REF: <default_user_identity_store> - This value should be set to the value of the default store set in the OAM Console (User Identity Stores under Configuration). For example: OAMIDSTORE.
   • ASSURANCE_LEVEL: <assurance_level> - This value should be set to the assurance level created in OAA earlier. For example: OAM-OAA-Level. See Configuring the OAM Agent in OAA.
   • CLIENT_ID: <client_id> - This is the value of the Client ID that is copied when creating the agent. For example: 485aa420-85c0-47db-958c-04c1258e4bc2.
   • CLIENT_SECRET: <client_secret> - This is the value of the client secret that is copied when creating the agent. For example: 3bc9bc4d-ebd7-4909-bcf5-2ac7472c13db.
   • LDAP_ATTRS: mail, postalcode - These are the LDAP attributes set for the email address and to use with the Oracle Mobile Authenticator for user names stored in the LDAP server. These attributes enable the migration of user data to OAA. Entries should be in lowercase.
7. Click Save.

Creating an OAM Authentication Scheme for OAA

Create an OAM Authentication Scheme to enable the use of the OAA Authentication Module.

1. Log in to the OAM Administration Console using the http://iadadmin.example.com/oamconsole URL.
2. In the OAM console, select Application Security, select Access Manager, and then select Authentication Schemes.
3. In the Authentication Schemes tab, select Create Authentication Scheme and enter the following information:
   • Name: OAA-MFA-Scheme
   • Description: OAA MFA Authentication Scheme
   • Authentication Level: 2
   • Challenge Method: Form
   • Challenge Redirect URL: /oam/server/
   • Authentication Module: OAA-MFA-Auth-Module
   • Challenge URL: /pages/login.jsp
   • Context Type: Default
   • Context Value: /oam
   • Challenge Parameters: initial_command=NONE
4. Click Apply to save the changes.

Creating the OAM Authorization Policy

To enable protection of resources with OAA, you have to create an OAM Authorization Policy.

1. Log in to the OAM Administration Console using the http://iadadmin.example.com/oamconsole URL.
2. In the OAM Console, select the Application Security menu, select Access Manager, and then click Application Domains.
3. In the Search Application Domains window, click Search to list the available domains.
4. Select the IAM Suite domain.
5. Select the Authentication Policies tab and click Create to create a new authentication policy. Enter the following information:
   • Name: OAA_MFA-Policy
   • Authentication Scheme: OAA-MFA-Scheme

   Click Apply to save the changes.

Validating the OAM-OAA Integration

This is a simple method of validating the integration of OAM and OAA. Oracle recommends that you roll back all the steps after completing the validation.

The validation procedure comprises the following steps:

• Creating the HTML Test Page
  
• Creating an Oracle Resource for the Test Page
  
• Creating a Test User
  
• Validating the Deployment
  

Creating the HTML Test Page

Create a simple HTML test page on each Oracle HTTP server. This test page provides a simple resource that can be protected by OAA.

On the OHS Servers located in the WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/<instance_name>/htdocs directory, create a test page called test_page.html with the following content:

1. On the OHS servers located in the WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/<instance_name>/htdocs directory, create a test page called test_page.html with the following content:

   <!DOCTYPE html>
   <html>
   <body>
   
   <h1>This is a Test Page</h1>
   
   </body>
   </html>

2. Save the file and restart the Oracle HTTP servers.

Creating an Oracle Resource for the Test Page

After you create the test page, create a resource in OAM so that WebGate is aware of it and protects it using OAA.

1. Log in to the OAM Administration Console using the http://iadadmin.example.com/oamconsole URL.
2. In the OAM Console, select Access Manager and click Application Domains.
3. Click Search to view the defined application domains.
4. Click the IAM Suite domain.
5. Select the Resources tab, click Create, and enter the following information:
   • Type: HTTP
   • Description: OAA Resource
   • Host Identifier: IAMSuiteAgent
   • Resource URL: /test_page.html
   • Operations: ALL
   • Protection Level: Protected
   • Authentication Policy: OAA_MFA-Policy
   • Authorization Policy: Protected Resource Policy

   Click Apply to save the changes.

No restarts are necessary but it can take a short time for the changes to propagate.

Creating a Test User

Create a test user in Oracle Unified Directory (OUD). Assign this user to the OAA-APP-User group. The user should also have a valid email address if you want to receive One Time Pin Codes through email, and a postal code if you have configured Oracle Mobile Authenticator.

You can use the following sample ldif file to create a test user:

dn: cn=oaauser,cn=Users,dc=example,dc=com
changetype: add
objectClass: orclUserV2
objectClass: oblixorgperson
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: oblixPersonPwdPolicy
objectClass: orclAppIDUser
objectClass: orclUser
objectClass: orclIDXPerson
objectClass: top
objectClass: OIMPersonPwdPolicy
givenName: oaauser
uid: oaauser
orclIsEnabled: ENABLED
sn: oaauser
userPassword: password
mail: [e-mail]
orclSAMAccountName: oaauser
cn: oaauser
postalCode: oaauser
obpasswordchangeflag: false
ds-pwp-password-policy-dn: cn=FAPolicy,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com

dn:cn=OAA-App-User,cn=Groups,dc=example,dc=com
changetype: modify
add: uniqueMember
uniqueMember: cn=oaauser,cn=Users,dc=us,dc=oracle,dc=com

Validating the Deployment

To validate the deployment:

1. Go to https://login.example.com/test_page.html.
2. When prompted for a username and password, enter your 'oaa' test user that you created earlier. See Creating a Test User.
3. Select Email to receive the one time pin through email.
4. When prompted, enter the one time pin you received through email.
   Your test page appears.