Create the EBS application

During this task we will create the Rapid or Class EBS application.

Tasks

Create the application

  1. Sign in to the Access Gateway Admin UI console.
  2. Click the Applications tab.

  3. Click +Add to add a new application.

  4. 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 click Create.

The steps that follow vary based on whether you are creating a Classic or Rapid EBS application.

Configure the EBS SSO Agent (Rapid) application

The following steps describe how to configure an EBS Rapid Application.

  1. In the Essential pane enter:

    Field Value
    Label The name of the application, as shown in your Okta tenant.
    Public Domain The externally facing URL of the EBS application.
    For example: https://ebs-external.example.com
    Note
    This must be the same value used in the Enable EBS for Single Sign-On section, step 7.
    Protected Web Resource The URL and port combination of the Oracle EBS Implementation being protected.
    For example: http://ebs-internal.example.com:8000/
    Note: 
    Always end the protected resource URL with a forward slash (/).
    See also Configure load balancing.
    Post Login URL

    URL of the EBS server:
    https://ebs-internal.example.com:8000/OA_HTML/OA.js?OAFunc=OAHOMEPAGE
    Note: This must be the hostname and port of the back end EBS server and not the external name used in Public Domain.

    Group The group containing users who can access the EBS instance.
  2. While optional, Okta recommends that all applications include certificates.
    See About Access Gateway certificate use for general information about certificate.
    See Certificate management tasks for a general task flow for obtaining and assigning certificates.  

  3. Expand the Certificates tab.

    By default a wildcard self signed certificate is created and assigned to the application when the application is initially created.

  4. Optional. Click Generate self-signed certificate

    A self-signed certificate is created and automatically assigned to the application.
  5. Optional. Select an existing certificate from the list of provided certificates.
    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 of available certificates.

  6. Click Next.The Application Configuration pane displays.

  7. In the Application configuration pane enter/verify:

    Field Value
    EBS Service Account The EBS username from the configuration section.
    In this example, OAGSSOUSER.
    EBS Service Account Password Password associated with EBS Service Account.
    EBS User Identified Either USER_NAME or EMAIL_ADDRESS.
    DBC File Contents DBC file contents as provided by the Oracle EBS Administrator or the value from section Register Okta Access Gateway With Oracle E-Business Suite.
  8. Click Not validated when complete.

    If all values are entered correctly, the Not Validated button will change to Validated.
  9. Click Next
  10. In the Attributes tab verify the following three attributes:

    See Application attributes for detailed information on the attribute options.

    Data Source Field Type Name
    IDP User profile field that represents the EBS user name. It can be data static and a fixed value for testing. EBS only supports user name values in upper case. Header EBS_USER
    static Auth Context Header REMOTE_IP
    static Auth Context Header SESSION_ID
  11. Click Done when complete.

 

Configure the EBS R12.1 or R12.2 (classic) application

The following steps describe how to create an EBS Classic application.

  1. In the Essentials pane enter:

    Field Value
    Label The name of the application as shown in your Okta tenant.
    Public Domain The externally facing URL of the EBS application.
    For example: https://ebs-external.example.com
    Protected Web Resource

    The URL and port combination of the Oracle EBS Implementation being protected.
    For example: http://ebs-internal.example.com:8000/

    Note: Always end the protected resource URL with a forward slash (/).
    See also Configure load balancing.

    Post Login URL Browseable route-through location to pick up the required EBS cookie from Okta Access Gateway and pass along to the Oracle EBS implementation.
    For example https://ebs-external.external/accessgate/dossologin
    Group The group containing users who can access the EBS instance.
  2. While optional, Okta recommends that all applications include certificates.
    See About Access Gateway certificate use for general information about certificate.
    See Certificate management tasks for a general task flow for obtaining and assigning certificates.  

  3. Expand the Certificates tab.

    By default a wildcard self signed certificate is created and assigned to the application when the application is initially created.

  4. Optional. Click Generate self-signed certificate

    A self-signed certificate is created and automatically assigned to the application.
  5. Optional. Select an existing certificate from the list of provided certificates.
    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 of available certificates.

  6. Click Next. The Application Configuration pane displays.

  7. In the Application Configuration pane enter:

    Field Value
    Access Gate URL The EBS URL matching the protected resource in the prior step using port 6801.
    For example: http://ebs-accessgate.example.com:6801

    OID Datasource Enabled.
    OID Host Fully qualified host name of the OID Host.
    For example: ebs-oid.example.com
    OID Port Port for the OID Host, typically 3060.
    User Search Attribute CN
    Matching Attribute EBSUSER,
  8. Click Next when complete. The Attributes pane will display.
  9. In the Attributes tab verify the following two attributes:

    See Application attributes for detailed information on the attribute options.

    Data Source Field Type Name
    IDP cn Header USER_NAME
    oid orclguid Header USER_ORCLGUID

Configure load balancing

Available since Access Gateway version 2022.2.3

Okta recommends that whenever possible load balancers and Access Gateway as a load balancer be implemented.
See About Access Gateway load balancing.

  1. Expand the Protected Web Resources tab.
  2. In Protected Web Resource tab enable load balancing.
    The Protected Web Resource showing load balancing enabled for this web resource.
    The Protected Web Resource tab will then expand to include a table of hostnames and weights representing the target load balancing instances, initially empty.
  3. Select a URL scheme. All added protected web resources will inherit this scheme. HTTP and HTTPS schemes are supported.
  4. [Optional] Enable and specify Host Header value.
  5. Repeat as required:
    1. Click Add protected web resource.
      A new empty row will be added to the table.
    2. Enter a fully qualified hostname:port combination.
      For example https://backendserver1.atko.com:7001.
    3. Enter a weight between 1 and 100. Enter 0 to specify a disabled host.

      Weights represent the percentage of requests that will be routed to this host.
      For example, two hosts of weights 2:1 would result in requests being routed ~66% to the host weighted 2 and ~33% to the host weighted 1.

    4. Click Okay to add the new host, or Cancel to cancel.
      Click edit () to modify an existing host.
      Click delete() to delete an existing host.
  6. Optional Configure health checks:
    Health checks are optional and use GET operations to confirm back and resources are functional.
    Resources deemed unhealthy are not routed new requests.

    1. Enable health checks.
      The health check slider shown in the enabled position.
    2. Click Edit to modify health check settings.
    3. Modify settings as required.
      FieldValue

      Default

      PathURI to resource used in health check./
      MethodHTTP method used.Always GET
      Status codeHTTP status code used to determine health.200
      IntervalInterval between health checks in seconds.10
      Request timeoutHealth check request timeout in seconds.1
      Healthy thresholdNumber of successful requests before a host is considered healthy.3
      Unhealthy thresholdNumber of failed requests before a host is considered unhealthy.3
    4. Click Save to save changes.
      Click Cancel to cancel changes.