AnsweredAssumed Answered

Remove user from role action removes approle that was directly assigned

Question asked by Gokhan Gur on Nov 22, 2017
Latest reply on Aug 23, 2019 by Mostafa Helmy

Like • Show 0 Likes0
Comment • 3

Hello,

Please consider the following scenario and let me know if there is any solution for that

1- "User A" has "Account X" on "Target System 1"

2- "Account X" has "AppRole-Y" on "Target System 1"

3-Then, "User A" is added to a business role which contains "AppRole-Y" on "Target System 1" as well.

4-"User A" is later removed from business role.

In the request created, Remove "AppRole-Y" from "Account X" also present.

However, this approle was assigned to account X before he was added to business role so ideally he should have kept Approle-Y even if he is out of the business role.

How can we achieve that?

Mostafa Helmy

Nov 22, 2017 7:11 AM

Correct Answer

Hi Gokhan, this is actually by design to function this way. It does not matter how the entitlement was originally granted to the user. As long as it is now part of a Role he is member of, and is not part of any other Role is still member of, it will be removed by removing that Role.

One way you can get around this is by enabling approvals on indirect items, that way an approver can partially reject the indirect items being removed from the user in the change request workflow.

See the reply in context

No one else had this question

Outcomes

Mostafa Helmy

Nov 22, 2017 7:11 AM

One way you can get around this is by enabling approvals on indirect items, that way an approver can partially reject the indirect items being removed from the user in the change request workflow.

1 person found this helpful

Actions

Volodymyr Melnyk @ Mostafa Helmy on Aug 23, 2019 3:59 AM

Hi Mostafa Helmy,

Is there still no way to do that? We have a real business need for movers, when a user moves from one team to another a new business role is assigned to the user. At the same time we run a review for all users' previous accesses and we can decide what access to be kept. But there is a problem that we need to keep the user at previous business role --> which leads to a violation (the user doesn't match the rule anymore). Having users in Business roles of old teams is a complete mess, after a couple of moves around different teams business roles are full of violations. And a number of violations is growing as more movers you have....

We need a solution for movers case. Is there any ideas?

Thanks

BR,

Volodymyr

Actions

Mostafa Helmy

@ Volodymyr Melnyk on Aug 23, 2019 5:10 AM

The design is still the same. However looking at your use case, if the user still requires certain access from his old Business Role in his new Role, then ideally I would expect that the new Business Role he has should also contain the same common entitlement. For example:

User1 has AppRole1 on TargetSystem1.
User1 is added Business Role BR1 that contains AppRole1.
User1 changes Roles and now does not match BR1, but instead matches BR2.

Problem here is that if User1 is removed from BR1, then he would lose AppRole1. However he must be removed from BR1 and added to BR2. So if User1 in his new role still requires BR2, then I would expect BR2 to also contain AppRole1.

Now if User1 is Added to BR2 then removed from BR1, he should still maintain access to AppRole1 since it is still a part of BR2.

Actions

3 Replies

Mostafa Helmy Nov 22, 2017 7:11 AM
Unmark Correct
Correct Answer
Hi Gokhan, this is actually by design to function this way. It does not matter how the entitlement was originally granted to the user. As long as it is now part of a Role he is member of, and is not part of any other Role is still member of, it will be removed by removing that Role.

One way you can get around this is by enabling approvals on indirect items, that way an approver can partially reject the indirect items being removed from the user in the change request workflow.
1 person found this helpful
Like • Show 0 Likes0
Actions
- Volodymyr Melnyk @ Mostafa Helmy on Aug 23, 2019 3:59 AM
  Mark Correct
  Correct Answer
  Hi Mostafa Helmy,
  
  Is there still no way to do that? We have a real business need for movers, when a user moves from one team to another a new business role is assigned to the user. At the same time we run a review for all users' previous accesses and we can decide what access to be kept. But there is a problem that we need to keep the user at previous business role --> which leads to a violation (the user doesn't match the rule anymore). Having users in Business roles of old teams is a complete mess, after a couple of moves around different teams business roles are full of violations. And a number of violations is growing as more movers you have....
  
  We need a solution for movers case. Is there any ideas?
  
  Thanks
  
  BR,
  Volodymyr
  Like • Show 0 Likes0
  Actions
  - Mostafa Helmy @ Volodymyr Melnyk on Aug 23, 2019 5:10 AM
    Mark Correct
    Correct Answer
    The design is still the same. However looking at your use case, if the user still requires certain access from his old Business Role in his new Role, then ideally I would expect that the new Business Role he has should also contain the same common entitlement. For example:
    
    User1 has AppRole1 on TargetSystem1.
    User1 is added Business Role BR1 that contains AppRole1.
    User1 changes Roles and now does not match BR1, but instead matches BR2.
    
    Problem here is that if User1 is removed from BR1, then he would lose AppRole1. However he must be removed from BR1 and added to BR2. So if User1 in his new role still requires BR2, then I would expect BR2 to also contain AppRole1.
    
    Now if User1 is Added to BR2 then removed from BR1, he should still maintain access to AppRole1 since it is still a part of BR2.
    Like • Show 0 Likes0
    Actions

Remove user from role action removes approle that was directly assigned

Outcomes

Related Content

Recommended Content