Customers want flexibility to add addition information into access requests beyond just selecting a defined access item from a list. One likely mechanism for supporting this need is through adding Forms to access requests.
Sound Familiar?
If this is a concern that impacts your organization, we’d love to talk to you about your use cases!
How You Can Help
The SailPoint Discovery process researches business problems for potential inclusion in future product development efforts. We are looking to deepen our understanding of the problem space, including how our customers would want the supplemental information to be applied in access request processing. Your input will help us with design and sizing of a potential solution as well as prioritization of the project in our future work.
Our Product Management team would love to hear from you! Here’s how:
Voice your thoughts, questions, comments, and concerns right here in this topic.
Vote on this idea in our Ideas Portal and share your use cases in comments.
Schedule a call to discuss this topic further and provide insights specific to your business problem and use cases. If you don’t see a calendar opening that aligns with your availability, feel free to send me a direct email.
Thanks in advance for your interest and participation!
There’s a few specific use-cases that might benefit from this at a few customesr.
1\ Right now there’s no specific way to select a target account for an entitlement during requests if a user has multiple accounts. Having a small form to just select the appropriate account would help here.
2\ We have a use-case where on a target Database users can have 1 of 2 authentication types (Kerberos or DB password).
Some applications on this specific DB require a user to have a DB password, while when connecting manually to the DB they would require Kerberos.
Having a small form available per source to input or select additional account provisioning data (that cannot be known upfront) will assist users in getting the correct settings on their accounts.
3\ For some applications it might make sense to have a form with connected inputs to guide users to the correct accesses.
Even with good descriptions, it might be very difficult to get a user to the correct access they need to request.
Have them answer a few questions in a form based on a dropdown and then propose some accesses for instance.
We had a similar case as mentioned by @tysremi under the 3rd use-case.
The current users have very less information about the roles/access they require. They are aware of what they need to do in the application but not about what they need(roles/access) to perform their tasks. Just having descriptions for those access profiles is not enough. If someway we could have another way for end users to get their roles/access, would be a great help to them.
One suggestion our client gave was to have a “Modeled After” option. So an user basically says I need the accesses that my colleague has to perform the same task as them. They had this implemented in their current system.
I am still new to SailPoint and IAM. In terms of security and best practices, is this a good option to have?
“Is this a good option to have?”
There are definitely different opinions on that.
The downsides:
It exposes individual users’ access, which could raise security concerns.
It could perpetuate overprivilege if the person you are modeling after has access they don’t actually need for their current role.
The upsides:
It can help speed new team member onboarding.
It can help in identifying likely correct access for a user who is trying to choose from a set of similar choices when the available info about access items is less than clear.
In essence, it’s not an ideal security practice but it is a business facilitation choice.
That said, today ISC does not offer this. Instead, our access request recommendations offer something related - a set of recommendations based on an analysis of similar identities that doesn’t highlight individual identities’ access.
This is already part of AI recommendations if I remember correctly, if access is missing based on a peer group analysis it would recommend a user to request certain access.
All the different systems have multiple roles. Currently we have to build these as a separate access profile. Sometimes an application can have around 50 different Access profiles, which just gets overwhelming for the end users.
Having one access profile, where the user would have to fill out a form with different drop down menus, that would then grant the role required, would be a way more user friendly experience, rather than having 50 different access profiles to go trough.
A good example would be Read/Write rights on a Sharepoint site. Currently, you need to create two separate Access Profiles. The user needs to click on the correct one (people just read the first two words and then decide that it is the access they need…).
Now if we could have one access profile, where the user needs to make a selection between read/write access, it would make it so much more easier and clearer for the end users
Hi @jennifer_mitchell , I enjoyed connecting with you today and discussing integrating forms with access requests. As previously discussed, we have used forms and workflows to collect additional information from requestors. However, this feature will assist us greatly in capturing the additional details at entitlement/role level and mapping them to account attributes in the case of direct connectors. Additionally, we have other use cases where users should be able to resubmit access with updated information, as well as revoke access with providing same context. I look forward to ISC releasing this feature soon.