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.
Learn more in the API reference documentation.
Adjust the configurations of the file to match your specific details, such as your Advanced 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.
Learn more in access requests.
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 |
|
POST |
Create request for the given request type. |
|
GET |
Retrieve the details of a single access request using an unique identifier, |
|
PUT |
Replace the content of a request. The only properties that can be changed are
properties that are defined in the request schema and not in the |
|
PATCH |
Update the contents of a request. The only properties that can be updated are properties
that are defined in the request schema and not in the |
|
POST |
Perform various actions on a specific request, such as |
|
GET |
Get requests for which the authenticated user has permissions to view. For additional search capabilities,
use the |
|
POST |
Get requests for which the authenticated user has permissions to view. The |
|
POST |
Get requests for which the authenticated user is assigned, either directly, through a role, or
through a delegate. The |
Account
Accounts are user profiles in applications. For example, when you provision an end user to an application, an account is created for them.
URI | HTTP method | Description |
---|---|---|
|
GET |
Retrieve all account objects across all applications that have been onboarded as part of any application. |
|
POST |
Retrieve all account objects across all applications that have been onboarded as part of any application. Additional filter criteria can be provided to allow searching by application, user, or glossary data. |
|
GET |
Retrieve by details of a single account object using its unique identifier. |
|
GET |
Retrieve the glossary specific details of a single account object using its unique identifier. |
|
POST |
Create glossary entry for a single account object using its unique identifier. |
|
PUT |
Create or update a glossary entry for a single account object using its unique identifier. |
Audit
Endpoints associated with IDM’s audit functionality.
To use the
This is a temporary requirement and will be removed in a future release. |
URI | HTTP method | Description |
---|---|---|
|
GET |
Get audit reports. |
|
GET |
Get the audit reports for a given user. |
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.
You can find more information in the Manage governance glossary.
URI | HTTP method | Description |
---|---|---|
|
GET |
Get a list of items from the Identity Governance access catalog. Each entry represents a single
type of requestable access that can be added to a request. The current supported types
of access that are requestable are |
|
POST |
Get a list of items from the Identity Governance access catalog using additional filter criteria.
Each entry represents a single type of requestable access that can be added to a request.
The current supported types of access that are requestable are |
|
GET |
Retrieve all currently configured properties eligible to be used for search or sort when searching against the catalog API. Each property includes some additional metadata about the property, such as whether it is multivalued or not and its datatype. |
|
GET |
Retrieve all currently configured properties eligible to be used for search or sort for a single object when searching against the catalog API. For example, you can use the endpoint to search for all specific entitlement properties. Each property includes some additional metadata about the property, such as whether it is multivalued or not and its datatype. |
Certification
URI | HTTP method | Description |
---|---|---|
|
GET |
Query existing certification templates. |
|
POST |
Create a new certification template. |
|
POST |
Duplicate an existing certification template. |
|
PUT |
Update a single certification template. |
|
DELETE |
Delete a single certification template. |
|
POST |
Get the available schema on which to filter certification templates. |
|
GET |
Query existing certification campaign instances. |
|
GET |
Read a single certification campaign. |
|
GET |
Get the actors (certifiers) tasks view for a certification. |
|
POST |
Update a certification’s deadline. |
|
POST |
Cancel a certification campaign. |
|
GET |
Query the review items (tasks) that are assigned to you. |
|
GET |
Query line items of the certification campaign instance. |
|
POST |
Query line items of the certification campaign instance. |
|
POST |
Take action on line items. |
|
POST |
Take action on a single line item. |
Config
Identity Governance has overarching configurations, such as requiring a justification when rejecting an access request.
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 all Identity Governance configuration properties across all categories. Only access request-related properties are available.
|
||
|
GET |
Get Identity Governance configuration settings for a given category (for example, |
||
|
PUT |
Update Identity Governance configuration settings for a given category (for example, |
Event
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.
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 event entities from which you can define a condition. |
|
GET |
Get the available schema for defining a condition on a given object.
For example, |
Job
Endpoint to trigger an Identity Governance’s job process.
URI | HTTP method | Description |
---|---|---|
|
POST |
Manualy triggers one of IGA’s job processes. |
Request form
Identity Governance enables administrators to create custom forms presented to users during request workflows.
URI | HTTP method | Description |
---|---|---|
|
GET |
Search request forms. |
|
POST |
Create a request form. |
|
GET |
Get a request form by ID. |
|
PUT |
Replace an existing request form by ID. |
|
PATCH |
Update an existing request form by ID. |
|
GET |
Search the request form assignments. |
|
POST |
Assign and unassign a request form. |
Request type
You can define workflows for access requests, such as what email gets sent to whom for an access request type. These endpoints are used, in tandem, with the access request endpoints. |
URI | HTTP method | Description |
---|---|---|
|
GET |
Get a list of supported request types. |
|
POST |
Create a new custom request type. |
|
GET |
Get the request type by ID. |
|
PUT |
Replace an existing request type. |
|
PATCH |
Update a request type. |
|
DELETE |
Delete a request type. |
Provisioning
In the Advanced Identity Cloud admin UI, you can add or remove, or provision, resources from end users, however; you can do the same through REST APIs.
URI | HTTP method | Description |
---|---|---|
|
POST |
Provision or de-provision applications for an end user. |
|
POST |
Provision or de-provision roles for an end user. |
|
POST |
Provision or de-provision entitlements for an end user. |
Scope
Scope determines which specific users are able to view or interact with particular 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. |
Segregation of Duty
Segregation of Duties (SoD) is an internal control process ensuring no single individual is granted privileges that could lead to a conflict of interest or fraud. Administrators can configure SoD using policies and policy rules that let them identify violations and run actions, such as create an exception, allow or remediate the violation, and others.
You can view the entire API using a YAML file based on the OpenAPI specification.
Adjust the configurations of the file to match your specific details, such as your Advanced Identity Cloud tenant FQDN. |
URI | HTTP method | Description |
---|---|---|
|
GET |
Search policies. The endpoint returns policies stored within the Identity Governance store, based on a set of query parameters. |
|
POST |
Create a new policy object within Identity Governance. |
|
POST |
Query policy objects using a targeted search filter. |
|
GET |
Get policy by ID. The endpoint returns the policy with the provided ID. |
|
PUT |
Update an existing policy object within Identity Governance. |
|
DELETE |
Delete an existing policy object within Identity Governance. |
|
POST |
Run a scan on all given rules of a policy and create violations if desired. |
|
GET |
Get policy rules associated with a policy ID. |
|
GET |
Query policy rules based on a set of query parameters. |
|
POST |
Create a new policy rule object within Identity Governance. |
|
POST |
Query the policy rule objects using a targeted search filter. |
|
GET |
Get policy rule by ID. |
|
POST |
Duplicate a given policy rule. The rule will be set as |
|
PUT |
Update an existing policy rule object. |
|
DELETE |
Delete an existing policy rule. |
|
POST |
Run a scan the given policy for violations and create violations if desired. |
|
POST |
Run a scan on a given user rule and return potential violations. |
|
GET |
Query policy scans with the Identity Governance store based on a set of query parameters. |
|
POST |
Query policy scan objects using a targeted search filter. |
|
GET |
Get policy scan by ID. |
|
DELETE |
Delete an existing policy scan object within Identity Governance. |
|
GET |
Query the signed-in user’s violation objects. |
|
GET |
Query the violation objects. |
|
POST |
Creates a violation with the given body. |
|
POST |
Once a phase (or phases) have chosen to allow a violation, close and complete the
violations with the outcome of |
|
POST |
As a user who can take action on violations, cancel existing exceptions, reverting the violations back to in-progress. |
|
POST |
As a user who can take action on violations, add a comment to the violation objects. |
|
POST |
As a user who can take action on violations, grant an exception to the violating access. |
|
POST |
As a user who can take action on violations, edit the list of active actors on the violation tasks. |
|
POST |
Query the violation objects using a targeted search filter. |
|
POST |
Query the signed-in user’s violation object using a targeted search filter. |
|
GET |
Query the contents of a single violation object. |
|
PUT |
Updates a given violation with the given body. |
|
DELETE |
Deletes a violation with a given ID. |
|
POST |
Once a phase (or phases) have chosen to allow a violation, close and complete the
violation with an outcome of |
|
POST |
As an actor on a violation, add a comment to a violation object. |
|
POST |
Once a phase (or phases) have chosen to remediate a violation, complete the violation
with an outcome of |
|
POST |
For violations with an outcome of |
|
POST |
Add a phase to a violation. A phase is a task that must be completed to move the violation forward,
which depends on the task configuration, such as expiration, assignee, notifications, and others.
For type= |
|
POST |
As an actor on a violation, allow the user to continue to violate the defined rule in perpetuity. |
|
POST |
As an actor on a violation, cancel an existing exception, reverting the violation back to |
|
POST |
Add a comment to a violation object. |
|
POST |
As an actor on a violation, grant an exception to the violating access. |
|
POST |
As an actor on a violation, edit the actors and permissions on a violation task. |
|
POST |
As an actor on a violation, choose to remediate the access, kicking off the remediation workflow assigned to the violation. |
|
POST |
As an actor on a manual provisioning task to handle the violation remediation, mark the action as completed. |
|
POST |
As an actor on a manual provisioning task to handle the violation remediation, mark the action as canceled (not completed). |
Task
Endpoints for fulfillment tasks.
URI | HTTP method | Description |
---|---|---|
|
GET |
Get the tasks for which the authenticated user has permissions to view. |
|
POST |
Get the tasks for which the authenticated user has permissions to view. The
|
User
Endpoint for a user’s grants and recommendations.
URI | HTTP method | Description |
---|---|---|
|
GET |
Get the grants a user currently has. |
|
GET |
Get the access recommendations for a given user. |
Workflow
To use the
This is a temporary requirement and will be removed in a future release. |
URI | HTTP method | Description |
---|---|---|
|
GET |
Get the workflow definitions. |
|
Post |
Create and/or publish workflow definitions. |
|
GET |
Get the workflow definition. |
|
DELETE |
Delete the workflow definition. If the status is published, it will try to delete the workfow model and process the definition in IDM. |
|
PUT |
Update or publish the workflow definition. |
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 all entitlements that match the target filter. |
|
GET |
Gets the users assigned to a specific entitlement. |