The purpose of guide is to describe Access Gateway attributes, how they are managed, used, and general characteristics.
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.
For a given application, attributes may be:
- Added - Click the add attribute icon () to add a new attribute to an application.
- Edited- Click the edit attribute icon () to change the characteristics of an existing attribute.
- Deleted - Click the delete attribute icon ( ) to remove an existing attribute from an application.
- Tested - Click the test attributes icon () to test the values of all attributes for an application. Clicking test runs the AppAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. Login Simulator which allows administrators to enter values for any/all attributes and generated simulated header and cookie values.
Application attributes are defined using the following fields:
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.
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 non-static fields Field used as the source for the attribute.
Maximum length: 128 characters.
Method for passing attributes. Can be one of:
Associated field in either the header or cookie.
DataSource: The Data Source field defines the source for the value of the attribute. The following sources are available:
|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,|
- From the Topology tab click the name of the application, then select the Attributes pane.
- From the Applications tab click the Edit application () icon on the row associated with the application, then select the Attributes pane.
- Click the (+) icon
From the Data Source drop down select an appropriate data source.
From the Field drop down select a field name.
From the Type drop down select the appropriate target type, either Header or Cookie.
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:
Click Okay when the attribute is complete.
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
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