You can find the user by issuing a POST to /api/data/users/search containing a JSON body like this:

{"criterias":["{\"operator\":\"AND\",\"childCriteria\":[{\"attributeKey\":\"dn\",\"operator\":\"EQ\",\"values\":[\"cn=SOMELDAPDN\"]}]}"]}

In this example I'm searching by using the LDAP DN of the identity. You can do a search in the IG UI and watch the traffic using the browser developer tools if you want to use some other criteria to find out what the API expects.

You'll get an array back and you get the user ID like this:

users[0].userId

Thanks I will give that a shot.

for the request/request we look to have  a working request --I will update here once we have it working

IG Rest calls to remove permission.

Used a POST with the URL containing the below

{{authURL}}/api/data/users/search?sortBy=displayName&sortOrder=DESC&indexFrom=0&size=100&showCt=true&listAttr=displayName&listAttr=userId&qMatch=ANY&q=cn=LX1411,ou=CPO,o=CTT

This worked great to grab the user based on their UserDN value for the given environment.



Here is an example to request permissions on an account:

{{authURL}}/api/request/users/{{userID}}/perms?getParams=true

with body containing:
{
"requestItem": "true",

}


Here is an example of how to request the removal of a permission on an account using /api/request/request

 

Reference <url>/apidoc against the ig server for docmuentation

Swagger looks to be 1.2 and doesn't import into Postman with 3.7.0 version

Are you feeding IG identities from IDM?  Are you using the IGIM driver to do that frequently?   If so, and if you have an attribute that identifies a termed user (employeeStatus=TERM, or something similar)  you can setup a data policy that fires when that flag is set initially.   The (micro)certification can be setup with a very short timeframe for auto-removal of access when the cert is done, and no notifications. 

The end result is the termination happens, IG learns about it, it kicks off a review that ends almost immediately, with auto-removal of permissions, and then fulfillment to your various systems happens.   No need for REST calls.

--Jim

New integrations that don't have business and technical roles defined and functioning can't take advantage of some of the data policies. Other customers that don't have a full license can't do a micro certification.

The data policies don't allow cross class conditions, such as Identity Employee Status terminated & checking if a user is a member of a group or holds a given permission.

3.7.3 will allow to start a workflow, but otherwise we are limited to kicking off an email. But there are license limitations for some customers with the data policies, or at least we have license messages on the page.

Personally I think there should be built in lifecycle events to ease security concerns, such as if a user is terminated, let's allow the removal of all applications / permissions. This isn't dependent on Roles being fully rolled out. Some customers will have hundreds of applications where it may take years for permissions to be removed. If we can start with collecting permissions and at least triggering on lifecycle events to handle permissions; we have one or more security measures being handled.