Enhancement: Significant Enhancements Made to New Request Center

Announcements Product News
, ,
22

Is there a bulk method supported to disable Access Requests for all Access Profiles? If it’s SailPoint’s product decision to all of sudden turn all of these to Enabled, surely there has to be a way customer’s can make a request to have them all Disabled.

@SarahKhan How can you give customers control over leaving Access Requests disabled and then later make the decision to make it enabled? You have just changed a customer’s resource - the Access Profiles themselves are not SailPoint’s to change, they are the customers.

Who else can I provide feedback to? More customers will be communicating this as it hits Production soon and they get blind sided by this. It’s one thing to make a change to the UI, it’s another to start changing customer’s resources. Poor form SailPoint.

23

Is there a way to generate a comprehensive report on all access profiles associated with applications? This report will allow us to identify and selectively disable the request option for access profiles that should not be requested.

24

First, make a GET call to v2/identity/apps/?offset=0&limit=50&count=true&excludeLauncherOnlyApps=true&excludeAccessProfiles=true
This returns a list of data about your applications. From that response body’s list, you need to isolate/pull out the values of “appRoleId” of each application for use in the next call.

Then you need to make a GET call to beta/requestable-objects/search?offset=0&limit=50&count=true
Passing in this request body – except that ID1, ID2, ID3 need to be the appRoleIds for each application. They need to be comma separated and in quotes (separate lines not required but maybe easier to build/read).

{
“indices”: [
“accessprofiles”
],
“filters”: {
“apps.id”: {
“type”: “TERMS”,
“terms”: [
“ID1”,
“ID2”,
“ID3”
]
}
},
“sort”: [
“name”
],
“queryType”: “TEXT”,
“textQuery”: {
“terms”: [
“*”
],
“fields”: [
“name”,
“description”
],
“matchAny”: false,
“contains”: true
}
}

Note that “description” in the Fields list is optional. If you just want the names returned, omit it.
Then you can make sure that any access profile that is not one of these gets set to not requestable.

25

Hey AJ,

thank you for taking the time to meet with us today. We are coming up with a plan to allow for bulk updates to APs and will make sure you do not receive the new RC until this is in place.

26

Following up on this, I was just playing around the “Role Discovery” and I created my first role. As “expected” after the introduction of this change, all access profiles generated by Role Discovery are now requestable!

If we’re building roles based on tailored searches, why would I want to have all those generated access profiles requestable in the first place?

If I didn’t follow this thread, I wouldn’t have known/imagined the generated access profiles were going to be available for my end-users in the Request Center, and it doesn’t make sense the extra step to make them non-requestable, either via the UI or API calls.

This was a long thread, so maybe I just missed the reason of these changes, @SarahKhan could you please explain to me why the new Request Center needs access profiles made requestable by default?

Also, given all the arguments provided regarding security and extra work thrown on customers that need to enforce strict approval processes to meet compliance, are you and your team reconsidering this?

I’ve seen other PMs opening enhancement projects to apply feedback provided by the community, is SailPoint planning to do this any time soon?

Thanks!

27

Hi @SarahKhan, any input to my questions above?
Thanks,
Elisa.