IGA 3.6.2 / 3.7 --- What rest calls do I need to make to request the removal of a group or application from a user?

When an account is disabled / terminated in IDM we want to send a rest call to IG to remove specific applications / permissions from that user.

-get token

-/data/users to get user's unique ID  (not working yet)

-request/users/{User Unique ID}/perms  (working when submitting it based on data in IG catalog)

do we then do a /request/request ?

      -If so any examples of doing a removal?
      -What are the requestType values we can specify?
      -What do we specify for the recipient? The Source ID or unique ID value we retrieved earlier?

      -What doe we specify for the requestItem? The unique ID of the permission or application?

thanks!
Fred

Parents
  • 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.

Reply
  • 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.

Children
No Data