ISC: Admins when only managers can request access

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Dear ISC community,

2 months ago we’ve reported an issue that even if the “Manager only” option was enabled under Enabling Requests for Others - SailPoint Identity Services , managers were still able to make requests for any user in the company. The documentation was mentioning something different:

Managers Only only allows managers to make requests for their direct reports.

In the end SailPoint fixed the issue, so that the behavior matched the documentation: managers can select and make requests only for their direct reports.

They also changed the behavior for Administrators. In my opinion this behavior modification came because of the way they implemented the change in the UI, not as a deliberate change:
ISC Admins are not allowed to make requests for all users in the UI, but they are allowed to do it over API.

Asking about this change, SailPoint needed 30 days of “working with our engineering team” to confirm that this is an expected behaviour (emphasis mine):

Many thanks for your patience, I had a further discussion with the engineering team and it is the expected behaviour that we are seeing right now.

We expect admin user credentials to be used for submitting requests from API-based integrations to ISC.

If you still needs to prevent this, You need engage PS team.

Please keep in mind that Expert Services is a billable service that is part of our Professional Services team.

In my opinion, admin users should have the same permission in the UI and over the API (the UI uses the API in the end). This also makes it clear which actions are available for admin users and which not.

Where should the distinction between what ISC admins can do in the UI and the API be drawn? Should admins be just normal users in the UI? Is this UI vs API permission difference documented anywhere?

What are your thoughts on this?

Best regards,
Andrei

2

Hi @adamian,

I concur with your perspective on the distinction between UI and API functionality. I have had similar reflections on this topic. While there may not be explicit documentation delineating the two, I believe a reasonable approach is to consider the complexity of the task and the user’s interaction preferences.

Regarding your specific question:

Where should the distinction between what ISC admins can do in the UI and the API be drawn?

I would suggest that the distinction should primarily be based on the administrative rights required and the nature of the user interaction. For tasks that are complex or require automation, APIs often provide a more efficient and flexible solution. For example, creating transforms can be quite intricate, and APIs can simplify this process.

Conversely, reports are typically more user-friendly when presented in a visually appealing format, such as a file. Therefore, a UI might be preferable for this task, as JSON output may not be as intuitive for most users.

In summary, the distinction between UI and API functionality should be drawn considering both functionality and the desired user experience.

3

I agree that there should be clear documentation outlining what can be done via the UI versus APIs. I’ve always viewed the UI and API as two different worlds, and when certain actions aren’t available through the UI, I have to check the APIs separately.

4

In my opinion, The UX should mirror the API permissions whenever possible.

Using the API should be an option, but not the only choice in a well-rounded/robust system.

1 Like