We are excited to share the revamped new Request Center, the updates made to the new Request Center allow for a easier search experience, allowing you to search all requestable items and search using partial word match. Additionally, the enhancements allow for a more efficient submitting process, allowing you to bulk submit items that act independent of each other.
Existing new Request Center Customers: We have listened to your feedback and we have made the enhancements you requested. The enhancements make it much easier to search and find items as well as making it easier to request and submit requests.
Legacy Request Center Customers: We have bridged the gaps between the legacy and new Request Center, this enables you to perform everything you did in legacy request along with additional enhancements. These enhancements allow for an easier experience when searching and submitting access requests.
We are excited to announce several significant enhancements to the new Request Center!
Finding the access you need is easier than ever, with the search functionality now supporting partial word matches and “contains” searches on names and descriptions. Search results are sorted by relevance, with exact matches at the top of the list.
Access profiles can now be enabled for request with or without associating them to an application.
Users can now include items from any of the access tabs in a single request.
Once a request is submitted, items requested together can now be managed completely independently. Each item can be provisioned as soon as it is approved, without waiting on other items’ approvals, and the requester can cancel a request for one item without affecting other items in the request.
Call to Action: Please work with your CSM to migrate over to the new Request Center
Dates of Release:
Available in Sandbox environment for opted-in customers: September 27th
Pushed to all opted-in customers: October 20th
Start Date for 3 Phase segment release for legacy request center: December 15th
Although I still need to hear from our Professional Services whether they changed something in our backend that caused unexpected results to our approval processes, I wonder if this new release has introduced a bug that forces app and source admins approval to all requests, even the ones that do NOT have them as reviewers.
Is anyone experiencing this in Sandbox??
UPDATE:
Never mind, it seems we forgot to “Apply changes” after setting up access profiles and roles. The approval processes are now requesting only approvals intended by the setup we configured in the Admin console. Sorry for the noise.
Glad to hear it Sarah! These changes are going to be awesome.
I don’t know if this is something your team has heard or not, but what I’d love to see inside request center would be a way for admins to view all requests without having to go to search.
Thank you for the announcement. We noticed the improvements of search recently and we are very excited for the migration. Nevertheless this is a very big change and we wonder if there is documentation available on how the system will behave in the following ways?
1: We currently have an application with access profile A and without access profile B. So only access profile A can be requested and access profile B can not be requested. After the migration. Will access profile A still be requestable and will access profile B still be non-requestable?
2: I currently have a role without end-date and request the role with end-date tomorrow form the request center. Will a request get created? If so, will it go for the grant approval flow or will it take the defined revocation approval flow? What happens if the request gets approved and what will happen if the request get denied?
3: identity A has role X with end date next month. I request role X and Y for identities A and B without end date. Both roles have no approval flow. What will the end date of role X be for identity A? Will it stay next month, will it become indefinite?
4: I request 2 roles, for different sources, both get approved. One provisions correctly, the other has provisioning issues. Will both items under my_requests get the message “Contact Helpdesk” or only the one that provides issues? Is this in line with the following annoucement? See also: ETN IDNUI-2950
Blockquote * Once a request is submitted, items requested together can now be managed completely independently. Each item can be provisioned as soon as it is approved, without waiting on other items’ approvals, and the requester can cancel a request for one item without affecting other items in the request.
5: Someone requests a role for me with end date X, it is pending approval. I then request the same role with end date Y. Will this override the original one, or will the newer one get cancelled? If both requests coexist and are approved, which date will be the end date? What if one gets approved and the other denied? Will the requester get notified of what will happen and prevent them from getting confused over a non-created request?
This update was perfect when requesting multiple items together, however, it still bundles all access items together on removal after a certification has been signed off. Is this a known bug or a feature that won’t be changed?
In our ServiceDesk integration, requested access is managed independently 1:1, so that 1 access request = 1 ticket in service desk integration. On off-boarding however, when these access-profiles are removed via Certification campaign, it is all bundled into 1 request and 1 ticket in service desk integration for multiple access items.
It would be nice if the Certification Campaigns where items are removed on sign-off also follow these new updates where an access profile is managed independently.
Is there a way to restrict access request from UI but still allowing access request thought API?
If we turn off the allow access request checkbox, then the API access request is also blocked
Access profile A will be requestable, if access profile B was created a long time (maybe a couple of years) ago then it will be requestable by default. They can mark requestable (allow access requests) to false or they can disable it if that’s the case.
Yes, the request will get created and will go to grant approval workflow since the requestType is GRANT_ACCESS If it gets approved then on the end_date it will start the revocation. If it gets denied then nothing is changed
The request does go through,the end date will be indefinite
Only the one that has provision issues will show contact helpdesk. Yes, this is the new enhancement.
Hi @SarahKhan, thank you for your responses. I have some responses to this.
We have noticed this and we had to update ALL access profiles that were not assigned to applications to prevent SailPoint from suddenly making them requestable without our intervention. I think making access profiles requestable by default is violating the principle of security by design. Since access profiles don’t have any approvers configured by default, they should also not be requestable by default. Now each time before you create and enable an access profile, you have to perform steps to prevent it being an access profile that is requestable by everyone for everyone without any approval needed. Roles are also not requestable by default after creating/enabling a role so why are access profiles?
Then this is allowing end users to bypass a security control. They can bypass the revocation approval process this way. The UI is using the wrong requestType here in my opinion.
Perfect, thank you!
Perfect, thank you!
I haven’t seen your answer to question 5 yet. Could you please take a look at it?
I’m really curious about this decision: Is there an upside to having access profile requests enabled by default from a Governance standpoint? Because like Angelo mentioned, it could lead to unnecessary access requests, and if there are no approvals in place, unmoderated auto-provisioning. Just wanted to understand the rationale behind it. Because some Access Profiles might just have been created to provide as a part of automated roles, and if users can request those separately, I think it kinda beats the purpose of a role. What do you think? (I could be wrong, so please correct me if I am.)
5: Someone requests a role for me with end date X, it is pending approval. I then request the same role with end date Y. Will this override the original one, or will the newer one get cancelled? If both requests coexist and are approved, which date will be the end date? What if one gets approved and the other denied? Will the requester get notified of what will happen and prevent them from getting confused over a non-created request?
The second request will go through but will fail before generating an approval saying Already has a pending request for this item This error message will be received via email!
