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.
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.
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).
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.
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.
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?
Hi Elisa,
This change was implemented in response to customer input that they didn’t always want to have to associate access profiles with applications to present them for access requests. Access Profiles have long (maybe always) been requestable by default - they just weren’t visible outside of applications before - and there are some design factors that prevented our reversing the requestable flags with this change.
For your existing access profiles, we have offered some API endpoints to allow you to manage which ones you want to make requestable. If your organization is focused only on roles, you might choose to make all access profiles not requestable. We posted a document on Compass in Jan or Feb (not sure if it got posted here too, so I’m attaching it as a PDF to this reply) to guide you through how to use the endpoints to identify the access profiles you might want to alter and then change their requestability.
I do think that we can improve this behavior by altering the default state for new access profiles to be not requestable until you specifically choose it, and I will work with my engineering team to change that default. Until we can get that work prioritized and done, please be sure to change that selection for any access profiles you create that you don’t want to allow requests for.
Jump in here, it would be so nice if you could also choose whether to make a requested role “sticky” or not. That has bit us so many times and if we could make it part of a request setup, it would help tremendously.
Having “new” access profiles not requestable by default would be an excellent solution as it will allow our organization a better control on the accesses we allow in the Request Center and configure proper approval processes for them.
I think Sarah shared some endpoints to run some reports and swap the unexpected requestable access profiles to non-requestable state, but it didn’t look like a procedure to apply once and for all, so it didn’t look like a sustainable way to grow connections and create new roles out of discovery sessions as we will have to flip all access profiles after they’re created.
I’ll check the attached PDF and I’ll share it with my team for further reference.