Application Attributes


The purpose of guide is to describe Access Gateway attributes, how they are managed, used, and general characteristics.

Using Attributes

Application Attributes can be used to:

  • Convey information to the underlying protected resource. For example to send username, requested URL, or other appropriate information using headers or cookies.
  • Provide information for policy decisions - For example to determine whether a given user has the rights to access a given page or other portion of a protected application. See Application Policy Overview for more information on application policy.

Attributes Operations

For a given application, attributes may be:

Attributes Elements

Application attributes are defined using the following fields:

Field Description
Send Flag Controls whether an attribute is present or not present within a header or cookie.
Attributes used for policy decisions ate typically set to Don't Send.

Datasource Originating source for the contents of the attribute.  Can be any of a number of sources including idPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta., various contexts, Data Stores and others.
See Administer DataStores for details on adding external data stores which can be used as attribute sources.

Field and Record Number

Either Field and Record Number, of Value.
For static and secret attributes, the value field represents a fixed value for the attribute.

For non-static fields Field used as the source for the attribute.

Record Number is only present with non-static fields. and represents which of a multi-value variable will be selected. Record Value can be one of:

  • n: Where n represents the specific record number in the input. Default, value 0.
  • #: return the total number of records in the input.
  • @: Concatenate all values, using :(colon) as separator.
    For example ":value1:value2:value3:"

Maximum length: 128 characters.


Method for passing attributes. Can be one of:

  • Header: Attribute will be passed in a header.

  • Cookie: Attribute will be passed in a cookie.


Associated field in either the header or cookie.
Maximum length: 128 characters.

Undestanding Datasources

  • DataSource: The Data Source field defines the source for the value of the attribute. The following sources are available:

    Data Source Description
    IDP The value of the is populated from the IDP field selected in the Value field.
    Static The value of the attribute is fixed and defined in the Value field
    Secret The value of the attribute is a static protected value, used as a secret key by the application in order to trust the headers that originate from the Access Gateway.


    The value of the attribute comes from the OID datasource. The OID Datasouce is available in the Oracle E-Business Suite and other application types which provide LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. support. Typically used to to retrieve the Oracle GUID.

    Auth Context The value of the attribute comes from the authentication context which includes the remote address and session id
    App Context The value of the attribute comes from the application context and includes such fields as domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https)., cookie domain,  
  • Editing Attributes

    1. From the Topology tab click the name of the application, then select the Attributes pane.
    2. From the Applications tab click the Edit application () icon on the row associated with the application, then select the Attributes pane.
    3. Click the (+) icon
    4. From the Data Source drop down select an appropriate data source.

    5. From the Field drop down select a field name.

    6. From the Type drop down select the appropriate target type, either Header or Cookie.

    7. In the Name field enter the name for the header or cookie value expected by the legacy application.
      For example, to map the idP field username to the header field login, we would create an attribute resembling:
      Example mapping of idP field login to to header field username.

    8. Click Okay when the attribute is complete.

    9. Repeat as required to add all fields required by the application.

    Okta User Profiles and Attributes

    Okta tenants provide a variety of attribute functionality which are provided to Access gateway using the IDP datasource.
    Within your Okta tenant, for a given Universal Directory you can:

    • Store rich profiles of user attributes in Okta.
    • Customize these profiles with custom attributes.
    • Bi-directionally map and move attributes from Okta and applications.
    • Transform attributes prior to storing or moving with a powerful expression language.

    For more information on

    Next Steps

    • Add fine grained policy to further protect resources.
      An overview of user policy can be found in Application Policy User Overview.
      For details and examples of policy see Administration User Policy Guide.
    • Add supplemental database or LDAP based data store for use as application attributes. For more information see Administer DataStores