/access-requests throws away request without any indication if user is already entitled

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Here is the scenario

  1. A user requests an access profile they’re already assigned but are not aware

  2. An access request is submitted through the /access-requests endpoint, and a 202 is returned

  3. Because the user is already assigned this AP, nothing happens

I realize I can add a step before submitting to check and see if that identity is already assigned that access, but it would be nice if the API endpoint would return a 400 and tell us that too

2

Hi Mark,

There was a recent change in the access request endpoint that made this endpoint fully asynchronous leading to the problem you are describing. This endpoint used to do a synchronous check to see if the identity already had the access being requested. This used to result in a 400 if the access was already granted or pending approval. Engineering moved this endpoint from synchronous to asynchronous because it was causing performance and scalability issues to do that check for every access request coming in.

Here is what you can do to check if an identity already has the access being requested before submitting the access request.

POST https://{tenant}.api.identitynow.com/v3/search
Body:

{
  "indices": [
    "identities"
  ],
  "query": {
    "query": "id:<identityId>"
  },
  "queryResultFilter": {
    "includes": [
        "id",
        "name",
        "access.name",
        "access.id",
        "access.type"
    ]
  }
}

You will need to run this API request for each identity listed in the access request. It will return a response with a list of accesses that the identity has:

[
    {
        "access": [
            {
                "name": "DevRel",
                "id": "2c9180877677453d01767b4b08f63386",
                "type": "ENTITLEMENT"
            },
            {
                "name": "Employee Source",
                "id": "2c91808a7643763f01767b59d9d907cf",
                "type": "ACCESS_PROFILE"
            },
            {
                "name": "Test Profile",
                "id": "2c91808a7960c9ba017960f8011d0097",
                "type": "ACCESS_PROFILE"
            }
        ],
        "name": "adam.archer",
        "id": "2c9180867b75ce33017b78198e8c0a06",
        "_type": "identity",
        "type": "identity",
        "_version": "v7"
    }
]

You can run this search query before submitting an access request. If the identity already has the access that is being requested, you can cancel the request. If there are any items in the requestedItems list that the identity doesn’t yet have access to, you can submit a request for just those items.

If you want to check if there is already a pending access request for the same identity/items, then you use the list pending approvals endpoint. This endpoint will allow you to get a list of all pending access requests for an identity. You can loop/paginate through the list of pending access requests and check if any of the items being requested are already pending. If any are pending, you can omit those specific access items from the access request body.

I have an action item on my end to update the API description for the access request endpoint to provide this same guidance.

3

Hello @colin_mckibben - for
"
There was a recent change in the access request endpoint that made this endpoint fully asynchronous leading to the problem you are describing. This endpoint used to do a synchronous check to see if the identity already had the access being requested. This used to result in a 400 if the access was already granted or pending approval. Engineering moved this endpoint from synchronous to asynchronous because it was causing performance and scalability issues to do that check for every access request coming in."

When was that put into place?

4

Hi Cory. I don’t have the exact date, but I want to say Q1 of 2022. Do you need an exact date?

1 Like