Hey everyone,
We’re currently managing a role that has a set of identities, and therefore doesn’t rely on dynamic criteria. Our need is to change this role to a criteria based one.
Do you know if we can change it with keeping the list of identities? If not, what could be the workaround to integrate the previous users, especially that some of them won’t fit with the new criterias?
Thanks.
Are you looking for an interim solution for keeping access for the list of users while defining the requirements for the criteria based ones so that the list users do not lose the access accidentally?
Or are you looking for a way to have users be assigned the role, as well as having a way to grant users the role when they do not meet the criteria you’ve defined?
Hi @gmilunich ,
The idea is to have no impact on the existing users. Saying so, I could accept any solution.
Are you looking for an interim solution for keeping access for the list of users while defining the requirements for the criteria based ones so that the list users do not lose the access accidentally?
Criteria have been defined, and some users doesn’t fit in all of them, so I’m afraid they’ll have to go to the request center and ask for the same role.
Or are you looking for a way to have users be assigned the role, as well as having a way to grant users the role when they do not meet the criteria you’ve defined?
Same thing here, are you suggesting exposing the role to be requested through the request center?
Ideally you would have visibility into who had this role and how they got it.
You could handle this by having users who don’t meet the automatic criteria use the Request Center to gain access to this role. This allows you the visibility to see that those users were granted the access by requesting it, rather than qualifying. This is useful later for Auditing and certification. This allows you to have a single role for granting access. However, you seem to want to avoid this.
Another option I have seen used in IIQ instances is that there was an exception entitlement/role that was requestable that was used to grant certain users access to the role/application/etc and that was also used to certify/audit those users. So the criteria would be added for “Role A” and then you’d have a second, requestable role/entitlement “Role A Exception” that the user could request and could be added to the criteria for “Role A”
The last thing I could see is that you could have 2 separate roles, say “Role A” and “Role A Exception” that both grant the same things, but “Role A” would have the Criteria, and “Role A Exception” would use the Identity List. This means you’d have to maintain both roles to keep them in sync though
The last thing I could see is that you could have 2 separate roles, say “Role A” and “Role A Exception” that both grant the same things, but “Role A” would have the Criteria, and “Role A Exception” would use the Identity List. This means you’d have to maintain both roles to keep them in sync though
This is a good solution, the only caveat is effectively maintaining 2 roles for the same permissions.
What I think about now is changing the role to a criteria based one, and then use the API to request access for the users who doesn’t meet them, meanwhile disabling validation to avoir being spammed and having to validate more than 30 access requests.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.