Create the Rapid or Classic EBS app
This topic describes how to create the Rapid or Classic EBS app.
Create the app
- Sign in to the Access Gateway Admin UI console.
- Click the Applications tab.
- Click +Add.
- Select one of Oracle EBS R12.1,Oracle EBS R12.2 (for classic) or Oracle EBS SSO Agent (for rapid) from the left column menu, and then click Create.
The steps that follow vary depending on whether you're creating a Classic or Rapid EBS app.
Configure the EBS SSO Agent (Rapid) app
-
In the Essential pane, configure these options:
Field Value Label The name of the app as shown in your Okta org. Public Domain The externally facing URL of the EBS app. Use the same value that you entered in step 7 of Enable Oracle E-Business Suite for single sign-on.
For example: https://ebs-external.example.com.
Protected Web Resource The URL and port combination of the Oracle EBS Implementation that you're protecting. Always end the protected resource URL with a forward slash (/). For example: http://ebs-internal.example.com:8000/. Post Login URL The URL of the EBS server. This must be the host name and port of the back-end EBS server and not the external name used in Public Domain. For example: https://ebs-internal.example.com:8000/OA_HTML/OA.jsp?OAFunc=OAHOMEPAGE.
Group The group containing users who can access the EBS instance. All apps, including the Access Gateway Admin UI console app, require a self-signed or signed certificate.
Include signed certificates wherever you terminate SSL. You can terminate SSL at Access Gateway or any other network component, like a load balancer.
If you terminate SSL at a load balancer, on the Access Gateway Admin UI console app, you also need to use a certificate that is trusted by the load balancer.
If you terminate SSL on the Access Gateway Admin UI console app, you must use a signed certificate, which must be on the Access Gateway node and be associated with the Access Gateway Admin UI console app.
- See Certificate use for details about certificates.
- See Certificate management for a task flow for obtaining and assigning certificates.
- Expand the Certificates tab.
By default, when you create the app, the system generates a self-signed wildcard certificate and assigns it to the app.
- Optional. Click Generate self-signed certificate. A self-signed certificate is created and automatically assigned to the app.
- Optional. Select an existing certificate from the list. Use the Search field to narrow the set of certificates by common name. Use the page forward and backward arrows to navigate through the list.
-
Click Next. The Application Configuration pane appears.
-
In the Application configuration pane, enter these values:
Field Value EBS Service Account The EBS username from the configuration section. For example, OAGSSOUSER.
EBS Service Account Password The password associated with the EBS Service Account. EBS User Identified Enter either USER_NAME or EMAIL_ADDRESS. DBC File Contents The DBC file contents as provided by the Oracle EBS Administrator or the value from the Register Okta Access Gateway With Oracle E-Business Suite section. - Click Not validated when complete. If all values are entered correctly, the Not Validated button changes to Validated.
- Click Next.
-
In the Attributes tab, verify these attributes:
Data Source Field Type Name IDP The user profile field that represents the EBS username. It can be data-static and a fixed value for testing. EBS only supports username values in upper case. Header EBS_USER static Auth Context Header REMOTE_IP static Auth Context Header SESSION_ID See App attributes.
- Click Done.
Create the EBS R12.1 or R12.2 (classic) app
-
In the Essentials pane, configure these options:
Field Value Label The name of the app as shown in your Okta org. Public Domain The externally facing URL of the EBS app. For example, https://ebs-external.example.com.
Protected Web Resource The URL and port combination of the Oracle EBS Implementation that you're protecting. Always end the protected resource URL with a forward slash (/). For example: http://ebs-internal.example.com:8000/.
Post Login URL The browsable route-through location to pick up the required EBS cookie from Okta Access Gateway and pass to the Oracle EBS implementation. For example, https://ebs-external.external/accessgate/dossologin.
Group The group containing users who can access the EBS instance. All apps, including the Access Gateway Admin UI console app, require a self-signed or signed certificate.
Include signed certificates wherever you terminate SSL. You can terminate SSL at Access Gateway or any other network component, like a load balancer.
If you terminate SSL at a load balancer, on the Access Gateway Admin UI console app, you also need to use a certificate that is trusted by the load balancer.
If you terminate SSL on the Access Gateway Admin UI console app, you must use a signed certificate, which must be on the Access Gateway node and be associated with the Access Gateway Admin UI console app.
- See Certificate use for details about certificates.
- See Certificate management for a task flow for obtaining and assigning certificates.
-
Click Next. The Application Configuration pane appears.
-
In the Application Configuration pane, configure these options:
Field Value Access Gate URL The EBS URL that matches the protected resource, using port 6801.
For example: http://ebs-accessgate.example.com:6801.OID Datasource Enable this option. OID Host The fully qualified host name of the OID Host. For example: ebs-oid.example.com. OID Port The port for the OID host, typically 3060. User Search Attribute Select CN. Matching Attribute Select EBSUSER. - Click Next when complete. The Attributes pane appears.
-
In the Attributes tab verify these attributes:
Data Source Field Type Name IDP cn Header USER_NAME oid orclguid Header USER_ORCLGUID See App attributes.
Configure load balancing
Only use Access Gateway as the load balancer. See Load balancing.
- Expand the Protected Web Resource tab.
- Enable Load Balancing By Access Gateway. A table of hostnames and weights representing the target load-balancing instances appears. This table is initially empty. Click the Edit
icon to modify an entry in the table, or click the Delete
icon to delete an entry.
- Choose either HTTP or HTTPS as the URL scheme. Each protected web resource that you add inherits this scheme.
- Optional. Enable and enter the Host Header value.
- Complete the following steps to add a host. Repeat these steps as required:
- Click Add protected web resource.
- Enter a fully qualified hostname:port combination, like for example, https://backendserver1.atko.com:7001.
- Enter a weight from 1 to 100. Enter 0 to specify that a host is disabled.
Weights represent the percentage of requests that are routed to this host. For example, two hosts of weights 2:1 result in requests being routed approximately 66% to the host weighted 2 and approximately 33% to the host weighted 1.
- Click Okay.
-
Optional. Configure health checks. They use GET operations to confirm that back-end resources are functional. New requests aren't routed to resources that have been labeled unhealthy by the health checks.
- Enable Load Balancer Health Check.
- Click Edit to modify health check settings.
- Modify the settings as required.
Field Value Default
Path The URI path to the resource used in the health check. / Method The HTTP method used in the health check. Always GET Status code The HTTP status code used to determine health. 200 Interval The interval between health checks in seconds. 10 Request timeout The health check request timeout in seconds. 1 Healthy threshold The number of requests that must succeed before a host is considered healthy. 3 Unhealthy threshold The number of requests that must fail before a host is considered unhealthy. 3 - Click Save.