Integrating your applications makes it easy for users to sign in with single sign on and gives you a central place to manage their permissions. Application integration includes securing your users, protecting the resources within the applications, and enabling users to access your applications through single sign-on (SSO). Integrating your applications with IAM provides the user with a seamless experience. Because of SSO, the user doesn't have to remember different IDs and passwords for each application. When your applications are integrated with IAM, your administrative overhead is reduced greatly because you can manage the policies and users for your applications from one central place. From a compliance perspective, IAM provides you with a single location where you can manage the access that your users have to your applications.
As part of application integration, IAM can be used as either an identity provider or a service provider for applications. An identity provider, also known as an Identity Assertion provider, provides identifiers for users who want to interact with IAM using a website that's external to IAM. A service provider is a website that hosts applications. You can enable an identity provider and define one or more service providers. Your users can then access the applications hosted by the service providers directly from the identity provider.
For example, a website can allow users to log in to IAM with
their Google credentials. Google acts as the identity provider and IAM functions as the service provider. Google verifies that the user is an
authorized user and returns information to IAM (for example,
the user name and the email address of the user, if the email address differs from the
user name).
Some applications may require a user account to exist in their local identity store
before the user can sign in to access these applications.
When users aren't created in IAM or imported into IAM from a flat file, they need to be synchronized from an authoritative source, such as an HR application or a corporate LDAP directory. For this scenario, the authoritative source and the application have to be integrated with IAM for provisioning and synchronization purposes.
Which Integration Method to Use?
Use the following flowchart to learn which method to use to integrate your
application with IAM.
In this flowchart, you learn which method to use to integrate your application with Oracle Identity Cloud Service. Do you want to synchronize users to or from Microsoft Active Directory (AD)? If you do, then use the AD Bridge. If you don't, then do you want to synchronize users from an LDAP such as Oracle Internet Directory? If you do, then use the App Catalog and the Provisioning Bridge. If you don't, then is your application listed in the App Catalog? If it is, then use the App Catalog template to provision or synchronize users. If it isn't, then does your application expose SCIM-based REST APIs to manage users? If it does, then use one of the Generic SCIM Templates to provision or synchronize users. If it doesn't, then develop and deploy a SCIM REST interface for your application and use the SCIM App Template to provision or synchronize users.
The following scenarios will help you understand this flowchart for synchronization and provisioning purposes:
Scenarios for
User Synchronization
One of the following scenarios may apply when synchronizing users
and groups from authoritative sources:
An HR Application as an Authoritative Source
When a company hires an employee, an HR representative adds that
employee's information in the HR application directly. The
HR application contains information about the user, such as
the user's first name, last name, job role, and job
location. This information is used to create an account for
the user and assign applications to the user. For this
scenario, you want to synchronize your user account into
IAM from the HR application.
IAM supports integration with
the HR application by using the App Catalog. If your
application isn't listed in the App Catalog, then you can
build your own connector or use the Generic SCIM App
Template. This template facilitates the configuration of
your custom application when the SCIM APIs are exposed. If
your application doesn't expose the SCIM APIs, then you can
develop a custom SCIM gateway to act as an interface between
IAM and your
application.
A Corporate LDAP as an Authoritative Source
Some customers store users and groups into an LDAP, such as
Microsoft Active Directory (AD) or Oracle Internet
Directory. These users and groups can authenticate into IAM by using SSO.
For this to occur, first, the users and groups must be
synchronized from the LDAP into IAM. To do this,
use the Microsoft Active Directory Bridge (for AD) or the
Provisioning Bridge (for Oracle Internet Directory).
Scenario for User Provisioning
IAM enables you to use app templates to
provision users to applications. In the App Catalog, you'll
find a list of app templates that support provisioning.
These templates enable you to integrate these applications
with IAM quickly. If your
application isn't listed in the App Catalog, then use the
Generic SCIM App Template.
Now that you know how to use the flowchart to select a method to
integrate your application with IAM for provisioning and synchronization purposes, let's
learn about each integration type in greater detail.
Integrate IAM with Applications from the App
Catalog 🔗
This section provides answers to the following questions to help you understand
how to use the App Catalog to integrate IAM with
Software-as-a-Service (SaaS) applications:
Over the past few years, customers are transitioning their access management system
from an on-premises environment to a cloud-based one. This includes shifting their assets
(such as their on-premises applications) into the cloud. Because of the proliferation of
cloud-based SaaS applications in the market, IAM must be able to
integrate with these applications. IAM has out-of-the-box
integrations for thousands of SaaS applications. When a predefined integration isn't
available for a SaaS application, IAM provides SAML and SCIM
toolsets that will enable customers to integrate with it. By integrating your SaaS
applications with IAM, you have one central place where you can
not only manage your applications, but also the access that your users have to
them.
What Is the App Catalog? 🔗
The App Catalog is a collection of partially configured application templates for
thousands of SaaS applications, such as Amazon Web Services and Google Suite. Using the
templates, you can define an application, configure SSO, and configure provisioning. Oracle
creates and maintains the App Catalog for you, and provides step-by-step instructions that
will help you to configure your applications.
What Are the Advantages of Using the App Catalog? 🔗
The App Catalog has out-of-the-box integrations for thousands of SaaS applications.
When an application is available in the App Catalog, most of the metadata that IAM needs to integrate with the application already exists, so you don't
have to define it. For most applications, it takes less than five minutes to configure them
so that they can be integrated with IAM. All you have to do is go
to the App Catalog, search for an application, create an instance of the application, and
provide the connectivity details that IAM requires to communicate
with it. When setting up applications, IAM features guided wizards
that will help you configure them even further. This provides you with a consistent approach
when using the App Catalog to integrate your applications with IAM.
Use Bridges to Integrate IAM with On-Premises
Applications 🔗
This section provides answers to the following questions to help you understand how to use bridges to integrate IAM with on-premises applications, including Microsoft Active Directory (AD), an enterprise LDAP (such as Oracle Internet Directory), and a business application (such as Oracle E-Business Suite) that's used to manage and automate your business-related processes:
Why Use Bridges to Integrate IAM with On-Premises
Applications? 🔗
Most customers have Microsoft Active Directory (AD) as their central directory
service. These customers also use AD as their network directory. This directory is
where all of their workstations are connected to and where they manage their
users.
In addition to AD, customers use:
An enterprise LDAP to centralize all of their user identities.
So, a customer uses AD to manage their employees, but in the
centralized LDAP, the customer manages their partners,
consumers, and any other users with which the customer has
relationships.
Business applications to manage and automate processes across
their enterprise. These processes include customer
relationship management (CRM), enterprise resource planning
(ERP), and supply chain management (SCM) processes.
For these reasons, it's imperative that IAM can integrate with AD, an enterprise LDAP (for example, Oracle Internet Directory), and an on-premises business application (such as Oracle E-Business Suite) to manage and automate the customer's CRM, ERP, SCM, and other business-related processes.
What Are the Types of On-Premises Application Integrations? 🔗
By using IAM, customers can control when they will migrate
their directory-based applications to the cloud. In the interim, they can use one of the
following:
AD Bridge: This bridge provides a link between your AD enterprise directory structure and IAM. IAM can synchronize with this directory structure so that any new, updated, or deleted user or group records are transferred into IAM. Each minute, the bridge polls AD for any changes to these records and brings these changes into IAM. So, if a user is deleted in AD, then this change will be propagated into IAM. Because of this synchronization, the state of each record is synchronized between AD and IAM. After the user is synchronized from Microsoft Active Directory to IAM, if you activate or deactivate a user, modify the user's attribute values, or change the group memberships for the user in IAM, then these changes are propagated to Microsoft Active Directory through the AD Bridge. See Setting Up a Microsoft Active Directory (AD) Bridge.
Provisioning Bridge: This bridge provides a link between your enterprise LDAP or on-premises business application (such as Oracle Internet Directory or Oracle E-Business Suite) and IAM. Through synchronization, account data that's created and updated directly on the LDAP or business application is pulled into IAM and stored for the corresponding IAM users and groups. Any changes to these records will be transferred into IAM. Because of this, the state of each record is synchronized between the LDAP or business application and IAM.
After users are synchronized from the on-premises business application to IAM, you can also use the Provisioning Bridge to provision
users to the application. Provisioning allows you to use IAM to manage the lifecycle of users in the application. This includes
creating, modifying, deactivating, activating, and removing users and their
profiles across the application. Any changes that you make to users or their
profiles in IAM are propagated to the business
application through the Provisioning Bridge. See Managing Provisioning Bridges.