Identity Governance-related APIs
Identity Governance has many features, including access requests, the governance glossary (catalog), and entitlements. The following sections comprehensively explore the Identity Governance REST API endpoints.
YAML file
The REST APIs contain many parameters and, in some instances, large request bodies. For your convenience, you can view the entire API using a YAML file based on the OpenAPI specification.
To download the YAML file, click here.
| Adjust the configurations of the file to match your specific details, such as your Identity Cloud tenant FQDN. |
Endpoints
Access request
In Identity Governance, end users can request access to resources. Resources are target applications, entitlements, or roles. You define which resources are requestable.
For more information, refer to access requests.
The following table shows the endpoints used by access requests:
| You can define workflows for access requests, such as what email gets sent to who for an access request type. These endpoints are used, in tandem, with the access request endpoints. For more information, refer to Workflows. |
| URI | HTTP method | Description |
|---|---|---|
|
POST |
Create or validate a new access request for a list of users. When submitting a new request for access, the system validates the request’s contents. If no issues are found, IGA creates a request for each pairing of user and catalog items included in the request. You can choose to only validate the request by using the |
|
GET |
Retrieve the details of a single access request using an unique identifier, |
|
POST |
Perform various actions on a specific request, such as:
Depending on the information the caller provides, each action has different request payloads. |
|
GET |
Get access requests based on the permissions the user has without additional filtering. For additional search capabilities,
use the POST |
|
POST |
Retrieve access requests submitted to review based on the permissions the user has with filtering. Use the |
|
POST |
Get access requests the authenticated user needs to make a decision on either through a role or through a delegate. Use the |
Governance glossary (catalog)
In Identity Governance, you can use the governance glossary to attach custom attributes (metadata) to applications, entitlements, or roles to enhance certifications or access requests.
For more information, refer to the Manage governance glossary.
The following table shows the endpoints used by access requests:
| URI | HTTP method | Description |
|---|---|---|
|
GET |
Retrieve all resources in the access catalog without additional filtering. Each entry represents a single type of requestable access that you can add to a request. The supported types of access that are requestable are application, entitlement, and role. |
|
POST |
Get a list of resources (catalog items) with additional filtering. Each entry represents a single type of requestable access that you can add to a request. The supported types of access that are requestable are application, entitlement, and role. |
|
GET |
Retrieve configured properties that are eligible for searching and sorting when querying the access catalog. Each property includes metadata, such as whether the property is multi-valued and its data type. |
|
GET |
Retrieve configured properties that are eligible for searching and sorting when querying access catalog for a single given object. For example, entitlement specific properties you can use to search. Each property includes metadata, such as whether the property is multi-valued and its data type. |
Provisioning
In the Identity Cloud admin UI, you can add or remove, or provision, resources from end users, however; you can do the same through REST APIs.
The following table shows the endpoints to add or remove users from resources:
| URI | HTTP method | Description |
|---|---|---|
|
POST |
Add or remove applications for an end user. |
|
POST |
Add or remove roles for an end user. |
|
POST |
Add or remove entitlements for an end user. |
Identity Governance configurations
Identity Governance has overarching configurations, such as requiring a justification when rejecting an access request.
The following table shows the endpoints relating to Identity Governance configurations:
| URI | HTTP method | Description | ||
|---|---|---|---|---|
|
GET |
Reads and returns all Identity Governance configuration properties across all categories. Only access request-related properties are available. These properties are used to determine the behavior behind functionality. For example, access request features contain configuration on whether justification is required to reject a request or whether a user can approve their own access. |
||
|
PUT |
Update the configuration properties across all categories. Only access request-related properties are available.
|
||
|
GET |
Get Identity Governance access request configurations for a given key. |
||
|
PUT |
Update Identity Governance access request configurations for a given key. |
Account
Accounts are user profiles in applications. For example, when you provision an end user to an application, an account is created for them.
The following table shows the endpoints for accounts:
| URI | HTTP method | Description |
|---|---|---|
|
GET |
Retrieve all account objects across all applications. |
|
POST |
Retrieve account objects searching by application, user, or glossary data. |
|
GET |
Retrieve a single account by ID. |
|
GET |
Retrieve an account’s glossary (catalog) metadata by account ID. |
|
POST |
Create glossary metadata for an account by account ID. |
|
PUT |
Update an account’s glossary metadata by account ID. |
Events
Events are rules defined to detect a change in the IGA system. Each rule has two core parts: a condition for the event and the action taken when that event occurs
The following table shows the endpoints for events:
| URI | HTTP method | Description |
|---|---|---|
|
GET |
Get and search for a list of event rules defined in IGA. Each entry represents a single event rule defined to detect a change in the system. IGA rules consist of two core pieces: condition for the event, and action taken when the event occurs. For example, a rule might define that whenever someone creates a user in IGA, they should also generate a certification for that user. |
|
POST |
Create a single IGA event rule. A single event rule is defined to detect a change in the system. IGA rules consist of two core pieces: condition for the event, and action taken when that event occurs. For example, a rule might define that whenever someone creates a user in IGA, they should also generate a certification for that user. |
|
GET |
Get a single IGA event by id. The response is a single event rule defined to detect a change in the system. |
|
PUT |
Update a single IGA event by id. This call requires that the entire object be provided and that it replaces the entire existing event definition. |
|
PATCH |
Update a single IGA event by id. This call allows the caller to update specific properties of the event only without providing the entire object. |
|
DELETE |
Delete a single IGA event by id. |
|
GET |
Get the list of available entities from which you can define a condition. |
|
GET |
Get the available schema for defining a condition on a given object.
For example, |
Scope
Scope is a rul that defines which subset of users can see or interact with a subset of target objects. Scoping rules comprise of two core parts: a condition for the source object (who or what the scope applies to) and a condition for the target object that can be viewed or acted upon.
| URI | HTTP method | Description |
|---|---|---|
|
GET |
Get and search for a list of scoping rules defined in IGA. Each entry represents a single scoping rule defined to assign a set of conditions that allows a subset of users visibility on a subset of target objects. IGA scoping rules consist of two core parts: a condition for the source object (who/what the scope applies to) and a condition for the target object that can be viewed or acted upon. |
|
POST |
Create a single scoping rule in IGA. Each scoping rule is defined to assign a set of conditions that allows a subset of users visibility on a subset of target objects. IGA scoping rules consist of two core parts: a condition for the source object (who/what the scope applies to) and a condition for the target object that can be viewed or acted upon. |
|
GET |
Get a single scoping rule in IGA by ID. Each scoping rule is defined to assign a set of conditions that allows a subset of users visibility on a subset of target objects. IGA scoping rules consist of two core parts: a condition for the source object (who/what the scope applies to) and a condition for the target object that can be viewed or acted upon. |
|
PUT |
Update a single IGA scope by id. This call expects the entire object to be provided and replaces the entire existing scope definition. |
|
PATCH |
Update a single IGA scope by id. This call allows the caller to update specific properties of the scope only without providing the entire object. |
|
DELETE |
Delete a single IGA scope by id. |
|
GET |
Get a list of available entities on which a condition can be defined. |
|
GET |
Get the available schema for defining a condition on a given object. For example, 'user' returns the attributes available for defining a scope for users in IGA. |
Evolving APIs
| The APIs referenced in this section are evolving, which means they can change or become deprecated at any time. |
The current evolving APIs focus on entitlements. For more information, refer to Manage entitlements.
| URI | HTTP method | Description |
|---|---|---|
|
GET |
Get an entitlement by an ID. |
|
POST |
Search for a list of entitlements that match a query. |
|
GET |
Gets the users assigned to a specific entitlement. |
Access grant
Access grants are one-to-one relationships between an end user and a resource.
For example, when you assign an end user to an entitlement, Identity Governance correlates the user to that entitlement. This one-to-one correlation is an entitlement grant. If an entitlement has 12 users associated, there are 12 entitlement grants.
For each entitlement grant, a confidence score can be assigned using Autonomous ID (Autonomous Identity).
With Autonomous Identity data exported, import the confidence scores into Identity Governance.
The confidence scores display on line-items in a certification.
This assists certifiers regarding which actions to take during a certification.
For example, if the confidence score for an end user to have an entitlement is 90,
then the certifier can have a high degree of certainty
that the end user can have the entitlement.
The following table shows the endpoints relating to an entitlement grant’s glossary metadata:
|
Only create confidence scores for access grants from data generated from Autonomous Identity. When importing the confidence scores from Autonomous Identity, use a script to iterate over the resource ID and account ID. |
| URI | HTTP method | Description |
|---|---|---|
|
GET |
Retrieve a single entitlement grant’s glossary metadata by account and entitlement ID. |
|
POST |
Create a single entitlement grant’s glossary metadata by account and entitlement ID. |
|
PUT |
Create or update a single entitlement grant’s glossary metadata by account and entitlement ID. |