About Enterprise Applications

Enterprise applications are web applications that require App Gateway to integrate with Oracle Identity Cloud Service for authentication and authorization purposes.

Enterprise applications work similarly to confidential applications if you configure the Client Configuration and Resource Server Configurations section under OAuth Configuration tab.

To configure an enterprise application to work with App Gateway for authentication and authorization purposes you need to know the following information about your web application:

  • The web application's base URL. For example, if a known URL of your application is http://myapp.internal.example.com:3266/myapp/private/home, then the base URL is http://myapp.internal.example.com:3266.

  • The list of resources of your web application. For example, if your web application exposes the following URLs: functionalities A to Z in the following format /myapp/private/funcA to /myapp/private/funcZ, a home page /myapp/private/home, a logout URL /myapp/logout, an about page myapp/public/about, and an index page /myapp/index, then the list of all resources of your web application is:

    • URLs from /myapp/private/funcA to /myapp/private/funcZ
    • /myapp/private/home
    • /myapp/logout
    • /myapp/public/about
    • /myapp/index
  • For each resource, define which resources require the user to be authenticated, which don't require user authentication, and which resource represents the log out action. Below are examples of authenticated and non-authenticated resources:

    • Resources from /myapp/private/funcA to /myapp/private/funcZ, and /myapp/private/home require the user to be authenticated.
    • /myapp/logout logs the user out.
    • Both myapp/public/about and /myapp/index are public resources and don't require the user to be authenticated.
  • For each resource, define who can access which resource and which HTTP Method will be allowed or denied access. For example, you can define that all members of group Employees are allowed access to make GET and POST HTTP requests to resource /myapp/private/home, only members of group MyGroupA can access /myapp/private/funcA, and only users accessing from within network perimeter IntranetIPs can access resources from /myapp/private/funcB to /myapp/private/funcZ.

  • Identify URL patterns that apply to your list of resources. In the previous example, the URL pattern /myapp/private/.* matches all the application's functionality URLs and the home page URL. All these URLs may require the same kind of authentication.

Add an Enterprise Application

An enterprise application enables you to secure web applications that are protected by the Oracle App Gateway.

To add an enterprise application in Oracle Identity Cloud Service, you need to configure the list of application resources (web application's URLs or URL patterns), create an authentication policy for each resource, and create an authorization policy for each resource. For each authentication policy, you define an authentication method, and header variables for App Gateway to include in the request before forwarding the request to the application.

For each authorization policy, you define

  1. Sign into the Identity Cloud Service console as an application administrator.
  2. Expand the Navigation Drawer, click Applications, and then click Add.
  3. In the Add Application page, click Enterprise Application.
  4. In the Details pane of the Add Enterprise Application page, provide a name for the application, enter the application URL, complete all other fields as necessary, and then click the Next > icon.

    Note:

    The application URL is the URL that you want users to use to access your enterprise application. Use the host name and port number of the App Gateway. If you have multiple instances of App Gateway, then use the host name and port number of the load balancer.
  5. In the OAuth Configuration pane, click the Next > icon.
    Use the OAuth Configuration pane to configure the enterprise application to act as a confidential application by providing client and resource server configurations.
  6. In the SSO Configuration pane, click Finish.
    You configure the Resources, Authentication Policy and Authorization Policy sections under the SSO Configuration pane later.
  7. Click Activate, and then click OK in the Confirmation widow to activate the application.

Configure Resources

You can create resources individually by adding one resource for each of your application's URLs, or use regular expression to create a resource which represents a collection of URLs for your application.

A resource represents a URL or URL Pattern for which you want to restrict access or intend to gvie anyone to access. You need the list of resources of your application. See About Enterprise Applications
  1. In the Application Details page, click the SSO Configuration tab of your enterprise application page, expand the Resources section, and then click Add to add a resource.
  2. In the Add Resource dialog, provide a name for the resource and the resource URL. If you want to use a regular expression as the resource URL value, then select Regex, so that App Gateway evaluates the Resource URL value as a pattern.

    For example, if you want to protect the application endpoint http://myapp.internal.example.com:3266/private/home, you can enter /private/home as the value for Resource URL. If you want to protect any page under the /private context, then enter /private/.* as value for Resource URL, and select Regex.

    See Use Regular Expressions.

Configure an Authentication Policy

Create an authentication policy for each resource you created for your enterprise application.

An authentication policy defines which authentication method to use to protect your enterprise application's resources, and whether App Gateway will add header variables to the request it forwards to the application.
  1. In the SSO Configuration tab of your enterprise application page, expand the Authentication Policy section, and then click Add under Managed Resources.
  2. In the Add Resource window, select the resource for which you want to configure an authentication policy from the list of resources that you created in the Resources section.
  3. Use the following table to define the Authentication Method for the resource you have selected:

    Table 5-1 Authentication Methods

    Authentication Method Description

    Basic Auth

    The Basic Auth method performs HTTP Basic authentication. If the request doesn't contain an Authentication Basic header, then user's browser will prompt for credentials.

    The credentials sent in the Authentication Basic header is validated in Oracle Identity Cloud Service.

    Basic Auth+Logout

    This method is used to protect the application's resource (URL) that represents the application's log out process.

    When App Gateway intercepts a request to this resource, the HTTP logout process is initiated. This process deletes any HTTP session cookie created by the Basic Auth+Session authentication method.

    After the logout process finishes, App Gateway forwards the user browser to the requested application's resource.

    Note that the HTTP logout process doesn't clear any credentials cached by the browser in the current browser session and then the user may not be prompted again for later requests.

    Basic Auth+Session

    Works the same as Basic Auth. After the credential is validated, it creates an HTTP session cookie (ORA_OCIS_CG_BA_SESSION).

    Form or Access Token

    In this authentication method, App Gateway delegates credentials collection and validation to Oracle Identity Cloud Service.

    If an Authorization Bearer header is present in the request, then the authentication is similar to a resource server flow. If a user-agent header is present, then a user browser flow takes place.

    The user browser flow redirects the user browser to Oracle Identity Cloud Service for credentials collection and validation, and then creates an OAuth session cookie (ORA_OCIS_CG_SESSION_*).

    If an Authorization session header is present in the request and the OAuth session cookie is missing or invalid, then the usual OAuth login flow is suppressed and a 401 HTTP error code will be returned along with a WWW-Authenticate: Bearer error="invalid_session" header. This is used by applications that may trigger an unwanted login when their requests contain a user-agent header, but not an Authorization Bearer header, allowing them to handle re-authentication themselves.

    Form+Logout

    This method is used to protect the application's resource (URL) that represents the application's log out process.

    This resource's URL doesn't need to be exposed by the application, as App Gateway redirects the user browser to Oracle Identity Cloud Service's OAuth logout endpoint (/oauth2/v1/userlogout), instead of forwarding the request to the application URL.

    In the Add Resource window, the Post-Logout URL is the URL which App Gateway redirects the user browser after signing the user out. You can also provide a Post-Logout State parameter value to be used by the post-logout URL page of the application.

    Multitoken

    Performs authentication based on the contents of the Authorization header of the request:

    • If the request contains an Authorization Basic header, then App Gateway handles this authentication as Basic Auth.
    • If the request contains an Authorization Bearer or Authorization Session header, App Gateway handles this authentication as Form or Access Token.
    • If the Authorization header is missing or has any other value, then a 401 Unauthoized HTTP error is returned.

    Multitoken+Fallthrough

    Same as Multitoken, but if the Authorization header is not Basic, Bearer, or session, then instead of presenting the 401 Unauthoized HTTP error, request App Gateway acts as authentication method was Basic Auth.

    Anonymous

    • If a valid OAuth session cookie is present, then the headers configured in the authentication policy are added to the request and the request is forwarded to the application.
    • If the OAuth session cookie is missing or expired, works the same as the Public authentication method. In this case, a REMOTE_USER header with value anonymous is added to the request.

    For both options, the headers configured in the authentication policy are added to the request, but authentication is not performed.

    Public

    No authentication is performed. The request is forwarded to the application as is.

    Unsupported

    This method always returns 500 Not Supported HTTP error code.

    For example, you can use this method to disable access to a protected URL that is available in the application but you don't want users to access it.

  4. The authentication method you selected in the previous step is valid for all HTTP Methods (GET, HEAD, DELETE, PUT, OPTIONS, CONNECT, POST, or PATCH). If you want to specify different authentication methods for HTTP methods (for example, the Form + Access Token authentication method for the GET HTTP method and the Multitoken authentication method for the POST HTTP method), then you can do so by using the Authentication Method Overrides menu. Select the HTTP Method, and then the Authentication Method you want. If you need to override more than one HTTP method, then repeat this step multiple times.
  5. If you want to add an header variable to the request so that App Gateway forwards it to the application, click the plus + icon for Headers, provide the name, and then either select the value for the header variable from the list of user attributes, enter a fixed value, or provide an expression. To add more than one header variable, click the + icon for Headers multiple times.

    For example, let's suppose the application requires a header variable named USERLOGGEDIN to be present in every request so that the applications knows the ID of user signed in to Oracle Identity Cloud Service. You need to add one header variable, enter USERLOGGEDIN for the Name field, and then either select User Name from the drop down list or enter $subject.user.userName for Value.

    Note:

    You can select a user attribute from the drop down menu or provide an expression using any attribute from Oracle Identity Cloud Service's SCIM user schema as header variable value. See Supported Header Value Expressions for Authentication Policies.

    In the Configure Authentication Policy for this application section, if App Gateway is configured in SSL mode (HTTPs), then confirm that Require Secure Cookies is selected. This flag sets the secure header to avoid cookies being used in non-secure HTTP communication. If App Gateway is configured in non-SSL mode (HTTP), then deselect Require Secure Cookies.

    For security reasons, make sure the Disable Audience Validation check box isn't selected. The audience validation check box is used to ensure the token has been issued by App Gateway's known issuer, in this case Oracle Identity Cloud Service. If you disable audience validation, App Gateway won't validate the audience of the token, which makes the application vulnerable to attacks.

Configure an Authorization Policy

Create an authorization policy for each resource in your enterprise application and define the conditions in which users are allowed or denied access to the resource.

Note:

Authorization policies only work for resources that you protect with Form or Access Token authentication method in an authentication policy. If your resource is protected with any other authentication method, App Gateway doesn't perform authorization check when users try to access the resource using a web browser.

Note:

Although the Authorization Policy section appears during enterprise application configuration, the ability for App Gateway and Oracle Identity Cloud Service to validate authorization is in early access. To enable this feature, file a Service Request with My Oracle Support. If you don't file a Service Request, your App Gateway won't perform authorization verification despite you having configured the Authorization Policy section.

Create a Service Request with Oracle Support. Use Enable Authorization Policy in Enterprise App for Oracle Identity Cloud Service for the title of your Service Request and include the information that the support note requires for you to provide.

Authorization policies define under what conditions users are allowed or denied access to application resources. When App Gateway intercepts an HTTP request to a resource endpoint, App Gateway verifies whether the enterprise application in Oracle Identity Cloud Service contains authorization policies for the resource. If so, then App Gateway verifies whether the HTTP request matches one of the rules configured to allow or deny access.

For example, you can configure an allow rule to allow all members of the Employees group to access the /myapp/private/home resource, and configure a deny rule to deny access to this resource for users authenticated by the My External SAML IDP identity provider.
  1. In the SSO Configuration tab of your enterprise application page, expand the Authorization Policy section.
  2. In the Allow Rules section, click Add, specify a Rule Name, and then complete the following fields.

    Table 5-2 Add Allow Rule Options

    Conditions Description

    If the resource is

    Select one of the resources configured in the enterprise application.

    And the HTTP Method is

    Select the HTTP Methods associated with this rule. The rule will be valid only for the selected HTTP Methods.

    And if the user is authenticated by

    Select the identity providers that are active in Oracle Identity Cloud Service. If the user is signed in using one of these identity providers, then App Gateway allows access to the resource. Local IDP refers to users authenticated by Oracle Identity Cloud Service.

    And is a member of these groups

    Select Oracle Identity Cloud Service's groups. If the signed in user is a member of one of the selected groups, then App Gateway allows access to the resource.

    And is not one of these users

    Select Oracle Identity Cloud Service users. If the signed in user is not one of the selected users, then App Gateway allows access to the resource.

    And the user's client IP address is

    Select the IP address range the HTTP request are made from.

    • Anywhere: App Gateway doesn't validate the IP address from where the HTTP request was made.
    • In one or more of these network perimeters: Select this option, and then select the network perimeters associated with this rule. If the IP address from where the HTTP request was made is specified in one of the network perimeters, then Access Gateway allows access to the resource.

    And access is

    Select a time of the day (From and To), select which days of the week, and then the timezone in which the rule is valid.

    App Gateway allows access to the resource only if the HTTP Request is made within the period configured.

    All the conditions configured for an allow rule must be met so that App Gateway can perform the action configured for the rule.
  3. In the Actions section of the Add Allow Rule window, click Add for Headers, enter name for the HTTP header and then select a user attribute as value. Repeat this step for all headers you want to configure for this rule.
    If the user is allowed access to the resource, App Gateway adds these header variables with the corresponding values to the HTTP request before forwarding the request to the application.
  4. Click Add to add the allow rule.
  5. In the Deny Rules section, click Add Deny Rule, specify a Rule Name, and then complete the following fields.

    Table 5-3 Add Deny Rule Options

    Conditions Description

    If the resource is

    Select one of the resources configured for the enterprise application.

    And the HTTP Method is

    Select the HTTP Methods to associate with this rule.

    And if the user is authenticated by

    Select identity providers that are active in Oracle Identity Cloud Service. If the user is signed in using one of these identity providers, then App Gateway denies access to the resource. Local IDP refers to users authenticated by Oracle Identity Cloud Service.

    And is a member of these groups

    Select Oracle Identity Cloud Service groups. If the signed in user is member of one of the selected groups, then App Gateway denies access to the resource.

    And is not one of these users

    Select the Oracle Identity Cloud Service users. If the signed in user is not one of the selected users, then App Gateway denies access to the resource.

    And the user's client IP address is

    Select the IP address range the HTTP request are made from.

    • Anywhere: App Gateway doesn't validate the IP address from where the HTTP request was made.
    • In one or more of these network perimeters: Select this option, and then select the network perimeters to associate with this rule. If the IP address from where the HTTP request was made is specified as one of the network perimeters, then Access Gateway denies access to the resource.

    And access is

    Select a time of the day (From and To), select which days of the week, and then the timezone in which the rule is valid.

    App Gateway denies access to the resource if the HTTP Request is made within the period configured.

    All the conditions configured for a deny rule must be met so that App Gateway can perform the action configured for the rule.
  6. In the Actions section of the Add Deny Rule window, select the action App Gateway must perform when a deny rule condition matches the resource's HTTP request.
    • None: App Gateway redirects the user browser to the URL you've set in the Custom Error URL parameter of the enterprise application. If this parameter has no value, then App Gateway redirects the user browser to the URL set in the Error URL parameter of the Session Settings.
    • Logout: Logs the user out from Oracle Identity Cloud Service.
  7. Click Add to add the deny rule.
  8. In the Settings section, select Time to live in minutes to define for how long App Gateway caches any authorization policy evaluation that has been performed.
    By caching these policy evaluation, App Gateway doesn't need to communicate with Oracle Identity Cloud Service in subsequent HTTP request made by the user for the same resource.

Use Regular Expressions

Use regular expressions (regex) to define a URL pattern which represents more than one URL of your enterprise application and for which you can apply the same authentication policy and the same authorization policy.

Create a list of all URLs for your application, and then to define URL patterns that map similar URLs, in which you want to define common authentication and authorization policies.

The authorization engine of App Gateway supports all tokens available to create regular expressions, such as Character Classes, Anchors, Escaped Characters, Group & References, Lookaround, Quantifiers & Alternation, and Substitution.

Below is a list of common operators supported by App Gateway's authorization engine:

Table 5-4 Common Regex Operators Supported by App Gateway Authorization Engine

Operator Description Example
Match-any-character Operator (.) The period character represents this operator. a.b matches any three-character string beginning with a and ending with b
Match-zero-or-more Operator (*) This operator repeats the smallest possible preceding regular expression as many times as necessary (including zero) to match the pattern a* matches any string made up of zero or more a's. In another example, fo* has a repeating o, not a repeating fo. Hence, fo* matches f, fo, foo, and so on.
Match-one-or-more Operator (+) This operator is similar to the match-zero-or-more operator except that it repeats the preceding regular expression at least once. ca+r matches car and caaaar, but not cr
Match-zero-or-one Operator (?) This operator is similar to the match-zero-or-more operator except that it repeats the preceding regular expression once or not at all. ca?r matches both car and cr, but nothing else.
Negate (^) Negate an expression. ^a matches any character except a
Grouping Operators ((...)) Regex treats expressions inside the parenthesis just as mathematics and programming languages treat a parenthesized expression as a unit. The expressions are processed before the expression outside the parenthesis. f(a|b)a matches faa and fba, which means the operation a|b is processed before the rest.
Alternation Operator (|) Alternatives match one of a choice of regular expressions: if you put the character(s) representing the alternation operator between any two regular expressions a and b, the result matches the union of the strings that a and b match.

foo|bar|quux would match any of foo, bar or quux

As another example, ( and ) are the open and close-group operators, then fo(o|b)ar would match either fooar or fobar. On the other hand, foo|bar would match foo or bar

List Operators ([ ... ] and [^ ... ])

A matching list matches a single character represented by one of the list items. An item is a character, a character class expression, or a range expression.

Non matching lists are similar to matching lists except that they match a single character not represented by one of the list items.

[ab] matches either a or b. [ad]* matches the empty string and any string composed of just a's and d's in any order.

As a non matching example, [^ab] matches any character except a or b

Range Operator (-) Represents those characters that fall between two elements in the current collating sequence. [a-f] represents all the characters from a through f inclusively.
Digit (\d) Matches any digit character (0-9). Same as [0-9]
Not Digit (\D) Matches any character that is not a digit character (0-9). Same as [^0-9]
Escape (\) Makes the next character in the expression means the character itself but not an operator. \. means period, not the Match-any-character operator.

Example 5-1 Use of Regular Expression

For example, if you want to allow only authenticated users access for any page of the application that starts with my and are under the path /mybank, then you can use the regular expression /mybank/my.*

The dot (.) and the star (*) together represents any sequence of zero or more consecutive characters after the prefix my.

In this example, the URLs /mybank/myCredits and /mybank/myDebits match the /mybank/my.* pattern, but /mybank/about doesn't.

Supported Header Value Expressions for Authentication Policies

When you configure enterprise application's authentication policies, you can add header variables to requests forwarded to the application, by selecting a user attribute from a list of pre defined user attributes, or by entering an expression.

In the header Value field for Authentication Policies, you can provide a simple literal string or an attribute identifier instead of selecting the user attribute from the drop down list. If you use an attribute identifier, App Gateway attempts to replace the attribute identifier by the value of the attribute after authentication happens.

The following types of attribute identifiers are supported by authentication policies:

  • Application: This attribute identifier accesses the information of the enterprise application registered in Oracle Identity Cloud Service.

    Format: $subject.client.<attr>

  • User: This attribute identifier accesses information of the user signed in to Oracle Identity Cloud Service.

    Format: $subject.user.<attr>

  • Request: This attribute identifier accesses request information.

    Format: $request.<attr>

For user attribute scope, App Gateway supports any simple top-level attribute in the JSON Response from /admin/v1/Users such as string, boolean, or int values.

App Gateway also supports user extension attributes as header value expressions for authentication policies, using the following format $subject.user.urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:<attributeName>, and custom attributes using the following format $subject.user.urn:ietf:params:scim:schemas:idcs:extension:custom:User:<customAttributeName>

Table 5-5 Example of User Attribute Scope Names and Return Values

Attribute Name Header Value Expression Description

Full Name

$subject.user.name

The user's full name.

User Name

$subject.user.userName

The user's login username.

Emails

$subject.user.emails

Other types of emails also supported: $subject.user.emails.recovery, $subject.user.emails.other, $subject.user.emails.home, and $subject.user.emails.work.

The user's primary email address.

Phone Numbers

$subject.user.phoneNumbers

Other types of phone numbers supported: $subject.user.phoneNumbers.mobile, $subject.user.phoneNumbers.home, and $subject.user.phoneNumbers.work.

The user's phone number.

Addresses

$subject.user.addresses

The user's mailing address.

Groups

$subject.user.groups

A list of comma-separated group names to which the user is assigned to through direct or indirect membership.

idcsCreatedBy

$subject.user.idcsCreatedBy

The display name of the user or application who created this resource.

idcsLastModifiedBy

$subject.user.idcsLastModifiedBy

The display name of the user or application who modified this resource.

Department

$subject.user.urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department

The user's department.

Employee Number

$subject.user.urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber

The user's employee number.

Example of supported values for request attribute scope:

Table 5-6 Example of Request Attribute scope names and supported values

Attribute Name Header Value Expression Description

policy_appname

$request.policy_appname

Returns the name of the enterprise application registered in Oracle Identity Cloud Service.

policy_name

$request.policy_name

Returns the policy name of the specific policy matched for the request.

policy_res

$request.policy_res

Returns the resource URL pattern matched for the request. The format is: "<type>:<pattern>"

Example: text:/my/resource or regex:/my/resource/.*

policy_action

$request.policy_action

Returns the HTTP Method (GET, POST, etc) used to access the requested resource.

res_host

$request.res_host

Returns the host name from the original Request.

res_port

$request.res_port

Returns the port number from the original Request.

res_type

$request.res_type

Returns the protocol (HTTP or HTTPS) of the original Request.

res_url

$request.res_url

Returns the full requested URL.

Default Headers and Cookies App Gateway Adds to the Request

By Default App Gateway adds header variables and cookies to any request forwarded to a protected enterprise applications. The following is a list of these headers and cookies and their respective values.

Headers

Header Name Description Authentication Method Usage
idcs_service_url

The value of this header is your Oracle Identity Cloud Service's base URL.

For example, https://idcs-tenant.identity.oraclecloud.com

Used by all authentication method.

idcs_cloudgate_id

The Client ID value for the App Gateway registered in Oracle Identity Cloud Service.

Used by all authentication method.

idcs_client_id

The Client ID value for the App Gateway registered in Oracle Identity Cloud Service.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by Anonymous or Public authentication methods.

idcs_authn_method

The authentication method configured in the enterprise application's authentication policy.

Value depending on the authentication method used:
  • If resource is protected by Anonymous authentication method, then value is anonymous.
  • If resource is protected by Form or Access Token authentication method, then value is oauth.
  • If resource is protected by Basic Auth or Basic Auth+ Session authentication methods, then value is http.
  • If resource is protected by Multitoken authentication method, then value is multitoken.
  • If resource is protected by Multitoken+Fallthrough authentication method, then value is multitoken or fallthrough depending if the authorization header is a known value or not.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by any authentication method except Public.

idcs_authn_strength

Identifies if the user authentication has happened in 1 or 2 steps.

If the user has signed in with Oracle Identity Cloud Service using their credentials only, then the authentication strenght is 1. If the user has signed in using multi-factor authentication, then authentication level is 2.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by any authentication method except Public and Anonymous.

remote_user

Username of the user signed in to Oracle Identity Cloud Service.

If the resource is protected by Anonymous authentication method, then the value of this header is anonymous.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by any authentication method except Public.

idcs_remote_user

Username of the user signed in to Oracle Identity Cloud Service.

If the resource is protected by Anonymous authentication method, then the value of this header is anonymous.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by any authentication method except Public.

idcs_remote_user_mappingattr

The Oracle Identity Cloud Service user schema attribute used to identify the signed in user.

For example, userName.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by any authentication method except Public and Anonymous.

idcs_session_id

The session ID value Oracle Identity Cloud Service creates after user signs in.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by Form or Access Token or Basic Auth+ Session authentication method.

idcs_user_assertion

Value of the identity token issued by Oracle Identity Cloud Service.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by Form or Access Token authentication method.

idcs_user_display_name

Value of the displayname attribute of the user signed in with Oracle Identity Cloud Service.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by any authentication method except Public and Anonymous.

idcs_user_id

Value of the unique identifier attribute of the user signed in with Oracle Identity Cloud Service.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by any authentication method except Public and Anonymous.

idcs_user_tenant_name

Oracle Identity Cloud Service tenant name.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by any authentication method except Public and Anonymous.

Cookies

Cookie Name Description Authentication Method Usage
ORA_OCIS_CG_SESSION_<idcs-tenant>_<aapgateway_host>

After the user authenticates with Oracle Identity Cloud Service, App Gateway sets this cookie to the request forwared to the application.

The cookie name is composed by ORA_OCIS_CG_SESSION prefix, concatenated with Oracle Identity Cloud Service's tenant name, and sufixed with the App Gateway's Host value.

App Gateway adds this header to the request forwarded to the enterprise application if the resource is protected by Form or Access Token authentication method.