Enhancement: Access Request ID!

[jennifer_mitchell]

Description

SailPoint® is excited to announce that the access request submission API endpoint now returns an access request ID as soon as a request is created. This enhancement allows the ID to be used as a filter with the access request status endpoint, making it easier and more precise to track the status of each request.

Problem

Previously, access request IDs were not generated until several steps into the request processing flow. As a result, the access request status endpoint could only confirm that a request was accepted, without providing a specific ID. To retrieve the request’s status, attributes like the requester, requestee, and requested item had to be used to locate the record, which could sometimes be less precise.

Solution

With this change, the response to the create-access-request endpoint (beta, v3, and v2024 versions) returns a list of one or more accessRequestIds, nested within a recap representation of the request:

Example:

{
    "newRequests": [
        {
            "requestedFor": "343f2c112ca24159b3ee6287c4db1110",
            "requestedItemsDetails": [
                {
                    "type": "ENTITLEMENT",
                    "id": "2c91808900ead52e0178fb9516624c00"
                }
            ],
            "attributesHash": 241198532,
            "accessRequestIds": [
                "8b4c12f95c664119b72df781f7fbf03f"
            ]
        }
    ]
}

You can then call the list-access-request-status (beta, v3, and v2024 versions) with one or more of those IDs as an accessRequestId filter to retrieve the status of a specific request or requests as follows:

beta/access-request-status?regarding-identity=me&limit=10&offset=0&count=true&filters=accessRequestId in ("8b4c12f95c664119b72df781f7fbf03f", "a7e482bbafd647f899e427c6d70292d8")&sorters=-created

Note: Even when searching for only one ID, this must be expressed as an in filter.

As a secondary benefit, this enhancement will also add into the My Requests lists a record of any request which fails early validation checks, such as duplicate requests. Those new entries will be marked Canceled, with the reason for cancellation explained in a comment on the record. The requester will still also receive an email notification that the request failed validation.

Who is affected?

This will be available to all customers once rolled out.

Important Dates

This will be enabled in customer sandbox environments on Monday, November 11th, 2024.

The rollout to customer production environments will be during the week of November 18th, 2024.

[angelo_mekenkamp]

Awesome! Great improvement, thank you @jennifer_mitchell!

Looking forward to try this out

[tysremi (Remi Tys)]

Great addition!
Will the access request ID also show in the UI upon access request creation?
That would really help users to get better support in case they need it, since they can share the access request ID with our support team.

[adamslamena]

Great improvement !!

[adamslamena]

this would be an amazing addition to this improvement. Having a request ID makes all the troubleshooting or answering questions so much easier. The users are also used to getting Ticket IDs when submittign IT inquiries.

[mehuljogi (Mehul Jogadia)]

Really good enhancement for access request.
Thank you for adding it.

[jennifer_mitchell]

Hi @tysremi -

It already does! If you go to the My Request page, you’ll see that each card includes an Access Request ID. And if you hover over it, it gives you a copy option so you can copy and share the ID as needed.

[tysremi (Remi Tys)]

Hi Jennifer,

Thanks, that looks good.
However I meant in the screen you get right after submitting a request.
If it’s possible to display it there, that makes it easier for business administrative users to find their specific requests for others later.

[jennifer_mitchell]

Oh, I see! We can consider that for future work. Thanks for the input!

[angelo_mekenkamp]

Hi @jennifer_mitchell,

I played around with it for a bit (just through API, no UI tests yet), and this is what I have noticed so far:

1. If I revoke one or multiple roles at a time from an identity, the returned values for accessRequestIds do not match with the values for accessRequestId when calling GET /v3/access-request-status/?sorters=-created.
2. I have not yet been able to request/revoke something (for multiple people, multiple roles or both), where a value of accessRequestIds returned more than 1 value. Why is this field attribute plural and the value an array and in which cases can we expect 0 or multiple values?
3. You mention Note: Even when searching for only one ID, this must be expressed as an in filter.. I nevertheless tried it with an eq filter and it also worked! Granted, this eq filter option is not documented in the API documentation, but neither is the in filter option. Is there a specific reason to use the in attribute, or is eq actually also supported?
4. If I request to revoke access (that my identity already had for a long time), wait until it is finished (checking status for this, knowing the ids are mismatching according to point 1), and then request the access again, I get a existingRequests output, with as accessRequestIds the id of the same response as when I requested revocation. Nevertheless the access got added again. Is this process relying on the search module? Because search has an SLA of 24 hours and is unreliable for activities like these, as I understood from the PO of search.
5. Probably not related to this specific change, but if I request revocation of something that I already requested revocation for, I am getting a 400 error instead of a existingRequest message, with, depending on how much time has passed either this error: has outstanding requests for the following access item(s) or this one does not have the following access item(s) assigned:.
6. The basic flow looks really nice! I created a brand new role with manager as approver, requested it for myself, got a response with newRequests containing accessRequestIds with value [b1a52adcd1f5417d85ca587825d026ac]. Then I searched for it with GET /v2024/access-request-status/?filters=accessRequestId eq "b1a52adcd1f5417d85ca587825d026ac" and saw the status with pending on approval phase.
7. If I then repeat step 6 with the same role and identity, I get existingRequests with the same value for accessRequestIds.

Kind regards,
Angelo

[jennifer_mitchell]

1. The revoke issue was brought to my attention today and we are investigating. I’ll update here when I have more info.
2. Does your tenant have bundled provisioning by some chance? If not, if you request for more than one person and more than one item, you should get a list of IDs - one per user-item combination. But with bundled provisioning (only in use by a very small number of customers), you’ll always get 1 ID per request submission.
3. I will ask. I was told eq won’t work, and I recall that previously it didn’t, so your report surprises me.
4. I will raise this existingRequests question to my team.
5. Unsure. I’ll ask.
6. I appreciate the positive feedback.
7. I presume this is what you expect. It makes sense to me.

[angelo_mekenkamp]

Regarding 2: We don’t, but these are the format I get the results in:

{
    "newRequests": [
        {
            "requestedFor": "2c9180867d05b227017d09921a345b50",
            "requestedItemsDetails": [{"type": "ROLE","id": "09b5302ac85647189f464c037b45d408"}],
            "attributesHash": -159757442,"accessRequestIds": ["f92fbf46002a44c5ac8480dcd65337ad"]
        },{
            "requestedFor": "2c9180867d05b227017d09921a205b4d",
            "requestedItemsDetails": [{"type": "ROLE","id": "6a268eac844247b6b99a0867d338320d"}],
            "attributesHash": -22131524,"accessRequestIds": ["1075b4d28dbc466cbc87c4c3b32b2cfa"]
        },{
            "requestedFor": "2c9180867d05b227017d09921a345b50",
            "requestedItemsDetails": [{"type": "ROLE","id": "6a268eac844247b6b99a0867d338320d"}],
            "attributesHash": -22131524,"accessRequestIds": ["ff02a81b7cb74549a2589901c2e5ee44"]
        },{
            "requestedFor": "2c9180838186f5d801818a1b38193947",
            "requestedItemsDetails": [{"type": "ROLE","id": "6a268eac844247b6b99a0867d338320d"}],
            "attributesHash": -22131524,"accessRequestIds": ["80585f64624e43a8b28db00a83db0f10"]
        }
    ]
}

Very clear as you know which role-identity pair belongs to which accessRequestId, but each of them return an array.

For 7. Yes this is what I expect, just a confirmation that that part is working

[jennifer_mitchell]

I have tested myself in the meantime too, and now I see what you meant on 2. I am asking my team why. Thanks!

[jennifer_mitchell]

All,
There was a missed set of logic with the access request ID info in revoke requests. We are going to address this initially by not returning the response body for revoke requests until we can resolve the issue. Expect that change to appear in sandboxes in the next day or so. Grant access requests will continue to return the ID(s), as that is functioning as expected.

(For Angelo, this has a direct impact on your questions 1, 4, and possibly 5. But I should have more details on 4, 5 when the revoke responses are reinstated.)

[andrejhautzel]

Hi,
I noticed a bug, which didn’t happen before the 11th november, so I think it’s related to introduction of this feature. When I try to order an access profile which should produce a sod conflict, it’s unable to show the sod conflict, it shows the request like there is no sod conflict at all. I noticed this on the sandbox of a client and our own.

[angelo_mekenkamp]

Performed some more tests, including UI based tests:

1. Requested a role with manager approver and whilst still pending, requested the same role again. Result in the UI does not mention the reason for cancelling:
   
   
   
   Mail successfully mentioned reason:
   
   
2. Had a pending request for a while already, cancelled this one with comment: “test cancel 123”. Then checked on the status, which said I cancelled the request, but the reason is also not visible here. But perhaps this was not visible before either.
   
   
   
   
   
   
3. While continuing testing I noticed for 1 and 2 that the reason for cancelling can be found as part of the comments.
   
   So from a technical perspective this is visible. From a business perspective this is just a list of comments and it is not clear which comments are related to making the request, which comments are related to approving or reassigning the request and which comments are related to cancelling the request. For example you can get this right now, in separate pages:
   
   
   

I have some minor suggestions, that might make it more clear to map comment to action, such that you get something like this:

Layout could be better, but In this way it will be visible in one screen in a quick look that the request is cancelled and also why.

4. Another option I think would make sense is too have the comments listed as tab in the details as well, like this:
   
   
5. Not a test but a question. I see that the returned accessRequestId is also the primary id of an object in /v2024/account-activities. In addition I see that this object has an attribute items with as value and array with only one object (will there ever be more than 1 for access (revocation) requests? This item has another id. If we go to the objects in GET /v2024/access-request-status, we find the object with attribute accessRequestId and it also has attribute accountActivityItemId, whose value resembles the id of the item in items in /v2024/account-activities. I wonder if in GET /v2024/access-request-status there is always a unique 1-1 mapping from accountActivityItemId to accessRequestId and vice versa. Which of the two can I consider as primary id for the object in GET /v2024/access-request-status and which one is more of a foreign id? Note that there is no attribute id on these objects itself.
6. I agree with @tysremi’s suggestion, good one!
7. I can see the added benefit of also having a single id for a bulk access request. Such that if someone requested role C for identity Y, and we wonder why, that we can see that this was because of bulk access request R, where in bulk access request R, we can see that the requester requested roles A, B and C for identities X, Y and Z. This would allow us as auditor or as admins to understand the cause of an unexpected request occurring. From the requester perspective I can see the added benefit of also having an option to see results grouped by bulk access request. As API you could then call an API with this bulk access request id to get similar information you get as you will now get in the 202 Accepted body, but then up to date.
8. Pending and Cancelled have the same grey background in the UI. Perhaps this can be changed for user friendliness. This helps tracking the ones that are still actually pending (a filter could also achieve this).

Still very excited to use this. Just trying to understand the behavior and intricacies to determine how to properly utilize this functionality. I definitely see it is moving in the right direction, especially when the revocation bit is fixed and added as well

Kind regards,
Angelo

[jennifer_mitchell]

@angelo_mekenkamp - Thanks for all the info.

First 1-4: This is as-designed behavior. Manual cancellation has always logged the reason in the Comments, so for consistency, we put the reason for cancellation by system in the same place. I agree that it would be a nice enhancement to make that more visibly connected in the UI. We’ll consider that for future work. (This was a backend-only change whose UI changes came based on existing logic.)

5. As I understand it, yes, that accountActivityItemId does map to the accountActivity record. I honestly haven’t explored it in depth, but the accessRequestId is primary for the access-request record (and status endpoint); the activity one is the foreign id connection point.
6. Thanks.
7. This is something we can consider as an enhancement (not planned).
8. I’ll talk with UX/UI about this point, for future consideration. Thanks.

[angelo_mekenkamp]

I really appreciate you taking into account our feedback @jennifer_mitchell! Thank you for the quick and honest responses! I understand your choices on what to address later and what to address now.

[jennifer_mitchell]

@andrejhautzel
I have strong suspicions this SOD issue you mention is not related - that the timing is coincidental. I’ll raise this to my team, but I suggest you also open a support ticket to chase it down through that channel.

[ishudeep]

@jennifer_mitchell
I tried to submit the access request for an ACCESS_PROFILE but this api seems to be not working for that. Although it’s returning the Access Request Id but no access request is submitted. And if I am using that Access Request Id in Access Request Status api it’s returning null. Can you please check on this.