Create-access-request API for non-requestable items

I am looking for API to submit/ create the Access request even though entitlement is marked as non-requestable ?

create-access-request | SailPoint Developer Community

When you build you payload do you get an error message for the object type you are trying to assign?

POST : {{baseUrl}}/access-requests

BODY:

{
  "requestedFor": [
    "8cfe5b64d9974XXXX14dacb024985f"
  ],
  "requestedItems": [
    {
      "id": "d6319162b21c4YYYY9d95ee491a",
      "type": "ENTITLEMENT",
      "comment": "Requesting access profile for Aabha"
    }
  ],
  "requestType": "GRANT_ACCESS"
}

RESPONSE :

{
    "detailCode": "400.1 Bad request content",
    "trackingId": "25402a6d354e4c738ac5dbefe7eb198a",
    "messages": [
        {
            "locale": "en-US",
            "localeOrigin": "DEFAULT",
            "text": "The following access items are not requestable: [d6319162b21c42ac9AAAA9d95ee491a]."
        },
        {
            "locale": "und",
            "localeOrigin": "REQUEST",
            "text": "The following access items are not requestable: [d6319162b21c4YYYY9d95ee491a]."
        }
    ],
    "causes": []
}
1 Like

Hey Vishal,

We cannot call an access request API and it will only perform the GRANT_ACCESS and or REVOKE_ACCESS only when you have made the said Entitlement/Access Profile/Role as Requestable within ISC/IDN.

So your first call would be to make the requestable API and then the access request API.

Thanks,
Aman

1 Like

Thank you Aman ,

I understand that we can’t make the API call for the access-requests until the request item is requestable and i can see that in error .

I am looking for any other API , which has capability / permission to submit the request even though the request item is non-requestable .

Hi Vishal,

it may not work if the entitlement is non-requestable.
I tried it when this feature was released a few months back, the API gave error as it was non-requestable.

Regards
Arjun

1 Like

it is not possible. Item has to be requestable if you want to request it.

What is your scenario / use case? What are you trying to achieve?

If you want to hide the item from access requests, then you need to create a segment so it not visible to users.

I want to generate access request as part of ncd detection .

Can you please provide more details on this solution? I will be having some similar requirements coming up in the near future where I will be asked to leverage API’s to grant access to a number of AD groups. We would want this to be completely transparent to the end users and to make sure that the Request Center is not visible with any access. But allow a system like ServiceNow to make an API call to request the access be granted.

I know that Managed Access in Service Now is available however the time to set it up and develop out all the required information is going to take a lot more time then if I work with the ServiceNow Team to set up the required API calls for their workflow for existing access request.

As others have mentioned, you cannot use the create access request API to request access for non-requestable items. Your access item(s) must be marked as requestable before you can use this API. I’m not quite sure what your use case is, but here are some suggestions for assigning access to non-requestable items.

  1. Temporarily modify the item to make it requestable so you can you submit the access request, and then immediately modify the item again to make it non-requestable. Roles, access profiles, and entitlements each have a PATCH endpoint to update the requestable field. Here’s the endpoint for entitlements: patch-entitlement | SailPoint Developer Community
  2. Add the entitlement to a role and assign identities directly to the role. This would not go through the access review process, so if you need some sort of approval/audit trail, you will need to build a system externally or in workflows to capture the approvals. You can use patch-role | SailPoint Developer Community to add identities to the membership array.
  3. As @jrossicare mentioned, you could create a segment to hide the entitlement. This would allow you to mark it as requestable but only a select group of identities can actually submit the access request. This group of identities could be admins or other privileged users that can submit the access request on behalf of other identities. I’m not sure of the exact details to make this work, but it could be worth exploring.
3 Likes

I want to generate access request as part of ncd detection .

I understand that we can mark temporarily entitlement as requestable , but i again it can have it’s own pro/cons.

Can you please elaborate? Why does native change detection require you to request non-requestable entitlements? Please be thorough in the description of your use case.

Thank you @colin_mckibben .

We want to generate the access request to be generated for the any NCD detection so that loop can be closed . it may happen that some of the high risk item detected as part of the NCD is non-requestable item .

We have explored the option to generate the form , but problem is that form can be assigned to one user only . also i think form can be notified only though the email it won’t be visible to the actor UI laying out that item is pending .

Is this to revoke an entitlement or grant access?

its would be for revoking the entitlement .

So from my perspective, ISC should be the source of truth for what access an identity should have on a source system. NCD will tell you when an identity has obtained out-of-band access (i.e. somehow they got access to an entitlement on the source without ISC granting it). If a user got access to something outside of the process provided by ISC, then you need to revoke that access directly on the source. You could either manually remove their access or setup a system that can automatically remove the access using the APIs provided by the source system.

Workflows can help with this. You can setup a workflow to listen to NCD events, and if you spot one then you can have the workflow invoke the HTTP Request Action to directly remove the out-of-band access from the user on the source. You could also create a micro-certification campaign to revoke the access. Check out this blog post by @Bassem_Mohamed. I think this can help you solve your use case.

3 Likes

I do agree with you @colin_mckibben that all the request should go from the central IGA . but in real time scenario that would be difficult and could have multiple different reason .

This solution is great but i see some challenges meeting my requirement

  1. Form can be assigned only to individual actor
  2. how actor will know if something is pending apart from email link.

When we talk about close loop i think its better to have the same approval process as when you raise the request for same item from ISC.

The blog post also mentions that you can trigger a microcertification campaign that only reviews the access item that was granted out-of-band. That would give you more control over the approval process.