Oracle Cloud Infrastructure Documentation

Managing Applications

Identity domains provide a secure and centralized cloud service to manage your cloud, Oracle, custom, and enterprise applications.

Required Policy or Role

To manage applications, you must have one of the following access grants:
  • Be a member of the Administrators group
  • Be granted the Identity Domain Administrator role or the Application Administrator role
  • Be a member of a group granted manage domains

To understand more about policies and roles, see The Administrators Group, Policy, and Administrator Roles, Understanding Administrator Roles, and Understanding Policies.

Cloud Applications

Cloud applications are web-based applications that function in the cloud. These applications can be accessed from anywhere, and at any time, over the web. Examples of cloud applications are Google, Salesforce, and Dropbox.

Oracle and Custom Applications

Oracle applications are a complete and modular set of enterprise applications, engineered to be cloud-ready. In Oracle Cloud, you'll find a broad range of software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) applications. You can use these applications as part of a subscription-based service; there's no software license or hardware to buy and manage. Oracle handles all the supporting underlying technologies.

You can extend Oracle applications or even build your own custom cloud applications in Oracle Cloud. Custom applications are applications (such as a mobile application, a web page, a client application, or a server application) that you can integrate with IAM. By default, for security purposes, custom applications are trusted or confidential.

IAM leverages the power of OpenID Connect and OAuth to deliver a highly-scalable, multi-tenant token service for securing programmatic access to custom applications by other custom applications, and for federated SSO and authorization integration with these applications:

  • Use OAuth 2.0 to define authorization in IAM for your custom applications. OAuth 2.0 has an authorization framework, commonly used for third-party authorization requests with consent. Custom applications can implement both two-legged and three-legged OAuth flows.

  • Use OpenID Connect to externalize authentication to IAM for your custom applications. OpenID Connect has an authentication protocol that provides Federated SSO, leveraging the OAuth 2.0 authorization framework as a way to federate identities in the cloud. Custom applications participate in an OpenID Connect flow.

Using the OAuth 2.0 and OpenID Connect standards provides the following benefits:

  • Federated SSO between the custom application and IAM. Resource owners (users accessing the custom application) need a single login to access IAM plus all applications integrated. IAM handles the authentication and credentials itself, insulating custom applications. This capability is provided by OpenID Connect with OAuth 2.0.

  • Authorization to perform operations on third-party servers with consent. Resource owners can decide at runtime whether the custom applications should have authorization to access data or perform tasks for them. This capability is provided by OAuth 2.0.

Enterprise Applications

Enterprise applications are web applications that require App Gateway to integrate with IAM 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 out the user.
    • 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 and authorization.

Use Case: Adding Applications

To understand how to add custom applications in an identity domain, read this use case.

This diagram illustrates adding a custom application at a high level.

For this use case, a user accesses the Customer Quotes trusted application. This trusted application is a client application that makes REST API calls to the abccorp.com resource server application. A resource server application is a third-party application that provides services that a trusted application can consume on behalf of the user.

For this example, the abccorp.com resource server application is a financial application that contains REST APIs that can be used to make a quote (/quote), request for a quote (/rfq), or get information about the user (/user).

When the user accesses the Customer Quotes trusted application, the application makes REST API calls to the abccorp.com resource server application on behalf of the user. In this example, the user doesn't communicate directly with the abccorp.com application.

Because the Customer Quotes application performs actions on behalf of the user, the application needs access to the /quote, /rfq, and /user REST APIs available with the abccorp.com application. To make these REST API calls, the Customer Quotes application might ask for the user's consent. This consent can come at any time that the Customer Quotes application calls for these REST APIs in the abccorp.com application.

The user logs in to IAM and accesses the Custom Quotes application, through single sign-on, by using OAuth 2.0 and OpenID Connect, as this is a way of federating identities in the cloud. Because the Customer Quotes application is authorized on behalf of the user to make the /quote, /rfq, and /user REST API calls to the abccorp.com application, the user can use the Customer Quotes application to make a quote, request for a quote, and get information about the user. Any additional actions that the user wants to perform through the Customer Quotes application isn't allowed.

To build this workflow, you create and activate two custom applications in IAM:

  • The abccorp.com resource server application. This application has REST APIs (resources) that other applications, such as the Customer Quotes application, can access. In this example, the user doesn't access the resource server application directly, but indirectly through the Customer Quotes application.

    You register resources of the abccorp.com resource server application. Application resources are API calls that are authorized by IAM. For this example, the application resources are the /quote, /rfq, and /user REST APIs. For security and auditing purposes, you can specify whether the user must give consent to access these resources.

  • The Customer Quotes trusted application. The user uses this application to access the REST APIs of the abccorp.com application.

    When you create this custom application, you want to generate an authorization code for the user when the user logs in to IAM. The authorization code is then sent to the Customer Quotes application to retrieve an access token. The access token contains all the rights that the user has to access the resource server application. For this example, these rights include making a quote, requesting a quote, and retrieving information about the user.

    Because the access token's lifetime is short, you might want to generate a refresh token. A refresh token is a secure mechanism to obtain a new access token when the current access token expires. This way, the Customer Quotes application can access the APIs of the abccorp.com application without asking for user consent again.

See Add Applications, Activate Applications, and Deactivate Applications for more information about creating and activating custom applications in IAM.

Using the Console

Adding Applications

You can add Custom Applications, if you are assigned to either the identity domain administrator role or the application administrator role.

See Assigning Users to Roles for information about assigning users to administrator roles.

You can add the following types of custom applications in IAM:

  • App Catalog application: Add an application from the Application Catalog, which contains pre-configured application templates.

  • Security Assertion Markup Language (SAML) application: Accessed by multiple users and hosted in a secure and protected place (server). Create a SAML application that supports SAML for single sign-on. This allows users to single sign-on (SSO) into your software as a service (SaaS) applications that support SAML for SSO.

  • Mobile application: Hosted directly on the resource owner's browser, machine, or mobile device. An example of this type of application is an Android or iPhone application. A mobile application can run in multiple environments outside of your control. Since these environments are not trusted, this type of application has reduced integration options.

  • Confidential application: Accessed by multiple users and hosted in a secure and protected place (server). The application uses OAuth 2.0. Applications that can protect their OAuth client id and client secret are called confidential applications

  • Enterprise application: Web applications that require App Gateway to integrate with IAM for authentication purposes. App Gateway passes HTTP headers to the application after authenticating and authorizing user's access.

Tip

Adding an App Catalog Application

Oracle creates and maintains the Application Catalog, which is a collection of application templates, for you and provides step-by-step instructions on how to configure most of the popular Software as a Service (SaaS) applications, such as Amazon Web Services and Google Suite.

The configuration options for each Application Catalog application can differ slightly. The steps in this task are for a basic configuration.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click Add application.
  3. In the Add application window, click Application Catalog, and then Launch app catalog.
  4. Locate and select an application by choosing a Category (predefined by Oracle), searching for the application by entering a string that begins with the application name, or to see all applications, click All.
  5. Click the application.
  6. Complete the application details by entering a Name, Description, and Domain Name.
    Note

    For applications with lengthy names, the application name appears truncated in the My Apps page. Consider keeping your application names as short as possible.

  7. (Optional) If applicable, enter a Custom sign-in URL and a Custom sign-out URL in the appropriate fields.
  8. (Optional) In the Custom error URL field, enter the error page URL to which a user has to be redirected, after a failure. This field is optional. However, if not specified, the tenant-specific Error page URL is used. If both the error URLs are not configured, then the error is redirected to the IAM Error Page (/ui/v1/error).

    When a user tries to use social authentication (ex: Google, Facebook, and so on) for logging into IAM, the Custom social linking callback URL must be configured in the Custom error URL field. Social providers need this callback URL to call IAM and send the response back after social authentication. The provided callback URL is used to verify whether the user exists or not (after first-time social login), and displays an error if the social authentication has failed.

  9. In the Custom social linking callback URL field, enter the URL that IAM can redirect to after linking of a user between social providers and IAM is complete.

    When you create a custom app using the IAM custom SDK and integrate with IAM Social Login, the custom app needs to have the Custom social linking callback URL which can be redirected after linking of the user between social provider and IAM is complete.

  10. In the Display settings section, select Display in My Apps.
    Important

    If you don't select Display in My Apps, the application does not display in the My Apps page.

    When you select the Display in My Apps check box in applications, the app is then visible in the My Apps page, but selecting this check box doesn’t enable or disable SSO to the app.

    The flag to enable or disable SSO comes from the app template.

  11. Select the User can request access check box, if you want the app to be listed in the Catalog. This option allows end users to request access to applications from their My Apps page by clicking Add and then selecting the app from the Catalog.
    Tip

    Don’t forget to activate the application so that users can request access.
  12. In the Authentication and authorization section, check Enforce grants as authorization if you want to allow access to this app only if the user has been granted this app.
  13. Click Next and configure SSO.
    • Click Download signing certificate to import the IAM signing certificate into your application. This certificate is used by the SAML application to verify that the SAML assertion is valid.
    • Click Download identity provider metadata to import the IAM Identity Provider metadata into your application. The SAML application needs this information so that it can trust and process the SAML assertion that is generated by IAM as part of the federation process. This information includes, for example, profile and binding support, connection endpoints, and certificate information.

    To get the issuing IAM root certificate, see Obtaining the Root CA Certificate.

  14. Complete the General, Additional configurations, and Attribute configuration sections, as necessary.
  15. Click Finish. The application has been added in deactivate state. To activate your application see Activating Applications.
  16. Click Activate.
  17. In the Resources section, click:
    1. Users to assign users to the application.
    2. Groups to assign groups to the application.
The applications you assign to the user display on the My Apps page. Newly assigned applications and applications that a user has not yet accessed appear first in the application list and have an asterisk icon in the application tile. The icon appears on the tile until the user accesses the application.
Enabling Provisioning for an App Catalog Application

User provisioning and synchronization are an important aspect of application management. Provisioning allows you to manage the lifecycle of accounts in applications like creating and deleting accounts using IAM. For example, when you grant the user access to an application such as Google Suite, then this user account is automatically created in Google Suite. This allows you to quickly add new users to multiple applications and de-provision users from those applications instantly when they change roles or leave your organization.

You can enable and configure provisioning for App Catalog applications either when adding the app or later when modifying it. When you enable provisioning by turning on the switch, the following steps appear:

  1. Configure the app connectivity.

    Configure your app connectivity by providing values for the respective fields. Ensure you Test connectivity before moving to the next configuration.

  2. Configure the Attribute mapping.

    Using Attribute mapping you can map IAM attributes to the attributes in your application account. You can verify the existing default mapping and, if necessary, change mappings by selecting appropriate values from the list for the required user attribute. You can add rows to map missed attributes and delete rows to exclude duplicate attribute mapping. To add a new attribute for provisioning, click Add row, specify the attributes in the User and your application account columns, and then click Save changes. For example, if you want to add the External ID field, enter $(user.externalId) in the User column, and then select the corresponding field from the list in the applications account column.

  3. Select the provisioning operations.

    Any app that supports provisioning and synchronization can be an authoritative app. If Authoritative Sync is configured, you can automatically create, modify, delete, and activate or disable users based only on the corresponding data from the authoritative application. However, the regular provisioning operations are not allowed while authorization sync is enabled.

    When authoritative sync is enabled, the following actions happen automatically:

    • If a user is not present in IAM, then the user is automatically created.

    • If an authoritative synced user is deleted from the application, then the user is also deleted from IAM.

    • If attributes of an authoritative synced user are modified, then the attributes for the user are also modified in IAM.

    When Authoritative Sync is enabled, then the provisioning operations aren’t permitted from IAM to the target application. To manage users in the application using provisioning, clear the Authoritative Sync check box. The following provisioning operations appear:

    • Create account: Select to create an account when the app is granted to the user.

    • Update account: Select to update this account.

    • De-activate Account: Select to deactivate a user who is assigned to an application.

    • Delete account: Select to delete the account in the app when the IAM user is deleted.

Important

When you configure the connection between your app and IAM, check and verify any pre-filled username and password field entries as these might not be the credentials to access your application.
To configure provisioning and synchronization for your application, follow the specific application catalog instructions for the application.
After you have enabled Provisioning, you can perform the following actions:
Enabling Synchronization for an App Catalog Application

User provisioning and synchronization is an important aspect of application management. After enabling provisioning, synchronization allows you to control how operations like creating and deleting accounts in Software as a Service (SaaS) applications are reflected in IAM.

You can enable and configure synchronization for App Catalog applications either when adding the app or later when modifying it. You can only enable synchronization after enabling provisioning. To enable provisioning, see Enabling Provisioning for an App Catalog Application. Follow the application catalog instructions for your specific SaaS app to enable and configure synchronization.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the name of the SaaS app that you want to configure.
  3. Under Resources, click Provisioning, and then turn on the Enable synchronization switch.
  4. In the Configure synchronization section, modify the attributes following the application catalog instructions for your specific SaaS application.
  5. Click Save changes.

Enable synchronization to import users from your SaaS app.

Note

If the number of created objects (users) and deleted recorded objects (synced users) exceeds the maximum number allowed, the sync job quits. The maximum number of objects created or recorded objects deleted is an approximate maximum limit, not a precise limit because of the parallel processing of synced objects.

See Importing User Accounts from a Software as a Service Application.

Importing Users from a SaaS Application

After enabling provisioning and synchronization for your App Catalog app, you might want to import the existing users from your Software as a Service (SaaS) applications and link them to IAM users.

Before you import your SaaS users, verify that:
  1. If not already there, click Applications and then the name of the app that you want to configure.
  2. Verify that the app is activated.
  3. Click Import.
    The page lists the result of the last import if any and the actions you need to perform. See Synchronizing User Accounts.
  4. If you want to invoke an on-demand synchronization, click the Import icon. If the icon is unavailable, click the Provisioning tab and verify that Provisioning and Synchronization are enabled, and the app is activated.
  5. A message confirms that the job for importing users is running successfully.
After the import finishes, the page lists the imported users.
Synchronizing Users

After synchronizing your SaaS app with an identity domain, you will see the result of the import including the number of users created, deleted, and updated. You can do a general search based on account name, user e-mail, or username. You can also filter and search the results based on Situation and Synchronization Status. Select values from the respective lists to view users matching the search criteria. These are helpful when you have to find a set of users based on their situation or status from a huge number of results.

The Import page provides you with the overall status information, whether the last import succeeded, failed, or is still running. If the import succeeded, then the result is listed as follows:

  • Start date is the date and time you started the import job.

  • End date determines date and time the import job finished.

  • Accounts created shows the number of identity domain accounts that got created during the import based on your synchronization settings.

  • Accounts deleted lists the number of identity domain accounts that got deleted during the import based on your synchronization settings.

  • Accounts updated notes the number of identity domain accounts that got changed during the import.

  1. This table summarizes the result of successfully running an import. For each SaaS app account, it shows whether there exists a matching identity domain user and the action that you need to perform to link the SaaS user account to an identity domain user.
    Column Description
    Account

    Shows the name of the SaaS app user account.
    Situation
    Lists whether a matching identity domain user exists or does not exist based on your synchronization configuration:

    • No match is found indicates that you need to manually select which action to take.

    • Exact match is found indicates that an identity domain user exists that matches the synchronization criteria that you configured.

    • Multiple matches are found indicates that there are multiple matches found for a user. You need to manually select one of the available actions.

    • Manually linked is the result of any action that you performed to link this SaaS app account to an identity domain user.
    User

    Shows the email address and user name of the identity domain user.
    Action
    If there is no matching identity domain user, you need to select the appropriate action from the list:

    • Assign existing user: The Assign user page lists all existing identity domain users and allows you to select the one that you want to link with this SaaS app account.

    • Create new user and link: The Add user page allows you to create a new identity domain user.
    Status

    Lists the status or whether you need to confirm linking the SaaS app account to the identity domain user.
  2. Take the appropriate action to link your SaaS users with identity domain accounts.
Accessing the Synchronization Failure Report

You can view the synchronization failure report of a provisioning application from the Import tab. The report contains the sync failures for the selected application. This report is useful in finding out the reason behind sync failures that occurred during account and object sync of an application.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Select Import and click Synchronization failure.
  4. In the Synchronization Failure Report page, you can use the filters to narrow down the result based on the following criteria:
    1. Application

      The Application filter is case-sensitive.

    2. Dates range

      Choose the number of days for which you need the failure report. Preconfigured values are: Past 30 Days, Past 60 Days, Past 90 Days. Alternatively, enter the Start date and the End date in the text box or select them from the calendar.

    3. Object type

    To narrow down the result based on Application or Object type, choose a value from the menu and enter a corresponding value in the text box. The available values are: Equals, Contains, Starts with and Ends with.

    Tip

    If you select Equals and enter Google App in the text box, the filter displays entries only for Google App. If you select Starts with and enter G in the text box, the filter displays entries for applications starting with the letter G.
  5. After you have set the filter, click Run to display the search result.

    The following table describes the various columns in the search filter:

    Filter Columns

    Description

    Application

    Displays the name of the Application.

    Object type

    Displays the type of the Object, for example, Account, Group, Organization, Printer, and so on.

    Object identifier

    Displays the unique ID of the object from which sync is performed.

    Name

    Displays the name of the object on which sync is performed.

    Date

    Displays the time when the sync was performed on the object.

    ECID

    Displays the value of the Event Correlation Identifier (ECID).

    Failure reason

    Displays the reason behind the synchronization failure.
  6. Click Download report to export the search result in the tabular column to a CSV file.
Adding a SAML Application

Create a Security Assertion Markup Language (SAML) application and grant it to users so that your users can single sign-on (SSO) into your SaaS applications that support SAML for SSO.

Before you begin: Before you create the SAML application, all users who need to sign in using this application must be present in the Service Provider (SP). If needed, use SCIM provisioning to sync any users or groups from the Identity Provider (IdP) to the SP. See Integrating Custom Applications with IAM.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click Add application.
  3. In the Add application window, click SAML Application, and then Launch workflow.
  4. In the Add SAML Application page, provide values for the following fields:

    • In the Name field, enter a name for the application.

      For applications with lengthy names, the application name appears truncated in the My Apps page. Consider keeping your application names as short as possible.

    • In the Description field, enter 250 or fewer characters to provide a description of the application.

    • Click the close (X) in the Application icon window to delete the default Application icon and then add your own icon for the application.

    • Select Add app links to add links that are associated with the application. Click Add and the Add app link window appears. App links are services such as Mail or Calendar that are offered by applications such as Google or Office 365.

      In the Add app link window:

      1. Enter a Name for the App link.

      2. In the Relay state field, enter the URL used to access the application.

      3. Click the close (X) in the Application icon window to delete the default Application icon for the app link and then add your own icon for the application.

      4. Select Visible if you want your application to appear automatically on each user’s My Apps page.
        Note

        Selecting this check box does not enable or disable SSO into the application.

      5. Click Add.

      The App link information appears in the table in the App links section.

      To remove an App link, select the row, and then click Remove.

      Note

      There is a delay (a few seconds) between clicking Remove and the App no longer appearing on the My Apps page. App link deletion (and grants related to those App links) is asynchronous. Wait a few seconds for the asynchronous task to remove the App and its grants before trying My Apps again.

    • In the Relay state field, enter a value which is sent to the SAML SP as the SAML RelayState parameter.

    • In the Custom sign-in URL field, specify a custom sign-in URL. However, if you are using a default login page provided by IAM, then leave this field blank.

    • In the Custom error URL field, enter the error page URL to which a user has to be redirected, if there is a failure. This is an optional field. However, if not specified, the tenant-specific Error page URL is used. If both the error URLs are not configured, then the error is redirected to the IAM Error Page (/ui/v1/error).

      When a user tries to use social authentication (ex: Google, Facebook, and so on) for logging into IAM, the callback URL must be configured in the Custom Error URL field. Social providers need this callback URL to call IAM> and send the response back after social authentication. The provided callback URL is used to verify whether the user exists or not (in the case of first-time social login), and display an error if the social authentication has failed.

    • In the Custom social linking callback URL field, enter the URL that IAM> can redirect to after linking of a user between social providers and IAM> is complete. This is an optional field.

      When you create a custom app using IAM> custom SDK and integrate with IAM> Social Login, the custom app needs to have the Linking callback URL which can be redirected after linking of the user between social provider and IAM is complete.

  5. In the Display settings sections of the Add SAML Application page, make the following selections:

    • Select Display in My Apps check box to specify you want the SAML App to be listed on the My Apps page.

      When you select the Display in My Apps check box in applications, the app is then visible in the My Apps page, but selecting this check box doesn’t enable or disable SSO to the app.

      The flag to enable or disable SSO comes from the app template.

    • Select the User can request access check box if you want the app to be listed in the Catalog. This option allows end users to request access to the app from their My Apps page by clicking Add and then selecting the app from the Catalog.

    Note

    Don’t forget to activate the application so that users can request access.
  6. When you are creating SAML app from scratch rather than creating a preconfigured SAML app created from the App Catalog, the Authentication and authorization section appears. The Enforce grants as authorization check box is selected by default. This check box enables users to access only the application that you assigned or granted access to. If the check box is selected, IAM can control access to the SAML application based on grants to users and groups. If the check box is not selected, any authenticated user has access to the application regardless of the assignment status.
  7. Click Next and configure SSO for the SAML application.
  8. In the General section of the Configure single sign-on page, define the following:

    • Entity ID: Enter a globally unique name for a SAML entity. The Entity ID is usually the URL of an identity provider or a service provider.

    • Holder-of-Key subject confirmation required: Turn on this option and then enter the endpoint at the service provider where the identity provider can send SAML authentication Holder-of-Key (HOK) assertions.

    • Assertion consumer URL: Enter the URL to which the SAML identity provider sends the SAML assertion. This URL must begin with either the HTTP or HTTPS protocol.

    • Name ID format: Select the type of format to use for the Name ID. The service provider and the identity provider use this format to easily identify a subject during their communication.

      Note

      When you integrate IAM with MS SharePoint app based on WS Fed 1.1 protocol, the following options are not available in the Name ID format: Persistent, Kerberos, and Transient.

    • Name ID value: Select the Name ID Value to identify the user that is logged in. The available options are Username , the user’s Primary email address and Expression. When you select the Expression option, enter a regular expression as a value in the text box. There is no character limit for the value, however, there are validation rules that are performed on the value for any invalid characters that cannot be mapped.

    • Signing certificate: Upload the signing certificate that is used to encrypt the SAML assertion.

      Note

      Some browsers show file paths prepended with c:\fakepath\. This behavior is a security feature of the browser and does not disrupt the upload process.
  9. Use the following table to define a more fine-grained SAML configuration in the Additional configurations section.
    Option Description
    Signed SSO

    Select Assertion to indicate that you want the SAML assertion signed. Select Response when you want the SAML authentication response signed.
    Include signing certificate in signature

    Select the check box to include the signing certificate in the signature, for example, when the application requires that the signing certificate is sent along with the assertion.
    Signature hashing algorithm

    Select the type of signing algorithm that you want to use to sign the assertion or the response, either SHA-256 or SHA-1. SHA-256 generates a fixed 256-bit hash. SHA-1 generates a 160-bit hash value known as a message digest.

    Note: In a FIPS enabled environment, set the Signature hashing algorithm to SHA-256, the only supported hashing algorithm, to avoid errors during SSO.

    Enable single logout

    Select to configure SAML single logout. Single logout enables a user to lot out of all participating sites in a federated session almost simultaneously. This check box is selected by default. Clear it if you do not want to enable single logout.
    Logout binding

    Select whether the log out request is sent as a REDIRECT (transported using HTTP 302 status-code response messages) or a POST (transported in HTML form-control content, which uses a base-64 format). This list box appears only if you select the Enable single logout check box.
    Single logout URL

    Enter the location (HTTP or HTTPS) where the log out request is sent. This field appears only if you select the Enable single logout check box.
    Logout response URL

    Enter the location (HTTP or HTTPS) where the log out response is sent. This field appears only if you select the Enable single logout check box.
    Encrypt assertion

    Select if you want to encrypt the assertion, and then define the encryption algorithm that you want to use and upload the encryption certificate.
    Encryption certificate

    Click Upload to upload the encryption certificate that's used to encrypt the SAML assertion. This button appears only if you select the Encrypt assertion check box.
    Encryption algorithm

    Select which encryption algorithm you want to use to encrypt the SAML assertion. This list box appears only if you select the Encrypt assertion check box.
    Key Encryption algorithm

    Select which key encryption algorithm you want to use to encrypt the SAML assertion. This list box appears only if you select the Encrypt assertion check box.
  10. In the Attribute configuration section, add user-specific and group-specific attributes to the SAML assertion. This is useful if your application uses user-specific or group-specific attributes, and you want to send that information as part of the SAML assertion.
  11. Click Additional attributes, and then use the following table to specify the user attribute that you want to include. User information in the attribute statement contains a list of attributes. Each attribute includes a name and a list of values (if there are multiple attribute values). Each value includes a value and the format of the value.
    Option Description
    Name

    Enter the name of the SAML assertion attribute.
    Format

    Select the format of this SAML assertion attribute: Basic, URI Reference, or Unspecified.

    Note: When you integrate IAM with MS SharePoint app based on WS Fed 1.1 protocol, Format menu is replaced with Namespace.
    Type
    Select one of the following options to specify the value of the assertion attribute.:

    • User attribute

      Select this option to choose one of the predefined list of user attributes or group attributes in the Value menu as the value of the assertion attribute. To specify group attributes, select User attribute and in the Value field, select Group membership.

    • Expression/literal

      Select this option when you cannot use any of the predefined values in the Value menu. You can provide an expression in the Value text box to specify the value of the SAML assertion attribute.

      To specify group attributes, select Expression/literal and specify an expression to fetch the groups.

      Example: The following expression specifies that the value of the SAML attribute should be the names of all the groups to which the user belongs: $(user.groups[*].display).
    Type value

    Select or enter the value to send as part of the assertion based on the Type that you have selected.

    When the type is User attribute, you can select one of the predefined list of user attributes as the value of the assertion attribute. Select the Group membership option in the menu if you want to send the users group membership as the value of the assertion attribute. The Condition and Value columns appear when you choose Group membership.

    When the type is Expression/literal, the value field is a text box and you can enter any path expression to specify what should be the value of the assertion attribute.

    The following are some examples of path expressions:

    • To send a list of literal values as the value of the assertion attribute, use ["value1", "value2", "value3"].

    • To send “home email” as the value of the assertion attribute, use $(user.emails[type eq "home"].value).

    • To send users first name concatenated with last name as the assertion attribute, use #concat($(user.name.givenName), $(user.name.familyName)).

    • To send an account attribute called SALARY as the value of the assertion attribute, use $(account.SALARY).

    • To include an attribute department from custom schema extension, use $(user.urn:ietf:params:scim:schemas:idcs:extension:custom:User:department).

    • To send a literal value as the value of assertion, use aLiteralValue.
    Condition

    Select a condition from the menu to filter the group memberships. This field is enabled only when you select User attribute as Type and Group membership as Type value. The available values are: Equals, Starts with, and All groups.
    Condition value

    Enter the filter value to use when filtering the group memberships.
  12. Click Finish. The application is added in a deactivated state. To activate your application, see Activating Applications.
  13. In the SSO Configuration section, to import the IAM signing certificate into your application, click Download signing certificate to first download the certificate file in PEM format. This certificate is used by the SAML application to verify that the SAML assertion is valid.
  14. In the SSO Configuration section, to import the IAM Identity Provider metadata into your application, click Download identity provider metadata to first download the metadata file in XML format. The SAML application needs this information so that it can trust and process the SAML assertion that is generated by IAM as part of the federation process. This information includes, for example, profile and binding support, connection endpoints, and certificate information. To get the issuing IAM root certificate, see Obtaining the Root CA Certificate.
Editing SSO Configuration Information for SAML Applications

You can edit SSO configuration information for SAML applications.

See Add a SAML Application for more information about the SSO configuration settings for SAML applications.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Select the SAML application from the list of applications listed.
  3. Under the SSO configuration section, click Edit SSO configuration.
  4. In the General section, modify required SAML assertion attributes for the SAML application.
  5. In the Additional configurations section, modify optional advanced SAML assertion settings for the SAML application (for example, selecting Assertion from the Signed SSO list to indicate that you want the SAML assertion signed).
  6. In the Attribute configuration section, modify user-specific and group-specific attributes for the SAML application (for example, selecting the type of user attribute from the User attribute list or selecting the condition by which you want to filter the group memberships from the Condition list).
  7. Click Save changes.
Adding a Mobile Application

Add mobile applications that use OAuth 2.0 and they cannot maintain the confidentiality of their client secrets.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click Add application.
  3. In the Add application window, click Mobile Application.
  4. Click Launch workflow.
  5. In the Add applications details page, use the following table to configure the application details.
    Option Description
    Name

    Enter a name for the mobile application. You can enter up to 125 characters.

    For applications with lengthy names, the application name appears truncated in the My Apps page. Consider keeping your application names as short as possible.
    Description

    Enter a description of the mobile application. You can enter up to 250 characters.
    Application icon

    Click the close (X) in the Application icon window to delete the default Application icon and then add your own icon for the application. This icon appears next to the name of the application on the My Apps page and the Applications page.
    Custom sign-in URL

    In the Custom sign-in URL field, specify a custom sign-in URL. However, if you are using a default login page provided by IAM, then leave this field blank.
    Custom sign-out URL

    In the Custom sign-out URL field, specify a custom sign-out URL. However, if you are using a default login page provided by IAM, then leave this field blank.
    Custom error URL

    This is an optional field. Enter the error page URL to which a user has to be redirected, if there is a failure. If not specified, the tenant-specific Error page URL is used. If both the error URLs are not configured, then the error is redirected to the IAM Error Page (/ui/v1/error).

    When a user tries to use social authentication (ex: Google, Facebook, and so on) for logging into IAM, the callback URL must be configured in the Custom error URL field. Social providers need this callback URL to call IAM and send the response back after social authentication. The provided callback URL is used to verify whether the user exists or not (if this is a first-time social login), and display an error if the social authentication has failed.
    Custom social linking callback URL

    This is an optional field. Enter the URL that IAM can redirect to after linking of a user between social providers and IAM is complete.

    When you create a custom app using IAM custom SDK and integrate with IAM Social Login, the custom app needs to have the Custom social linking callback URL which can be redirected after linking of the user between social provider and IAM is complete.
    Display in My Apps

    Select the check box if you want the mobile application to be listed for users on their My Apps pages. In this case, you need to configure the application as a resource server.

    When you select the Display in My Apps check box in applications, the app is then visible in the My Apps page, but selecting this check box doesn’t enable or disable SSO to the app.

    The flag to enable or disable SSO comes from the app template. Use the IAM REST APIs to update this flag. You cannot set the SSO flag from the UI.

    User can request access

    Select the User can request access check box if you want the app to be listed in the Catalog. This option allows end users to request access to the app from their My Apps page by clicking Add and then selecting the app from the Catalog.
    Enforce grants as authorization

    Select the check box if you want end users to be able to request access to the app from their My Apps page by clicking Add access. If self-service is not enabled, users won’t see the Add access button.
  6. Click Next.
  7. In the Authorization section of the Add Mobile Application page, use the following table to configure application details.
    Option Description
    Allowed grant types
    Select the check box for the grant types that this application is allowed to use when requesting validation.
    • Select the Refresh token grant type when you want a refresh token supplied by the authorization server, and then use it to obtain a new access token. Refresh tokens are used when the current access token becomes invalid or expires and don’t require the resource owner to reauthenticate.

    • Select the Authorization code check box when you want to obtain an authorization code by using an authorization server as an intermediary between the client application and resource owner.

      An authorization code is returned to the client through a browser redirect after the resource owner gives consent to the authorization server. The client then exchanges the authorization code for an access (and often a refresh) token. Resource owner credentials are never exposed to the client.

    • Select the Implicit check box if the application can't keep client credentials confidential for use in authenticating with the authorization server.

      An access token is returned to the client through a browser redirect in response to the resource owner authorization request (rather than an intermediate authorization code).

    • Select the Device code grant type if the client can't receive requests from the OAuth Authorization Server, for example, it cannot act as an HTTP server such as game consoles, streaming media players, digital picture frames, and others.

      In this flow, the client obtains the user code, device code, and verification url. The user then accesses the verification url in a separate browser to approve the access request. Only then can the client obtain the access token using the device code.
    Allow non-HTTPS URLs

    Select this check box if you want to use HTTP URLs for the Redirect URL, Logout URL, or Post logout redirect URL fields. For example, if you are sending requests internally, want a non-encrypted communication, or want to be backward-compatible with OAuth 1.0, then you can use an HTTP URL.

    Also, select this check box when you are developing or testing your application and you might not have configured SSL. This option is provided as a convenience and is not recommended for production deployments.
    Redirect URL

    Enter the application URL where the user is redirected after authentication. Add additional redirect URLs as needed.
    Post-logout redirect URL

    Enter the URL where you want to redirect the user after logging out of the application. Add additional post-logout redirect URLs as needed.
    Logout URL

    Enter the URL where the user is redirected after logging out of the application.
    Allowed operations

    Select the On behalf of check box, if you want to ensure that access privileges can be generated from the user's privileges alone, so that a client application can access endpoints to which the user has access, even if the client application by itself would not normally have access.
    Bypass consent

    If enabled, this attribute overwrites the Require consent attribute for all the scopes configured for the application, and then no scope will require consent.
    Client IP address
    • Anywhere: The token request is allowed from anywhere. There is no perimeter.
    • Restrict by network perimeter: Select the network perimeters so that a token request is only allowed from them.
    Add resources

    If you want your application to access APIs from other applications, then click Add scope in the Token issuance policy section. Then, in the Add scope window, select the applications that your application will reference.
    Add app roles

    Click Add to enable your mobile application to access IAM APIs.

    In the Add app roles window, select the application roles that you want to assign to this application. This enables your application to access the REST APIs that each of the assigned application roles can access.

    For example, select Identity Domain Administrator from the list. All REST API tasks available to the identity domain administrator will be accessible to your application.

    You can delete the application roles by clicking the x icon for the row of the required application role.

    Note: You can’t delete protected application roles.
  8. Click Finish. A message confirms that the application has been added in deactivated state. To activate your application see Activating Applications.
  9. Note that the Client ID appears General information section for the application. To integrate with your application, use this ID as part of your connection settings. Because a mobile application runs on a mobile device, a Client Secret is not generated for this type of application.
Adding a Confidential Application

Confidential applications run on a protected server.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click Add application.
  3. In the Add application window, click Confidential Application, and then click Launch workflow.
  4. In the Add application details page, use the following table to configure application details and the display settings.
    Option Description
    Name

    Enter a name for the confidential application. You can enter up to 125 characters.

    For applications with lengthy names, the application name appears truncated in the My Apps page. Consider keeping your application names as short as possible.
    Description

    Enter a description for the confidential application. You can enter up to 250 characters.
    Application icon

    Click the close (X) in the Application icon window to delete the default Application icon and then add your own icon for the application. This icon appears next to the name of the application on the My Apps page and the Applications page.
    Application URL

    Enter the URL (HTTP or HTTPS) where the user is redirected after a successful login. This value is also known as the SAML RelayState parameter. HTTPS format is suggested. Only use HTTP for testing purposes.

    For Enterprise applications, 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.
    Custom sign-in URL

    In the Custom sign-in URL field, specify a custom sign-in URL. However, if you are using a default login page provided by IAM, then leave this field blank.
    Custom sign-out URL

    In the Custom sign-out URL field, specify a custom sign-out URL. However, if you are using a default login page provided by IAM, then leave this field blank.
    Custom error URL

    This is an optional field. Enter the error page URL to which a user has to be redirected, if there is a failure. If not specified, the tenant-specific Error page URL is used. If both the error URLs are not configured, then the error is redirected to the IAM Error Page (/ui/v1/error).

    When a user tries to use social authentication (ex: Google, Facebook, and so on) for logging into IAM, the callback URL must be configured in the Custom Error URL field. Social providers need this callback URL to call IAM and send the response back after social authentication. The provided callback URL is used to verify whether the user exists or not (if this is a first-time social login), and display an error if the social authentication has failed. This is the URL where the callback is sent with social registration user details, if a successful logged-in social user account does not exist in IAM.
    Custom social linking callback URL

    This is an optional field. Enter the URL that IAM can redirect to after linking of a user between social providers and IAM is complete.

    When you create a custom app using IAM custom SDK and integrate with IAM Social Login, the custom app needs to have the Linking callback URL which can be redirected after linking of the user between social provider and IAM is complete.
    Display in My Apps

    Select the check box if you want the confidential application to be listed for users on their My Apps pages. In this case, you need to configure the application as a resource server.

    When you select the Display in My Apps check box in applications, the app is then visible in the My Apps page, but selecting this check box doesn’t enable or disable SSO to the app.

    The flag to enable or disable SSO comes from the app template.
    User can request access

    Select the check box if you want end users to be able to request access to the app from their My Apps page by clicking Add Access. If self-service is not enabled, users won’t see the Add Access button.

    For Confidential apps: Enforce grants as authorization

    For Enterprise apps: User must be granted this app

    If you want IAM to control access to the application based on grants to users and groups, select this option. If you clear this option, any authenticated user has access to the application.
  5. Click Next.
  6. On the Configure OAuth pane, to protect resources for your application now, and to make the application visible on the My Apps page, click Configure this application as a resource server now
    Use the following table to provide the information needed to configure this application as a resource server.
    Option Description
    Access token expiration (seconds)

    Define how long (in seconds) the access token associated with your confidential application remains valid.
    Allow token refresh

    Select this check box if you want to use the refresh token that you obtain when using the Resource Owner, Authorization Code, or Assertion grant types.
    Refresh token expiration (seconds)

    Define how long (in seconds) the refresh token, which is returned with your access token and is associated with your confidential application, remains valid.
    Primary audience

    Enter the primary recipient where the access token of your confidential application is processed.
    Add secondary audience

    Enter the secondary recipients where the access token of your confidential application is processed, and click Add. The secondary recipient appears in Secondary audience column, and the Protected column allows you to know whether the secondary audience is protected or not.
    Add scopes

    To specify which parts of other applications that you want your application to access, add those scopes to your confidential application.

    Applications must interact securely with external partner or confidential applications. Also, applications from one Oracle Cloud service must interact securely with applications in another Oracle Cloud service. Each application has application scopes that determine which of its resources are available to other applications.
  7. On the Configure OAuth pane, click Configure this application as a client now.
    Use the following table to provide the information needed to configure this application as a client.
    Option Description
    Resource owner Use when the resource owner has a trust relationship with the confidential application, such as a computer operating system or a highly privileged application, because the confidential application must discard the password after using it to obtain the access token.
    Client credentials

    Use when the authorization scope is limited to the protected resources under the control of the client or to the protected resources registered with the authorization server.

    The client presents its own credentials to obtain an access token. This access token is either associated with the client’s own resources, and not a particular resource owner, or is associated with a resource owner for whom the client is otherwise authorized to act
    JWT assertion

    Use when you want to use an existing trust relationship expressed as an assertion and without a direct user approval step at the authorization server.

    The client requests an access token by providing a user JSON web token (JWT) assertion or a third-party user JWT assertion and client credentials. A JWT assertion is a package of information that facilitates the sharing of identity and security information across security domains.
    SAML2 assertion

    Use when you want to use an existing trust relationship expressed as a SAML2 assertion and without a direct user approval step at the authorization server.

    The client requests an access token by providing a user SAML2 assertion or a third-party user SAML2 assertion and client credentials. A SAML2 assertion is a package of information that facilitates the sharing of identity and security information across security domains.
    Refresh token Select this grant type when you want a refresh token supplied by the authorization server, and then use it to obtain a new access token. Refresh tokens are used when the current access token becomes invalid or expires and don’t require the resource owner to reauthenticate.
    Authorization code

    Select this grant type when you want to obtain an authorization code by using an authorization server as an intermediary between the client application and resource owner.

    An authorization code is returned to the client through a browser redirect after the resource owner gives consent to the authorization server. The client then exchanges the authorization code for an access (and often a refresh) token. Resource owner credentials are never exposed to the client.
    Implicit

    If the application can't keep client credentials confidential for use in authenticating with the authorization server, then select this check box. For example, your application is implemented in a web browser using a scripting language such as JavaScript. An access token is returned to the client through a browser redirect in response to the resource owner authorization request (rather than an intermediate authorization).
    Device code

    Select the Device Code grant type if the client doesn't have the capability to receive requests from the OAuth Authorization Server, for example, it cannot act as an HTTP server such as game consoles, streaming media players, digital picture frames, and others.

    In this flow, the client obtains the user code, device code, and verification URL. The user then accesses the verification URL in a separate browser to approve the access request. Only then can the client obtain the access token using the device code.
    TLS client authentication

    Select the TLS Client Authentication grant type to use the client certificate to authenticate with the client. If a token request comes with an X.509 client certificate and the requested client is configured with the TLS Client Authentication grant type, the OAuth service uses the Client_ID in the request to identify the client and validate the client certificate with the certificate in the client configuration. The client is successfully authenticated only if the two values match.

    For added security, before enabling the TLS Client Authentication grant type, enable and configure OCSP validation and import a trusted partner certificate.

    Allow HTTP URLs

    Select this check box if you want to use HTTP URLs for the Redirect URL, Logout URL, or Post logout redirect URL fields. For example, if you are sending requests internally, want a non-encrypted communication, or want to be backward-compatible with OAuth 1.0, then you can use an HTTP URL.

    Also, select this check box when you are developing or testing your application and you might not have configured SSL. This option is not recommended for production deployments.
    Redirect URL

    Enter the application URL where the user is redirected after authentication.

    Note: Provide an absolute URL. Relative URLs are not supported.
    Post-logout redirect URL

    Enter the URL where you want to redirect the user after logging out of the application.
    Logout URL

    Enter the URL where the user is redirected after logging out of the confidential application.
    Client type

    Select the client type. The available client types are Trusted and Confidential. Choose Trusted if the client can generate self-signed user assertions. Then, to import your signing certificate that the client uses to sign its self-signed assertion, click Import certificate.
    Allowed operations

    • Select the Introspect check box if you want to allow access to a token introspection end point for your application.

      If the confidential application can't keep client credentials confidential for use in authenticating with the authorization server, then select this check box. For example, your confidential application is implemented in a web browser using a scripting language such as JavaScript.

      An access token is returned to the client through a browser redirect in response to the resource owner authorization request (rather than an intermediate authorization code).

    • Select the On behalf of check box if you want to ensure that access privileges can be generated from the user's privileges alone. This allows the client application to access endpoints to which the user has access, even if the client application by itself would not normally have access.
    ID token encryption algorithm

    Select one of the content encryption algorithms.
    Bypass consent

    If enabled, this attribute overwrites the Require consent attribute for all the scopes configured for the application, and then no scope will require consent.
    Client IP address
    • Anywhere: The token request is allowed from anywhere. There is no perimeter.
    • Restrict by network perimeter: Select the network perimeters so that a token request is only allowed from them.
    Authorized resources

    Select one of the following options to allow a client application to access authorized resources:

    Note: The option to define an authorized resource is available to only Confidential applications. Trust scope cannot be defined for Mobile applications.
    Add resources

    If you want your application to access APIs from other applications, then check Add resources in the Token issuance policy section. Then, in the Add scope window, select the applications that your application references.

    Note: You can delete scopes by clicking the x icon next to the scope. However, you can’t delete scopes that are protected.
    Add app roles

    Check Add app roles. In the Add app roles window, select the application roles that you want to assign to this application. This enables your application to access the REST APIs that each of the assigned application roles can access.

    For example, select Identity Domain Administrator from the list. All REST API tasks available to the identity domain administrator will be accessible to your application.

    You can delete the application roles by selecting the application role and then clicking Remove.

    Note: You can’t delete protected application roles.
  8. Click Next.
  9. Configure the web tier policy. Import an existing web tier policy or manually edit the policy in Simple mode by completing the fields or in Advanced mode by editing a JSON file.
  10. Add any resources that you want to protect.
  11. Click Finish.
    The application has been added in a deactivated state.
  12. Record the Client ID and Client secret in the Application added dialog box.
    To integrate with your confidential application, use this ID and secret as part of your connection settings. The Client ID and Client secret are equivalent to a credential (for example, an ID and password) that your application uses to communicate with IAM.
  13. Click Close.

    The new application’s details page is displayed.

  14. At the top of the page, to the right of the application name, click Activate.
  15. Confirm the activation.
  16. Under the Resources section:
    1. Click Consent information and then add consent information information.
    2. Click Users or Groups to add users and groups to the app.
Configuring Authorized Resources

Authorized resources define the way a client can access the resources in a Confidential application.

Accessing All Resources

The All authorized resource option enables the client to access any resource within a domain.

Select All to allow your application to request an access token for trusted or confidential client using the scope urn:opc:resource:consumer::all. This option provides a wide scope. The access token in the response contains the audience urn:opc:resource:scope:account and the scope urn:opc:resource:consumer::all, which gives access to any of the services that are in the same domain without requiring explicit association with target services.

Use only the urn:opc:resource:consumer::all scope in the request. An invalid scope error is returned if you attempt to include both the urn:opc:resource:consumer::all scope and another scope in the same request, such as urn:opc:idm:__myscopes__.

In the account mode, clients can get token for any specific resource provided either urn:opc:resource:consumer::all or the specific resource is added in the allowed scopes.

Apart from the scope defined above, you can also specify fine-grained scope as follows:

  • urn:opc:resource:consumer:paas::read

  • urn:opc:resource:consumer:paas:stack::all

  • urn:opc:resource:consumer:paas:analytics::read

Note

The requested scope should always exist and match, either directly or hierarchically, the client's defined allowed scopes to allow the client access to the resource.

For example, a client uses the urn:opc:resource:consumer:paas:analytics::read scope in its request for access to a resource. If the scope directly matches an allowed scope defined, then in the returned access token the audience is urn:opc:resource:scope:account and the scope is urn:opc:resource:consumer:paas:analytics::read.

If the allowed scope defined by the client is urn:opc:resource:consumer:paas::read, then the client is allowed to access the resource hierarchically if the client requests one of the following scopes:

  • urn:opc:resource:consumer:paas::read

  • urn:opc:resource:consumer:paas:analytics::read

However, if the requested scope is urn:opc:resource:consumer:paas:analytics::write with a different qualifier, then the client isn’t allowed access to the resource.

Note

The All option doesn't provide access to the IAM admin APIs. You must continue to use the scope urn:opc:idm:__myscopes__ to access the admin APIs.

To generate a refresh token in addition to the access token, use the scope urn:opc:resource:consumer::all offline_access in the request.

Accessing Resources with Matching Tags

The Tagged authorized resource option enables the client to access any resource with matching tags.

Request an access token using the trusted or confidential client and request the scope urn:opc:resource:consumer::all. The access token in the response contains the audience urn:opc:resource:scope:tag=<base64 encoded JSON> and the scope urn:opc:resource:consumer::all, which gives access to Resource Apps that have tags that match the allowed tags specified in the Client App.

In the tags mode, clients can get token for any specific resource provided either the client has matching tags with the resource and urn:opc:resource:consumer::all or the specific resource is added in the allowed scopes.

Select Tagged to enable your confidential application to access tags from other applications.

When you select Tagged, you can choose scopes from an OPC application that aren't specific, such as urn:opc:resource:consumer.

  1. Select Tagged.
  2. Select Add Scope under Resources.
  3. Select urn:opc:resource:consumer on the Select scope page and click >.
  4. Select the OPC scopes that you want to add and provide a named qualifier, such as read and write to each of the scopes. You can edit these qualifiers dynamically.
  5. Click Add.
    The scopes appear under Resources.
In addition to using the urn:opc:resource:consumer::all scope, you can also specify the following fine-grained scopes:

  • urn:opc:resource:consumer:paas::read

  • urn:opc:resource:consumer:paas:stack::all

  • urn:opc:resource:consumer:paas:analytics::read

Note

The requested scope must always exist and match, either directly or hierarchically, the client's defined allowed scopes to allow the client access to the resource.

For example, a client uses the urn:opc:resource:consumer:paas:analytics::read scope in its request for access to a resource. If the scope directly matches an allowed scope defined, then in the returned access token the audience is urn:opc:resource:scope:tag=<base64 encoded JSON> and the scope is urn:opc:resource:consumer:paas:analytics::read.

For client allowed tags color:green and color:blue, the sample JSON is as follows:

{"tags":[{ "key":"color","value":"green"},{"key":"color","value":"blue"} ]}

If the allowed scope defined by the client is urn:opc:resource:consumer:paas::read, then the client is allowed to access the resource hierarchically if the client requests one of the following scopes:

  • urn:opc:resource:consumer:paas::read

  • urn:opc:resource:consumer:paas:analytics::read

However, if the requested scope is urn:opc:resource:consumer:paas:analytics::write, then the client isn't allowed access to the resource, since that isn't one of the allowed scopes defined by the client.

Accessing Resources with Specific Scopes

The Specific authorized resource option enables the client to access only those resources where an explicit association between the client and the resource exists.

Leave Specific selected (the default) to allow your application to acquire an access token with permissions based on an explicit association between the client and target services. Then, use the Add button to select the applications that your application references.

Regenerating a Client Secret for Confidential Applications

When you create a confidential application, you use a Client ID and a Client Secret as part of your connection settings. You can regenerate your Client Secret at any time for a confidential application using the identity domains console.

An active confidential application.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the confidential application for which you want to regenerate a Client Secret.
  3. In the General information section, click Regenerate. The new Client Secret appears in the New client secret dialog box. Copy the Client Secret if necessary.
  4. Click Close.
Generating Tokens for Confidential Applications

When you create a confidential application and you configure the client to use the JWT Assertion grant type, you can generate access tokens at any time using the identity domain console.

An active confidential application with the client configured to use the JWT Assertion grant type.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.Select the identity domain you want to work in and click Applications.
  2. Click the confidential application for which you want to generate an access token.
  3. Click Access token.
  4. In the Access token section, use the following table to configure which scopes are included in the access token:
    Option Description
    Available scopes

    Click Available scopes to get the access token to access any resources configured for the application.

    If the scopes are defined from multiples resource servers, the token cannot be generated. Use the Customized scopes option and ensure that the selected scopes are from the same resource server.
    Customized scopes using Invokes identity domain APIs

    1. Click Customized scopes and Invokes identity domain APIs.

    2. From the list of roles that are assigned to the client application, select those roles that you want to include or remove to limit the scopes to be populated in the resulting token.
    Customized scopes using Invokes other APIs

    1. Click Customized scopes and Invokes other APIs.

    2. The UI displays a list of all the scopes assigned to the application. You can select any scopes as long as those scopes are from the same resource server.
    Include refresh token

    The Include refresh token check box is enabled if the Refresh token grant type is configured for your client application and the resource server to which the scopes belong to allows refresh token generation. The refresh token is used to obtain a new access token without requiring the user to reauthenticate.
  5. Click Download token.
    Note

    The downloaded token gets saved as a tokens<n>.tok file in the download folder of your browser.
Adding an Enterprise Application

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

To add an enterprise application in an identity domain, 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.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click Add application.
  3. In the Add application window, click Enterprise Application.
  4. In the Add application details page, use the following table to configure application details and the display settings.
    Option Description
    Name

    Enter a name for the confidential application. You can enter up to 125 characters.

    For applications with lengthy names, the application name appears truncated in the My Apps page. Consider keeping your application names as short as possible.
    Description

    Enter a description for the confidential application. You can enter up to 250 characters.
    Application icon

    Click the close (X) in the Application icon window to delete the default Application icon and then add your own icon for the application. This icon appears next to the name of the application on the My Apps page and the Applications page.
    Application URL

    Enter the URL (HTTP or HTTPS) where the user is redirected after a successful login. This value is also known as the SAML RelayState parameter. HTTPS format is suggested. Only use HTTP for testing purposes.

    For Enterprise applications, 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.
    Custom sign-in URL

    In the Custom sign-in URL field, specify a custom sign-in URL. However, if you are using a default login page provided by IAM, then leave this field blank.
    Custom sign-out URL

    In the Custom sign-out URL field, specify a custom sign-out URL. However, if you are using a default login page provided by IAM, then leave this field blank.
    Custom error URL

    This is an optional field. Enter the error page URL to which a user has to be redirected, if there is a failure. If not specified, the tenant-specific Error page URL is used. If both the error URLs are not configured, then the error is redirected to the IAM Error Page (/ui/v1/error).

    When a user tries to use social authentication (ex: Google, Facebook, and so on) for logging into IAM, the callback URL must be configured in the Custom Error URL field. Social providers need this callback URL to call IAM and send the response back after social authentication. The provided callback URL is used to verify whether the user exists or not (if this is a first-time social login), and display an error if the social authentication has failed. This is the URL where the callback is sent with social registration user details, if a successful logged-in social user account does not exist in IAM.
    Custom social linking callback URL

    This is an optional field. Enter the URL that IAM can redirect to after linking of a user between social providers and IAM is complete.

    When you create a custom app using IAM custom SDK and integrate with IAM Social Login, the custom app needs to have the Linking callback URL which can be redirected after linking of the user between social provider and IAM is complete.
    Display in My Apps

    Select the check box if you want the confidential application to be listed for users on their My Apps pages. In this case, you need to configure the application as a resource server.

    When you select the Display in My Apps check box in applications, the app is then visible in the My Apps page, but selecting this check box doesn’t enable or disable SSO to the app.

    The flag to enable or disable SSO comes from the app template.
    User can request access

    Select the check box if you want end users to be able to request access to the app from their My Apps page by clicking Add Access. If self-service is not enabled, users won’t see the Add Access button.

    For Confidential apps: Enforce grants as authorization

    For Enterprise apps: User must be granted this app

    If you want IAM to control access to the application based on grants to users and groups, select this option. If you clear this option, any authenticated user has access to the application.
  5. Click Next.
  6. On the Configure OAuth pane, to protect resources for your application now, and to make the application visible on the My Apps page, click Configure this application as a resource server now
    Use the following table to provide the information needed to configure this application as a resource server.
    Option Description
    Access token expiration (seconds)

    Define how long (in seconds) the access token associated with your confidential application remains valid.
    Allow token refresh

    Select this check box if you want to use the refresh token that you obtain when using the Resource Owner, Authorization Code, or Assertion grant types.
    Refresh token expiration (seconds)

    Define how long (in seconds) the refresh token, which is returned with your access token and is associated with your confidential application, remains valid.
    Primary audience

    Enter the primary recipient where the access token of your confidential application is processed.
    Add secondary audience

    Enter the secondary recipients where the access token of your confidential application is processed, and click Add. The secondary recipient appears in Secondary audience column, and the Protected column allows you to know whether the secondary audience is protected or not.
    Add scopes

    To specify which parts of other applications that you want your application to access, add those scopes to your confidential application.

    Applications must interact securely with external partner or confidential applications. Also, applications from one Oracle Cloud service must interact securely with applications in another Oracle Cloud service. Each application has application scopes that determine which of its resources are available to other applications.
  7. On the Configure OAuth pane, click Configure this application as a client now.
    Use the following table to provide the information needed to configure this application as a client.
    Option Description
    Resource owner Use when the resource owner has a trust relationship with the confidential application, such as a computer operating system or a highly privileged application, because the confidential application must discard the password after using it to obtain the access token.
    Client credentials

    Use when the authorization scope is limited to the protected resources under the control of the client or to the protected resources registered with the authorization server.

    The client presents its own credentials to obtain an access token. This access token is either associated with the client’s own resources, and not a particular resource owner, or is associated with a resource owner for whom the client is otherwise authorized to act
    JWT assertion

    Use when you want to use an existing trust relationship expressed as an assertion and without a direct user approval step at the authorization server.

    The client requests an access token by providing a user JSON web token (JWT) assertion or a third-party user JWT assertion and client credentials. A JWT assertion is a package of information that facilitates the sharing of identity and security information across security domains.
    SAML2 assertion

    Use when you want to use an existing trust relationship expressed as a SAML2 assertion and without a direct user approval step at the authorization server.

    The client requests an access token by providing a user SAML2 assertion or a third-party user SAML2 assertion and client credentials. A SAML2 assertion is a package of information that facilitates the sharing of identity and security information across security domains.
    Refresh token Select this grant type when you want a refresh token supplied by the authorization server, and then use it to obtain a new access token. Refresh tokens are used when the current access token becomes invalid or expires and don’t require the resource owner to reauthenticate.
    Authorization code

    Select this grant type when you want to obtain an authorization code by using an authorization server as an intermediary between the client application and resource owner.

    An authorization code is returned to the client through a browser redirect after the resource owner gives consent to the authorization server. The client then exchanges the authorization code for an access (and often a refresh) token. Resource owner credentials are never exposed to the client.
    Implicit

    If the application can't keep client credentials confidential for use in authenticating with the authorization server, then select this check box. For example, your application is implemented in a web browser using a scripting language such as JavaScript. An access token is returned to the client through a browser redirect in response to the resource owner authorization request (rather than an intermediate authorization).
    Device code

    Select the Device Code grant type if the client doesn't have the capability to receive requests from the OAuth Authorization Server, for example, it cannot act as an HTTP server such as game consoles, streaming media players, digital picture frames, and others.

    In this flow, the client obtains the user code, device code, and verification URL. The user then accesses the verification URL in a separate browser to approve the access request. Only then can the client obtain the access token using the device code.
    TLS client authentication

    Select the TLS Client Authentication grant type to use the client certificate to authenticate with the client. If a token request comes with an X.509 client certificate and the requested client is configured with the TLS Client Authentication grant type, the OAuth service uses the Client_ID in the request to identify the client and validate the client certificate with the certificate in the client configuration. The client is successfully authenticated only if the two values match.

    For added security, before enabling the TLS Client Authentication grant type, enable and configure OCSP validation and import a trusted partner certificate.

    Allow HTTP URLs

    Select this check box if you want to use HTTP URLs for the Redirect URL, Logout URL, or Post logout redirect URL fields. For example, if you are sending requests internally, want a non-encrypted communication, or want to be backward-compatible with OAuth 1.0, then you can use an HTTP URL.

    Also, select this check box when you are developing or testing your application and you might not have configured SSL. This option is not recommended for production deployments.
    Redirect URL

    Enter the application URL where the user is redirected after authentication.

    Note: Provide an absolute URL. Relative URLs are not supported.
    Post-logout redirect URL

    Enter the URL where you want to redirect the user after logging out of the application.
    Logout URL

    Enter the URL where the user is redirected after logging out of the confidential application.
    Client type

    Select the client type. The available client types are Trusted and Confidential. Choose Trusted if the client can generate self-signed user assertions. Then, to import your signing certificate that the client uses to sign its self-signed assertion, click Import certificate.
    Allowed operations

    • Select the Introspect check box if you want to allow access to a token introspection end point for your application.

      If the confidential application can't keep client credentials confidential for use in authenticating with the authorization server, then select this check box. For example, your confidential application is implemented in a web browser using a scripting language such as JavaScript.

      An access token is returned to the client through a browser redirect in response to the resource owner authorization request (rather than an intermediate authorization code).

    • Select the On behalf of check box if you want to ensure that access privileges can be generated from the user's privileges alone. This allows the client application to access endpoints to which the user has access, even if the client application by itself would not normally have access.
    ID token encryption algorithm

    Select one of the content encryption algorithms.
    Bypass consent

    If enabled, this attribute overwrites the Require consent attribute for all the scopes configured for the application, and then no scope will require consent.
    Client IP address
    • Anywhere: The token request is allowed from anywhere. There is no perimeter.
    • Restrict by network perimeter: Select the network perimeters so that a token request is only allowed from them.
    Authorized resources

    Select one of the following options to allow a client application to access authorized resources:

    Note: The option to define an authorized resource is available to only Confidential applications. Trust scope cannot be defined for Mobile applications.
    Add resources

    If you want your application to access APIs from other applications, then check Add resources in the Token issuance policy section. Then, in the Add scope window, select the applications that your application references.

    Note: You can delete scopes by clicking the x icon next to the scope. However, you can’t delete scopes that are protected.
    Add app roles

    Check Add app roles. In the Add app roles window, select the application roles that you want to assign to this application. This enables your application to access the REST APIs that each of the assigned application roles can access.

    For example, select Identity Domain Administrator from the list. All REST API tasks available to the identity domain administrator will be accessible to your application.

    You can delete the application roles by selecting the application role and then clicking Remove.

    Note: You can’t delete protected application roles.
  8. Click Next.
  9. Configure single sign-on.
  10. Click Activate, and then click Activate application.
Configuring SSO Resources

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 give anyone to access. You need the list of resources of your application. See Enterprise Applications

Policy mapping is hierarchical in App Gateway. So, order of the resources defined is important. See the following example:

If the user is accessing a resource /myapp/logout.html, and we have authentication policy in below order:
  1. /.* (public)
  2. /.*/logout.html (Form+logout)
Then policy match stops at step #1 (/.*) and the same policy is applied which is "public" in this case.
Similarly, if user is accessing a resource /myapp/logout.html and we have authentication policy in below order.
  1. /.*/logout.html (Form+logout)
  2. /.* (public)
In this case, policy match stops at point 1 (/.*/logout.html) and same policy is applied which is "Form+logout".

Something else to be aware of is that applications which do their own login integrations can run into problems when their integrations accessed static resources during login, but the resources were not made public. This causes the login process to fail. To avoid this happening, you should use the public authentication method for your public static resources such as CSS, JavaScript, image files as follows:

  • Group all public static resources together, for example under /myapp/public/resources.

  • State that these directories should use the public authentication method using a regex such as /myapp/public/.*.

To configure resources:

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the enterprise application that you want to modify.
  3. In the Application details page, click SSO configuration, and then click Edit SSO configuration. In the Resources section, click Add resource to add a resource.
  4. In Add resource, provide a name and description for the resource and the resource URL. Optionally, add a URL query string. If you want to use a regular expression, 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 Using Regular Expressions.

  5. Click Add resource.
  6. Click Save changes.
Configuring an SSO 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 adds header variables to the request it forwards to the application.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the enterprise application that you want to modify.
  3. In the Application details page, click SSO configuration, and then click Edit SSO configuration. In the Authentication policy section, Check Audience validation, Allow CORS, or Require secure cookies, if needed.
    • Audience validation: For security reasons, ensure the Audience validation check box is selected. The audience validation check box is used to ensure that the token has the been issued by App Gateway's known issuer, in this case IAM. If you clear audience validation, App Gateway won't validate the audience of the token, which makes the application vulnerable to attacks.
    • Allow CORS: Select to enable Cross-Origin Resource Sharing (CORS) so that applications that run on one identity domain can obtain data from another identity domain.
    • Require secure cookies: 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.
  4. Check Add managed resources.
  5. In the Add managed 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 or add a managed resource.
  6. Use the following table to define the Authentication method for the resource you have selected:

    Authentication Method

    Description

    Basic Auth

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

    The credentials sent in the header are in the AuthenticationBasic validated in IAM.

    Basic Auth+Logout

    This method is used to protect the application's resource (URL) that represents the application's logout 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.

    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 IAM.

    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 IAM 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 reauthentication themselves.

    Form+Logout

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

    This resource's URL doesn't need to be exposed by the application, as App Gateway redirects the user browser to the IAM 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 out the user. 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.
  7. 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.
  8. If you want to add a 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 application knows the ID of user signed in to IAM. You must add one header variable, enter USERLOGGEDIN for the Name field, and then either select User name from the list or enter $subject.user.userName for Value.

    Note

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

  9. Click Add managed resource.
  10. Click Save changes.
Configuring an SSO 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.

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 IAM 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. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the enterprise application that you want to modify.
  3. In the Application details page, click SSO configuration, and then click Edit SSO configuration.
  4. In the Authorization policy section, select Time to live (minutes) to define for how long App Gateway caches any authorization policy evaluation that has been performed.
    By caching these policy evaluations, App Gateway doesn't need to communicate with IAM in subsequent HTTP request made by the user for the same resource.
  5. In the Allow rules section, click Add allow rule, specify a Rule name, and then complete the following fields.
    Add Allow Rule Options

    Conditions

    Description

    Resource to include

    Select one of the resources configured in the enterprise application.

    HTTP Method

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

    Authenticating identity provider

    Select the identity providers that are active in IAM. 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 IAM.

    Group membership

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

    Exclude users

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

    Filter by client IP address

    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.
    • Restrict to the following 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.

    Restrict access time period

    Select a time of the day (From and To), select which days of the week, and then the time zone 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.
  6. In the Actions section of the Add allow rule window, click +Another Header, enter the 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.
  7. Click Add allow rule to add the allow rule.
  8. In the Deny rules section, click Add deny rule, specify a Rule name, and then complete the following fields.
    Add Deny Rule Options

    Conditions

    Description

    Resource to include

    Select one of the resources configured for the enterprise application.

    HTTP Method

    Select the HTTP Methods to associate with this rule.

    Authenticating identity provider

    Select identity providers that are active in IAM. 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 IAM.

    Group membership

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

    Exclude users

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

    Filter by client IP address

    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.
    • Restrict to the following 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.

    Restrict access time period

    Select a time of the day (From and To), select which days of the week, and then the time zone 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.
  9. 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.
    • Sign out the user: Logs the user out from IAM.
  10. Click Add deny rule to add the deny rule.
  11. Click Save changes.
Using 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.

The following is a list of common operators supported by App Gateway's authorization engine:
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 one or more characters 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.
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 predefined 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 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 IAM.

    Format: $subject.client.<attr>

  • User: This attribute identifier accesses information of the user signed in to IAM.

    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>

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:

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 IAM.

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, and so on) 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 application. 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 IAM'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 IAM.

Used by all authentication method.
idcs_client_id

The Client ID value for the App Gateway registered in IAM.

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 one or two steps.

If the user has signed in with IAM using their credentials only, then the authentication strength 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 IAM.

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 IAM.

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 IAM 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 IAM 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 IAM.

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 IAM.

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 IAM.

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

IAM 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 IAM, App Gateway sets this cookie to the request forwarded to the application.

The cookie name is composed by ORA_OCIS_CG_SESSION prefix, concatenated with IAM's tenant name, and suffixed 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.
Adding Tags to an Application

You're an identity domain administrator or application administrator who wants to create custom attributes for your applications that can be used to search for the applications more effectively. To do this, you add tags to your applications. Tags are key-value pairs that are used to organize and identify applications.

For example, suppose you're creating three versions of an application: one for development purposes, one for testing purposes, and one that will be used in production. You can create the following tags for these versions: Version: Development; Version: Testing; and Version: Production.

You can create new tags for your confidential, mobile, SAML, enterprise, and app catalog applications using the Tags tab in the Details pane. You can use these tags to identify and organize your applications.
Note

You can delete tags by clicking the X icon next to the tag. However, some tags are protected and cannot be deleted.
  1. In the Tags area of the Details pane, click Add Tags.
  2. Choose a Tag Namespace or leave the namespace as None to add a free-form tag. See Tags and Tag Namespace Concepts.
  3. In the Tag Key and Tag Value fields of the Add Tags window, enter or select the key-value pair for the tag you're creating.
  4. (Optional) To create more tags, click +Another Tag, and repeat the process.
  5. Click Add Tags.
Assigning Applications to a User Using Account Form

Account Form will be visible in the user interface with account attributes for a provisioning application if the underlying App Template supports it. With Account Form, when you grant a provisioning application to a user, you can provide account values and when you edit a provisioned account, you can update existing account values.

To provide specific values using account form:
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Under Resources, select User and click Assign users.
  4. In the Assign users window, for the user who needs access to the application, click Assign from the Actions menu for that user.
  5. Click Next.
  6. (Optional) Add a path.
  7. Click Assign user. The user account is assigned.
  8. Select the next user you want to provide access to this application and repeat the steps 1 through 7.
Creating a Custom Secure Form Fill App

Custom secure form fill apps give you the flexibility to define tenant-level form fill apps that are not in the global Oracle App Catalog.

Secure Form Fill is the IAM alternative for single sign-on into apps that require auto-form fill but don't support OAuth, SAML, or federated sign-on methods.

Users enter their application credentials for form-fill-enabled apps in IAM once. IAM stores and encrypts the information, and automatically fills in the login form so that users can sign in without having to reenter the information each time.

IAM stores the user's credentials in an encrypted format using strong encryption combined with a customer-specific private key. When a user opens the secure form fill application, which in turn prompts the login page, IAM detects and securely fills the user's credentials, submits the credentials to the app login page, and then the user is automatically signed in.

Prerequisites for Creating a Custom Secure Form Fill App

Learn the prerequisites for creating a custom secure form fill app.

Ensure that you have the following prerequisites in place before creating and testing a secure form fill app.
  • A Windows operating system version 7, 8 or 10 with:

    • Local admin rights enabled

    • 32-bit Java Runtime Environment (JRE) to access local help content for the Secure Form Fill Admin Client.

  • At least one of the following supported desktop browsers:

    • Mozilla Firefox

    • Google Chrome

  • Secure Form Fill Admin Client. See Install the Secure Form Fill Admin Client.

    Note

    The ESSO Administrative Console is part of the Secure Form Fill Admin Client.

  • Administrator privileges for an identity domain. See Understanding Administrator Roles.

Installing the Secure Form Fill Admin Client

You use the Secure Form Fill Admin Client (Oracle Enterprise Single Sign-On (ESSO) Administrative Console) to create and update secure form fill configuration files for your custom secure form fill apps in IAM. Use these instructions to install the Secure Form Fill Admin Client.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Settings and then Downloads.
  2. On the Download page, locate the Secure Form Fill Admin Client and download it. See Downloading SDKs and Applications.
    Note

    The ESSO Administrative Console is part of the Secure Form Fill Admin Client.
  3. In the download location, unzip the file.
  4. Double-click the installer to launch the install wizard, and then click Next.
  5. Choose the Complete installation option, click Next, and then click Install.
  6. When the installation completes, click Finish.
    Note

    This documentation explains, at a high level, how to use the ESSO Administrative Console only as it pertains to custom secure form fill apps and IAM. For additional instructions, see the help in the ESSO Administrative Console.
Creating a Secure Form Fill Configuration File

You use the Secure Form Fill Admin Client (Oracle Enterprise Single Sign-On (ESSO) Administrative Console) to create secure form fill configuration files for your custom secure form fill apps in IAM. Use these instructions to create secure form fill configuration files and then import those files into IAM.

Install the Secure Form Fill Admin Client. See Install the Secure Form Fill Admin Client.
Note

This documentation explains, at a high level, how to use the Secure Form Fill Admin Client only as it pertains to custom secure form fill apps and IAM. For additional instructions, see the help in the ESSO Administrative Console.
  1. Launch the Secure Form Fill Admin Client.
  2. Right-click Applications, and then choose New Web App. Alternatively, use any of the following options:
    • Click Applications, Add, and then choose Application Type: Web in the first pane of the wizard.
    • Choose Insert, Application, and then choose Application Type: Web in the first pane of the wizard.
  3. On the Add Application dialog, enter the name of the application.
    Important

    The application name must be the same name that you use when you create the secure form fill application in IAM.
  4. Leave all other default options selected, and then click Finish.
  5. Choose the Logon form type. This form is used to set up your Web app template.
    Note

    No other form type is supported.
  6. In the Address field, enter the URL for the Web app, click Go, and then navigate to the login page.
    A list of all fields on the login page appear on the bottom of the screen. Select any field in the list on the bottom of the screen to highlight the field on the page.
  7. Using the fields on the bottom of the screen, complete the following steps:
    Note

    Do no use the Third Field or Fourth Field options.

    Do not use the Allow multiple field designation option.

    Only use ordinals if field names or attribute level matching is not possible. Using ordinals is less amenable to page changes or differences across browsers, and are not recommended in most scenarios.

    1. Select the user name field, right-click, and then choose Username/ID.
    2. Select the password field, right-click, and then choose Password.
    3. Select the submit button, right-click, and then choose Submit.
  8. Click OK.
  9. On the Web dialog, make any of the following changes as necessary.
    Option Description

    Identification Tab

    Click Edit to make changes. This is the URL or the URLs of the form to configure. For applications that have varying text in their URLs, you can use substrings or regular expressions to specify how to match the variable text.

    Your Match Type change options are:

    • Exact Match. Exact match matches a URL exactly as specified. This is generally an edge case and rarely used.

    • Wildcards.
      • ? matches any single character.

      • * matches zero or more occurrences of any character. If wild cards are used, to avoid a potential security issue, do not perform mid-string wildcard matches. Always exact match the start of the URL, for example, https://server?.somesite.com/*.

    • Regular Expressions. This is the recommended option. Use the set of regular expressions to specify a string pattern that the form-fill agent should recognize as a match, for example, URL1=.*?https://www\.expedia\.co\.jp/user/login.*

    Fields Tab

    Click a field, and then using the Edit button, adjust the primary form fields used for detection and injection of the user name and password fields as well as the submit button.

    Note:

    Do not use the SendKeys or the SendKeys using journal hook options.

    Check each field type to ensure that it is the appropriate type (such as Password for password input fields, and so on).

    Your Field options are:
    • Field Identification. Allows you to fine-tune how the input fields for the form are located. Field identification can be adjusted for any form field. Click the ellipsis to display the Field identification options. Identify fields by:

      • Name. The default and recommended option. Beware that not every input field has a name or sometimes the name is not consistent every time the page is loaded. If so, then it's recommended to use the Matching option.

      • Ordinal. This option identifies fields based on sequence. This option is not the recommended alternative since it is easily impacted by minor changes to the page. Also, the fields and the field ordinals can be inconsistent across browsers.

      • Matching. Identifies fields based on tag types, attribute values, HTML, and so on. This option is the recommended option if Name is not possible. Often, matching is used to match the “id” attribute of the input field or a regex on the name attribute. Matching can be a regex, substring match, or whole string match.

    • Events. Pre Inject and Post Inject events allow secure form fill to trigger a specific event on the field before and after injecting the credentials into that field. This is useful as some fields will not recognize that injection has occurred unless a specific event is triggered in that field. Event values are: blur, change, click, focus, focusin, focusout, input, keydown, keypress, keyup, and mouseover.

    Matching Tab

    Create or modify granular page matching criteria for the selected web form.

    Secure Form Fill in IAM uses the matching criteria you supply here to distinguish among similar forms.

    Matching can also be used to refine the detection match criteria, that is, the set of HTML tags and values you use to identify a specific field to perform more specific matching beyond just the form fields themselves.

    Proxy Tab

    Do not change these settings.
  10. Click OK.
  11. Use the following tabs to make any necessary changes:
    Note

    Do not change any other options on any other sub tabs other than those listed in the table below.
    Option Description

    General Tab

    Enter a description for the Web app.

    Add, edit, or delete forms. This option allows you to set all the forms relevant for this Web app. Use this option if you have multiple login forms for your Web app.

    All other settings are not required for secure form fill and should not be changed.

    Error Loop Tab

    Secure form fill supports the detection of an error loop condition. Error loop conditions generally occur if secure form fill has the wrong credentials for the Web app and attempts to submit these credentials repeatedly to the Web app.

    • Logon timeout (sec.). The maximum time in seconds between successive logon attempts before a logon error is triggered.

    • Max. retries. The maximum number of retries (after first try) allowed before a logon error is triggered.

    Miscellaneous Tab

    • Logon Loop Grace Period. Allows control over the response during login grace period (for example, controls reinjection).

    • Auto-submit. Use this option to turn auto-submit on or off for all forms used by the app.
  12. Click File, and then Save.
    Tip

    Name the Web app file, the *.ini file, and the name of the IAM app with the same name.
  13. To export the file, click File, Export, select the application to export, and then click OK.
  14. Name the file.
    Important

    The *.ini file name must match the name of the application created in IAM.
Post requisite: Create an IAM secure form fill app.
Creating a Secure Form Fill App

After you create a configuration file in the Oracle Enterprise Single Sign-On (ESSO) Administrative Console, the next step is to create a secure form fill app.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click Add application, and then click Application Catalog.
  3. In the Filters section for the Type of integration, click Secure form fill, locate Generic Secure FormFill App Template, and then select it.
  4. Complete the application details by entering a Name, Description, and Application URL.
    Important

    The application name must match the file name of the .ini file created in the ESSO Administrative Console.

  5. In the URLs section, add any necessary URLs.
  6. In the Display settings section, select Display in My Apps.
    Important

    If you do not select Display in My Apps, the application does not display in the My Apps page for users.

    When you select the Display in My Apps check box in applications, the app is then visible in the My Apps page, but selecting this check box doesn’t enable or disable SSO to the app.

  7. Select the User can request access check box, if you want the app to be listed in the Catalog. This option allows end users to request access to applications from their My Apps page by clicking Add and then selecting the app from the Catalog.
  8. Select User can view their credentials if you want users to view their credentials in My Profile.
  9. Click Create application.
  10. Click Import to import the secure form fill configuration file that you created in the ESSO Administrative Console.
    The application has been added in deactivate state. To activate your application, click Activate next to the app name.
  11. To assign users to the application, click Users.
    Tip

    Assign the application to yourself or a test user. This saves you time when testing the secure form fill app.
  12. To assign groups to the application, click Groups.
The applications you assign to the user or group displays on the My Apps page. Newly assigned applications and applications that a user has not yet accessed appear first in the application list and have an asterisk icon in the application tile. The icon appears on the tile until the user accesses the application.
Installing and Using the Secure Form Fill Plugin

Install the Oracle Secure Form Fill Plugin so that you can launch secure form fill apps. Once installed, you are able to access My Apps from your browser toolbar.

Installing the Google Chrome Plugin

If you are using Google Chrome and you need to install the plugin, you are prompted to go to the Extensions on Google Chrome and install the Oracle Secure Form Fill Plugin from the IAM user interface. You will be prompted to download the plugin from the My Apps page the first time that you access to a secure form fill app.

Installing the Mozilla Firefox Plugin

If you are using Mozilla Firefox and you need to install the plugin, instead of downloading the Secure Form Fill Mozilla Firefox plug-in from the Mozilla Store, install the Secure Form Fill Mozilla Firefox plug-in from the My Apps page. You will be prompted to download the plug-in from the My Apps page the first time that you access to a secure form fill app.

Accessing My Apps from the browser using the plugin

After you install the Oracle Secure Form Fill Plugin, when you are logged in to IAM you can access My Apps from your browser toolbar.

Search for apps and see favorite apps by clicking the My Apps Image of the My Apps icon as it appears on the browser toolbar. icon.

Testing a Custom Secure Form Fill App

After you create a custom secure form fill app in an identity domain, test the app before deploying it to your organization.

  • A custom secure form fill app created in the identity domain.

  • The custom secure form fill app is set to display on the My App page.

  • The custom secure form fill app is assigned to you as a user or as a group.

  1. Sign in to the identity domain console to access the My Apps page.
  2. Install the secure form fill plug in, if you have not already installed it, and then refresh your browser.
  3. Open the app, enter the credentials for the application, and then click Login.

A successful result is IAM injecting the user name and password, and then clicking the submit button.

If you are having issues, check the settings for your Web app in the Oracle Enterprise Single Sign-On (ESSO) Administrative Console, export the *.ini file if necessary, check the settings for your app in the identity domain, and try again.

Updating a Custom Secure Form Fill App

To update a custom secure form fill app, you first update the Web app using the Secure Form Fill App, export the configuration file in (*.ini), and then update the custom secure form fill app in the identity domain.

  1. If you need to update the Web app and configuration file created in Secure Form Fill Admin Client, update the Web app first, and then save and export the file. See Create a Secure Form Fill Configuration File.
  2. To change the custom secure form fill app, access the application as an Identity domain administrator, make any necessary changes, import the new configuration file (if necessary), and then save the app. See Create a Secure Form Fill App in IAM.
Test your new configuration. See Test a Custom Secure Form Fill App.
Importing and Synchronizing Users in Applications

You can import and synchronize users of third-party cloud applications using a flat file and manage them in an identity domain.

Importing Users into Applications

You can perform a full sync import of the users of third-party Cloud applications using a flat file. In a full sync import, the imported user in the CSV file replaces any existing user who is already assigned to the application.

  1. Create a CSV file for import in the following format or download the CSV file along with user data from the target system apps: 
    ID, NAME, ACTIVE
hercule.poirot@sampleapp.com,hercule.poirot@sampleapp.com,true

    This table provides a description of the attributes in the CSV format file:

    Attribute Name

    Description

    Sample Value

    ID

    The unique identifier of the account in the target.

    hercule.poirot@sampleapp.com

    NAME

    The name of the account.

    NAME is the primary input that is matched with the username of a particular user in IAM>.

    hercule.poirot@sampleapp.com

    ACTIVE

    The status of the account on the target. The possible values are true and false.

    If the value is true, the user account is imported and activated. If the value is false, the user is imported in a deactivated state.

    true
  2. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  3. Click the application that in which you want to import users.
  4. Click Import.
  5. Browse for the CSV file, and import it.
    Note

    Import from CSV file is enabled for applications that support flat file synchronization.
  6. Refresh the page to view the import result. If the import succeeds, then the users present in the CSV file displays.
  7. Select Users to view the imported users.
    Note

    Refresh the Users tab to view the imported users.
  8. Observe that the users with a true value for ACTIVE attribute are activated. However, if a user account has false value for ACTIVE attribute, the user account is imported in a deactivated state.
    Note

    The Users tab displays only the matched and confirmed users.
  9. Synchronize the imported users. See Synchronizing Imported User Accounts to synchronize the imported user accounts with the users in an identity domain.
Synchronizing Imported User Accounts

After you import the users, if a matching user account doesn’t exist in the identity domain, you can either assign the user account to an existing user or create a new user for the user account.

If the imported user account exists, an exact match is found and no further action is required. The synchronization status of the user account is set as confirmed.

Assigning an Existing User

You can assign an existing user to the imported user account in the Import tab if the user is present in IAM and the import failed to match the user.

  1. On the row of the imported user, select Assign existing user from the Actions menu.
  2. In the Assign user window, search for an existing user, select the required user and click Assign.
The user account is manually linked to the existing user and the synchronization status is confirmed.
Managing synchronized users

You can activate, deactivate, assign, and revoke imported users from the Users tab.

You can perform the following actions on the synchronized users:

  • To activate an imported user account, select the Actions menu, and click Activate.

  • To deactivate an imported user account, select the Actions menu, and click Deactivate.

  • To remove any imported user account, select the user, and click Revoke.

  • To assign any other user to the application apart from the synchronized users from the flat file, click Assign. Choose a user from the list of existing users and click OK. The assigned user account is displayed and is in an activated state.

Configuring OAuth

Configure the your Enterprise or Confidential application to act as a confidential application by providing client and resource server configurations.

  1. On the Configure OAuth pane, to protect resources for your application now, and to make the application visible on the My Apps page, click Configure this application as a resource server now
    Use the following table to provide the information needed to configure this application as a resource server.
    Option Description
    Access token expiration (seconds)

    Define how long (in seconds) the access token associated with your confidential application remains valid.
    Allow token refresh

    Select this check box if you want to use the refresh token that you obtain when using the Resource Owner, Authorization Code, or Assertion grant types.
    Refresh token expiration (seconds)

    Define how long (in seconds) the refresh token, which is returned with your access token and is associated with your confidential application, remains valid.
    Primary audience

    Enter the primary recipient where the access token of your confidential application is processed.
    Add secondary audience

    Enter the secondary recipients where the access token of your confidential application is processed, and click Add. The secondary recipient appears in Secondary audience column, and the Protected column allows you to know whether the secondary audience is protected or not.
    Add scopes

    To specify which parts of other applications that you want your application to access, add those scopes to your confidential application.

    Applications must interact securely with external partner or confidential applications. Also, applications from one Oracle Cloud service must interact securely with applications in another Oracle Cloud service. Each application has application scopes that determine which of its resources are available to other applications.
  2. On the Configure OAuth pane, click Configure this application as a client now.
    Use the following table to provide the information needed to configure this application as a client.
    Option Description
    Resource owner Use when the resource owner has a trust relationship with the confidential application, such as a computer operating system or a highly privileged application, because the confidential application must discard the password after using it to obtain the access token.
    Client credentials

    Use when the authorization scope is limited to the protected resources under the control of the client or to the protected resources registered with the authorization server.

    The client presents its own credentials to obtain an access token. This access token is either associated with the client’s own resources, and not a particular resource owner, or is associated with a resource owner for whom the client is otherwise authorized to act
    JWT assertion

    Use when you want to use an existing trust relationship expressed as an assertion and without a direct user approval step at the authorization server.

    The client requests an access token by providing a user JSON web token (JWT) assertion or a third-party user JWT assertion and client credentials. A JWT assertion is a package of information that facilitates the sharing of identity and security information across security domains.
    SAML2 assertion

    Use when you want to use an existing trust relationship expressed as a SAML2 assertion and without a direct user approval step at the authorization server.

    The client requests an access token by providing a user SAML2 assertion or a third-party user SAML2 assertion and client credentials. A SAML2 assertion is a package of information that facilitates the sharing of identity and security information across security domains.
    Refresh token Select this grant type when you want a refresh token supplied by the authorization server, and then use it to obtain a new access token. Refresh tokens are used when the current access token becomes invalid or expires and don’t require the resource owner to reauthenticate.
    Authorization code

    Select this grant type when you want to obtain an authorization code by using an authorization server as an intermediary between the client application and resource owner.

    An authorization code is returned to the client through a browser redirect after the resource owner gives consent to the authorization server. The client then exchanges the authorization code for an access (and often a refresh) token. Resource owner credentials are never exposed to the client.
    Implicit

    If the application can't keep client credentials confidential for use in authenticating with the authorization server, then select this check box. For example, your application is implemented in a web browser using a scripting language such as JavaScript. An access token is returned to the client through a browser redirect in response to the resource owner authorization request (rather than an intermediate authorization).
    Device code

    Select the Device Code grant type if the client doesn't have the capability to receive requests from the OAuth Authorization Server, for example, it cannot act as an HTTP server such as game consoles, streaming media players, digital picture frames, and others.

    In this flow, the client obtains the user code, device code, and verification URL. The user then accesses the verification URL in a separate browser to approve the access request. Only then can the client obtain the access token using the device code.
    TLS client authentication

    Select the TLS Client Authentication grant type to use the client certificate to authenticate with the client. If a token request comes with an X.509 client certificate and the requested client is configured with the TLS Client Authentication grant type, the OAuth service uses the Client_ID in the request to identify the client and validate the client certificate with the certificate in the client configuration. The client is successfully authenticated only if the two values match.

    For added security, before enabling the TLS Client Authentication grant type, enable and configure OCSP validation and import a trusted partner certificate.

    Allow HTTP URLs

    Select this check box if you want to use HTTP URLs for the Redirect URL, Logout URL, or Post logout redirect URL fields. For example, if you are sending requests internally, want a non-encrypted communication, or want to be backward-compatible with OAuth 1.0, then you can use an HTTP URL.

    Also, select this check box when you are developing or testing your application and you might not have configured SSL. This option is not recommended for production deployments.
    Redirect URL

    Enter the application URL where the user is redirected after authentication.

    Note: Provide an absolute URL. Relative URLs are not supported.
    Post-logout redirect URL

    Enter the URL where you want to redirect the user after logging out of the application.
    Logout URL

    Enter the URL where the user is redirected after logging out of the confidential application.
    Client type

    Select the client type. The available client types are Trusted and Confidential. Choose Trusted if the client can generate self-signed user assertions. Then, to import your signing certificate that the client uses to sign its self-signed assertion, click Import certificate.
    Allowed operations

    • Select the Introspect check box if you want to allow access to a token introspection end point for your application.

      If the confidential application can't keep client credentials confidential for use in authenticating with the authorization server, then select this check box. For example, your confidential application is implemented in a web browser using a scripting language such as JavaScript.

      An access token is returned to the client through a browser redirect in response to the resource owner authorization request (rather than an intermediate authorization code).

    • Select the On behalf of check box if you want to ensure that access privileges can be generated from the user's privileges alone. This allows the client application to access endpoints to which the user has access, even if the client application by itself would not normally have access.
    ID token encryption algorithm

    Select one of the content encryption algorithms.
    Bypass consent

    If enabled, this attribute overwrites the Require consent attribute for all the scopes configured for the application, and then no scope will require consent.
    Client IP address
    • Anywhere: The token request is allowed from anywhere. There is no perimeter.
    • Restrict by network perimeter: Select the network perimeters so that a token request is only allowed from them.
    Authorized resources

    Select one of the following options to allow a client application to access authorized resources:

    Note: The option to define an authorized resource is available to only Confidential applications. Trust scope cannot be defined for Mobile applications.
    Add resources

    If you want your application to access APIs from other applications, then check Add resources in the Token issuance policy section. Then, in the Add scope window, select the applications that your application references.

    Note: You can delete scopes by clicking the x icon next to the scope. However, you can’t delete scopes that are protected.
    Add app roles

    Check Add app roles. In the Add app roles window, select the application roles that you want to assign to this application. This enables your application to access the REST APIs that each of the assigned application roles can access.

    For example, select Identity Domain Administrator from the list. All REST API tasks available to the identity domain administrator will be accessible to your application.

    You can delete the application roles by selecting the application role and then clicking Remove.

    Note: You can’t delete protected application roles.
  3. Click Save changes.
Deleting Applications

You can use IAM to delete multiple applications simultaneously.

Deactivate all applications that you want to delete.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Select the check box for each application that you want to delete, or to delete all applications, select the select all check box in the heading row of the table.
  3. Select Actions, Delete, then Delete application.
    Note

    You cannot delete an Oracle Public Cloud application from the UI. You will encounter an error if you try removing any Oracle Public Cloud application.
Activating Applications

Activating applications reinstates the access rights to applications for users and groups.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Select the check box for each deactivated application that you want to activate.
  3. Select Actions, Activate, and then Activate application.
Deactivating Applications

Deactivating an application temporarily disables the access rights to applications that users or groups have.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.Select the identity domain you want to work in and click Applications.
  2. Select the check box for each activated application that you want to deactivate.
  3. Select Actions, Deactivate, and then Deactivate application.
Viewing Details About Applications

By default, you can see the name and description for each application in IAM.

By clicking an application name, you can view high-level and configuration information about the application. For Oracle applications, you can also see the roles associated with the application, and the IAM groups and users assigned to the application.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application name for which you want additional information.
    Tip

    To search for applications, enter all or part of the beginning of the application name that you want to locate in the search field, and then press Enter. To fine-tune your search, click the search field again, and then select a status.
  3. To view high-level information about the application, such as the application type, name, description, icon, URL, links, and whether the application will appear on the My Apps page, click Details.
  4. To view configuration information about the application, click Configuration. For custom SAML applications, this tab is labeled SSO configuration because, by granting SAML applications to users, they can single sign-on (SSO) into SaaS applications that support SAML for SSO. See Add a Confidential Application, Add a Mobile Application, and Add a SAML Application.
  5. For Oracle applications, to view roles associated with the application, click Application roles. You can assign users and groups to an application role or remove users and groups from the application role. See Modifying Oracle and Custom Applications.
  6. For Oracle applications, to view the names and descriptions of any groups assigned to the application, click Groups.
  7. For Oracle applications, to view the names, email addresses, and phone numbers of any users assigned to the application, click Users. You can filter and sort this list of users.
    • To display only those users who are assigned to a particular application role, click Show, and then select the application role.
    • To display users who are assigned to any application role, click Show, and then select All role members.
    • To sort the users in ascending order by their names or email addresses, click Sort By, and then select Name or Email.
Modifying Oracle and Custom Applications

After configuring, you can modify Oracle and custom applications to assign users and groups, edit high-level information, import users and groups into the applications, export users and groups from applications, and perform specific configuration tasks for custom applications.

To modify applications:
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application you want to modify. The Applications page expands to open a sub page that displays high-level information about the application.

    You can perform the following tasks in Oracle and custom applications:

    • Oracle applications:

      • Assign users and groups.

      • Remove users and groups.

        The Groups and Users tabs are used to display groups and users assigned to application roles of an Oracle application. Although you can filter and sort this list of users and groups, you can't modify the list. You can't edit values in these tabs.

      • Import Users and Groups for Oracle Application Roles.

      • Export Users and Groups for Oracle Application Roles.

        Note

        If you assign users to Oracle application roles and then deactivate the accounts, IAM prevents the users from accessing the roles. To enable the users to access the Oracle application roles to which they are assigned, activate the users.

      • View High-Level Information

      See Modify Oracle Applications.

    • Custom applications:

      • Assign users and groups.

      • Remove users and groups.

      • Edit high-level information and configuration information.

      • Edit Web Tier Policies for Trusted Applications.

      • Regenerating a Client Secret and generating tokens for Trusted Applications

      • Edit single sign-on (SSO) configuration for SAML Applications.

      See Modify Custom Applications.

Modifying Oracle Applications

You can assign and remove users and groups to Oracle Applications, and import and export users and groups for Oracle Application Roles. You can view the high-level information but can't edit any of the values in Oracle Applications.

Assigning Users to Oracle Applications

You can assign users to Oracle applications only after you activate the applications.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Application roles.
  4. Select the check box for the application role of the Oracle application to which you want to assign users.
  5. Click the Action menu, and then select Assign users.
  6. In the Assign users window, select the check box for each user that you want to assign to the application role.
  7. Click Assign.
    The application role displays a user icon and a Users assigned link. The link displays the number of users that you assigned to the application role.
  8. Click Users assigned.
  9. In the Users assignments window, verify that you see the users that you assigned to the application role.
  10. Click Close.
Removing Users from Oracle Applications

To remove users from Oracle applications, use the Application Roles tab. You can remove users from Oracle applications only after you activate the applications.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Application roles.
  4. Select the check box for the application role of the Oracle application from which you want to remove users.
    Tip

    You can see which application roles have users assigned to them by the user icon and the Users Assigned link that appears in the application role.
  5. Click the Actions menu, and then select Revoke users.
  6. In the Revoke users window, select the check box for each user that you want to remove from the application role.
  7. Click Revoke.
Assigning Groups to Oracle Applications

After you activate the applications, you can assign groups to Oracle applications by using the Application roles tab.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Application roles.
  4. Select the check box for the application role of the Oracle application to which you want to assign groups.
  5. Click the Action menu, and then select Assign groups.
  6. In the Assign groups window, select the check box for each group that you want to assign to the application role.
  7. Click Assign.
    Note

    The All tenant users group is a default group that's created by IAM. All IAM users are assigned to this group, by default. If you assign this group to any of your applications, then all users are assigned to these applications indirectly.
    The application role displays a group icon and a Groups assigned link. The link displays the number of groups that you assigned to the application role.
  8. Click Groups assigned.
  9. In the Groups assignments window, verify that you see the groups that you assigned to the application role.
Removing Groups from Oracle Applications

You can remove groups from Oracle applications from the Application Roles tab. You can remove groups from Oracle applications only after you activate the applications.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Application roles.
  4. Select the check box for the application role of the Oracle application from which you want to remove groups.
    Tip

    You can see which application roles have groups assigned to them by the group icon and the Groups assigned link that appears in the application role.
  5. Click the Actions menu, and then select Revoke groups.
  6. In the Revoke groups window, select the check box for each group that you want to remove from the application role.
    Note

    The All tenant users group is a default group that's created by IAM. All IAM users are assigned to this group, by default. If you remove the All tenant users group from your applications, then access rights to these applications are revoked for every IAM user.
  7. Click Revoke.
Editing High-Level Information for Oracle Applications

When you create an instance of an Oracle application in your identity domain, the application instance appears in the Applications page. As a Service Administrator, you can edit some of the high-level information for Oracle Applications. However, you can’t edit attributes that are protected. Even in an editable attribute, you can’t update certain values that were seeded by the system.

To view and edit high-level information about Oracle application, such as the application type, name, description, icon, URL, links, and whether the application appears on the My Apps page, click Edit application.

UI Elements Attributes Update Seeded Values Add New Values

Description

description

 Yes N/A

Tags

tags

 No Yes

Allowed Scopes

allowedScopes

 No Yes

Allowed Tags

allowedTags

 No Yes

Redirect URL

redirectUris

 Yes N/A

Access Token Expiration

accessTokenExpiry

 Yes N/A

Refresh Token Expiration

refreshTokenExpiry

 Yes N/A

Scope

scopes

 No Yes

Secondary Audiences

protectableSecondaryAudiences

 No Yes

Is Refresh Token Allowed

allowOffline

 Yes N/A

Enforce Grants as Authorization

allowAccessControl

 N/A N/A

Trust Scope

trustScope

 N/A N/A

Activate

active

 N/A N/A
Not all attributes correspond to UI fields:

  • Web tier policy tab and all the UI fields within the tab are controlled and edited by one attribute urn:ietf:params:scim:schemas:oracle:idcs:extension:webTierPolicy:App:webTierPolicyJson.

  • grantedAppRoles attribute records each App Role defined by another application that has been granted to the client.

  • signonPolicy editable attribute indicates that you can assign Oracle Applications to Sign-On Policy.

Note

You cannot change any of the fields other than the ones listed above for Oracle Public Cloud applications. You will encounter an error if you click Save after you try editing any of these values.
Apart from editing certain attributes, you can perform the following with Oracle Public Cloud Applications:

  • Edit only single scope. Bulk removal of scopes is not supported.

  • Grant client access to the IAM APIs

    To enable your application to access IAM APIs, click Add.

    In the Add App Role window, select the application roles that you want to assign to this application. This enables your application to access the REST APIs that each of the assigned application roles can access.

    For example, select Identity Domain Administrator from the list. All REST API tasks available to the identity domain administrator will be accessible to your application.

    You can't remove the following:

    • The assigned application roles from the application by clicking the x icon for the row of the required application role

    • The App Roles that were granted when an Oracle Public Cloud application was created because those seeded values are protected

Modifying Custom Applications

You can assign and remove users and edit high-level information in custom applications.

Assigning Users to Custom Applications

Custom applications are non Oracle Public Cloud (OPC) services. You can modify custom applications by assigning users to them. Users can access the My Apps page to view these applications.

  • The application must be activated.

  • The application must be assigned to the current user who is accessing the My Apps page

  • The Display in My Apps check box must be selected in the Details tab in the applications.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Users.
  4. Click Assign users.
  5. In the Assign users window, do one of the following:
    1. Select the check box for each user that you want to assign to the application.
    2. For a provisioned application, select Assign next to the user that you want to assign to the application. Enter the required values for the form, and then click Save.
    Note

    If the form contains multi-valued attributes, then an Add button appears to the right of each attribute. Click Add, and then in the Allowed values window, select the values for the attribute, and click OK.
  6. Click Assign.
Note

If you assigned a provisioned application to the user, then you can modify the values of the application form. To do this, click the Actions menu, select Edit, change the appropriate values, and then click Save.

You can activate or deactivate a user's account assigned to a synchronized app that's created from the App Catalog. To do so:

  1. Click the Actions menu to the right of the user account that you assigned to the application.

  2. Click Activate or Deactivate.

  3. In the Activate account? or Deactivate account? window, click OK.

See Enabling Provisioning for an App Catalog Application for more information about configuring provisioning for an application to manage the lifecycle of users in the application.

Removing Users from Custom Applications

You can modify custom applications by removing users from them. Users can no longer view these applications through the My Apps page.

The application must be activated.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Users.
  4. Select the check box for each user that you want to remove from the application.
  5. Click Revoke.
  6. Complete one of the following choices:
    • To remove one user from the custom application, in the Revoke user? dialog box, click Revoke user.
    • To remove multiple users from the custom application, in the Revoke users? dialog box, click Revoke users.
Assigning Groups to Custom Applications

You can modify custom applications by assigning groups to them. Users who are members of these groups can access the My Apps page to view these applications.

Prerequisite: The application must be activated.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Groups.
  4. Click Assign groups.
  5. In the Assign groups window, do one of the following.
    1. Select the check box for each group that you want to assign to the application.
    2. For a provisioned application, select Assign next to the group that you want to assign to the application. Enter the required values for the form, and then click Save.
      Note

      If the form contains multi-valued attributes, then an Add button appears to the right of each attribute. Click Add, and then in the Allowed values window, select the values for the attribute, and click OK.

      The All tenant users group is a default group that's created by IAM. All IAM users are assigned to this group, by default. If you assign this group to any of your applications, then all users are assigned to these applications indirectly.

  6. Click Assign.
Note

If you assigned a provisioned application to the group, then you can modify the values of the application form. To do this, click the Actions menu, select Edit, change the appropriate values, and then click Save.
Removing Groups from Custom Applications

You can modify custom applications by removing groups from them. Users who are members of these groups can no longer view these applications through the My Apps page.

Activate the application.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Groups.
  4. Select the check box for each group that you want to remove from the application.

    The All tenant users group is a default group that's created by IAM. All IAM users are assigned to this group, by default. If you remove the All tenant users group from your applications, then access rights to these applications are revoked for every IAM user.

  5. Click Revoke access.
Editing High-Level Information for Custom Applications

You can edit high-level information for custom applications.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.
  2. Click the application that you want to modify.
  3. Click Edit application.
  4. Modify any fields as necessary (for example, modify the application name in the Name field).
  5. Click Save changes.
Editing Configuration Information for Custom Applications

You can edit configuration information for custom applications.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click the application that you want to modify.
  3. Click Configuration.
  4. Expand the Client configuration node.
  5. Modify a configuration value for the custom application by:
    • Entering the value in the attribute field (for example, in the Redirect URL field, entering the application URL where the user is redirected after authentication)
    • Clicking a button (for example, adding a resource to the custom application by clicking Add or removing a scope for a trusted application by clicking Remove)
    • Selecting or clearing the check box (for example, allowing the resource owner to be a grant type for the custom application by selecting Resource owner)
    • Selecting the value from the menu (for example, selecting User administrator from the Grant the client access to Oracle Identity Cloud Service admin APIs. list to enable the custom application to access user administrator-related APIs)
  6. If your custom application is a confidential or a mobile application, then you can switch Bypass consent on or off.
  7. If your custom application is a confidential application, then expand the Resources node.
    If your custom application is a mobile application, then the Resources node doesn't appear in the Configuration tab. This is because confidential applications run on a protected server, and mobile applications run on an unauthenticated web browser or a mobile device.
  8. Modify a configuration value for the protected resources of your confidential application. See step 3 for more information about how to edit configuration values.
  9. Click Save.

See Add a Confidential Application, Add a Mobile Application, and Add a SAML Application for more information about the configuration settings for client applications.