AnsweredAssumed Answered

Request for role removal not working when user is both member of a parent and child role

Question asked by Marcel van Kekeren on Feb 18, 2020
Latest reply on Feb 20, 2020 by Mostafa Helmy

Like • Show 1 Like1
Comment • 8

Due to the way business roles are evolving in our organization users can be both member of a business role and the technical role that is an entitlement of the business role.

This causes strange behavior in the request process. the 2 main issues are:

A) as soon as the user is member of the business role there is no way you can remove the user as a member of the technical role.

B) When a membership rule or a request removes the user from the business role. the system generates a request to remove the business role, the technical role and entitlement c and group d, but after the request is fulfilled the user is still a member of the technical role b with missing the entitlements.

Issue A and B contradict each other.

If the system is "smart" and understands that the technical role is indirect entitled from the business role and should not be removed you would expect is to understand that if I remove the business role the technical role should also be removed. That is not the case and I need to create a second request to remove the technical role.

On the other hand if the system knows that the tech-role is both direct and indirect entitled and should not be removed from the user when de business role is removed. It should also know that the entitlements that are part of the tech-role should not be removed because the user is still a member of the tech-role.

adding to that, if the system assumes the user both direct and indirect entitled to the technical role why is there no option to remove the direct entitlement without removing the user from the business role first.

Question:

what is the expected way the system should handle this situation.
if this behavior is expected what is the logic behind this.
is there a way to change this. in other words, how can I bring back the option to remove the direct entitled technical role without removing the user from the business role. And have the request workflow not generating request to remove entitlements when the user is still a member of the technical role.

1 person has this question

Outcomes

Mostafa Helmy

Feb 19, 2020 7:13 AM

In short, A is expected behaviour by design while B sounds like a defect to me.

There are a lot of Role processing issues discovered and fixed recently in the latest patch (Fixed Issues in 7.1.1 Patch 5 ref: Role Management section). If you are not already on that patch, I would recommend you upgrade to get those issues fixed.

If you still face similar problems on that version, then I suggest you log a case with RSA Support to further investigate this.

Actions

Marcel van Kekeren @ Mostafa Helmy on Feb 19, 2020 11:22 AM

Mostafa,

Can you give some more input on what part of Issue B is in your opinion the defect. Because you could look at it in two ways.

B1) if you assume that the technical role is indirect entitled via the Business role, the defect is that the technical role is not removed.
B2) if you assume that the technical role is both direct and indirect entitled. the defect is that the entitlements are removed.

if it is option B2 the expected behavior of A is in my oppinion a design flaw.

Actions

Mostafa Helmy

@ Marcel van Kekeren on Feb 19, 2020 12:56 PM

Just so we are on the same page, are we talking about RSA managed roles or collected roles? If collected, does your collector have the deprecated HasData checkbox or not?

Actions

Marcel van Kekeren @ Mostafa Helmy on Feb 20, 2020 6:20 AM

We are talking about Managed Roles

Actions

Mostafa Helmy

@ Marcel van Kekeren on Feb 20, 2020 6:40 AM

Right, in that case here is my thoughts:

[Application Design] Once a user becomes a member of a parent role (BR in your case), all parent role entitlements (TR(s) in your case) are instantly treated as indirect entitlements, whether they were granted to the user directly before the BR or not.
[Application Design] This means any change in the parent role membership will cascade to all indirect entitlements granted through that role, unless those indirect entitlements are explained by another parent role they user is still a member of. For example:
- Users U1/U2 are members of BR1, which contains TR1,TR2.
- User U1 is also a member of BR2, which contains TR2,TR3.
- Now if you decide to remove both U1/U2 from BR1, the expectation is that the change request should remove only TR1 from U1 (since TR2 is still explained by the U1-BR2 membership) and both TR1/TR2 from U2.
- The same method of calculation applies on the TRs nested entitlements. So in the above case:
- Assuming U2 has TR1/TR2 (from BR1) and also TR3 (from some other BR or even directly).
- If TR1/TR2 share any sub-entitlements with TR3, then the above change request will not attempt to remove those shared entitlements while removing TR1/TR2 from U2.
Give the above points, and back to your scenario:
- It may be ok for TR-B to not get removed from the user when he gets removed from BR-A (given that TR-B is part of another BR-X that the user is still a member of).
- However even if that is the case, then the user should've definitely not lost any of the sub-entitlements in TR-B.
So the expected behaviours in your above scenario are either:
- User is removed from BR-A, TR-B and any of TR-B's sub-entitlements not explained by other active role memberships of that User.

User is removed from BR-A and not TR-B nor any of its sub-entitlements given that TR-B is explained by another active role membership of that User.

Any deviation from the above behaviour to me is a defect that needs to be fixed.

Actions

Edward Bertsch Feb 19, 2020 9:16 AM

"No one else had this question" seems to be displayed once an answer has been marked as correct. Is that just something we have to live with, using the Jive product? Or has RSA configured the forum to work this way? Even if the question was considered (by RSA at least) to be answered, seems to me that it's still helpful to know the number of "me too" customers about a given issue.

1 person found this helpful

Actions

Marcel van Kekeren @ Edward Bertsch on Feb 19, 2020 11:35 AM

Edward,

I agree that it would be helpful to know the number of "me too" customers and the forum should not block that option once a answer is marked as correct.

I removed the "answer is correct" marker because i cannot validate if it is indeed a bug fixed in version 7.1.1 Patch 5

Besides that in my oppinion the designed is flawed and RSA should restore de functionality that in case a technical role is both direct and indirect entitled you have the ability to remove the direct entitlement.

1 person found this helpful

Actions

Jamie Pryer

@ Edward Bertsch on Feb 20, 2020 6:26 AM

Hey Ed,

good point

We are actually moving over to a new platform later this year for the entire community, which is meant to be a LOAD better then this one. Once that happens, we need to check if that feature is there and then raise up if not for the whole community. Ive taken a note!

Actions

8 Replies

Mostafa Helmy Feb 19, 2020 7:13 AM
Mark Correct
Correct Answer
In short, A is expected behaviour by design while B sounds like a defect to me.

There are a lot of Role processing issues discovered and fixed recently in the latest patch (Fixed Issues in 7.1.1 Patch 5 ref: Role Management section). If you are not already on that patch, I would recommend you upgrade to get those issues fixed.

If you still face similar problems on that version, then I suggest you log a case with RSA Support to further investigate this.
Like • Show 0 Likes0
Actions
- Marcel van Kekeren @ Mostafa Helmy on Feb 19, 2020 11:22 AM
  Mark Correct
  Correct Answer
  Mostafa,
  Can you give some more input on what part of Issue B is in your opinion the defect. Because you could look at it in two ways.
  
  B1) if you assume that the technical role is indirect entitled via the Business role, the defect is that the technical role is not removed.
  B2) if you assume that the technical role is both direct and indirect entitled. the defect is that the entitlements are removed.
  
  if it is option B2 the expected behavior of A is in my oppinion a design flaw.
  Like • Show 0 Likes0
  Actions
  - Mostafa Helmy @ Marcel van Kekeren on Feb 19, 2020 12:56 PM
    Mark Correct
    Correct Answer
    Just so we are on the same page, are we talking about RSA managed roles or collected roles? If collected, does your collector have the deprecated HasData checkbox or not?
    Like • Show 0 Likes0
    Actions
    - Marcel van Kekeren @ Mostafa Helmy on Feb 20, 2020 6:20 AM
      Mark Correct
      Correct Answer
      We are talking about Managed Roles
      Like • Show 0 Likes0
      Actions
      - Mostafa Helmy @ Marcel van Kekeren on Feb 20, 2020 6:40 AM
        Mark Correct
        Correct Answer
        Right, in that case here is my thoughts:
        
        [Application Design] Once a user becomes a member of a parent role (BR in your case), all parent role entitlements (TR(s) in your case) are instantly treated as indirect entitlements, whether they were granted to the user directly before the BR or not.
        [Application Design] This means any change in the parent role membership will cascade to all indirect entitlements granted through that role, unless those indirect entitlements are explained by another parent role they user is still a member of. For example:
        Users U1/U2 are members of BR1, which contains TR1,TR2.
        User U1 is also a member of BR2, which contains TR2,TR3.
        Now if you decide to remove both U1/U2 from BR1, the expectation is that the change request should remove only TR1 from U1 (since TR2 is still explained by the U1-BR2 membership) and both TR1/TR2 from U2.
        The same method of calculation applies on the TRs nested entitlements. So in the above case:
        Assuming U2 has TR1/TR2 (from BR1) and also TR3 (from some other BR or even directly).
        If TR1/TR2 share any sub-entitlements with TR3, then the above change request will not attempt to remove those shared entitlements while removing TR1/TR2 from U2.
        Give the above points, and back to your scenario:
        It may be ok for TR-B to not get removed from the user when he gets removed from BR-A (given that TR-B is part of another BR-X that the user is still a member of).
        However even if that is the case, then the user should've definitely not lost any of the sub-entitlements in TR-B.
        So the expected behaviours in your above scenario are either:
        User is removed from BR-A, TR-B and any of TR-B's sub-entitlements not explained by other active role memberships of that User.
        OR
        User is removed from BR-A and not TR-B nor any of its sub-entitlements given that TR-B is explained by another active role membership of that User.
        
        Any deviation from the above behaviour to me is a defect that needs to be fixed.
        Like • Show 0 Likes0
        Actions
Edward Bertsch Feb 19, 2020 9:16 AM
Mark Correct
Correct Answer
"No one else had this question" seems to be displayed once an answer has been marked as correct. Is that just something we have to live with, using the Jive product? Or has RSA configured the forum to work this way? Even if the question was considered (by RSA at least) to be answered, seems to me that it's still helpful to know the number of "me too" customers about a given issue.
1 person found this helpful
Like • Show 1 Like1
Actions
- Marcel van Kekeren @ Edward Bertsch on Feb 19, 2020 11:35 AM
  Mark Correct
  Correct Answer
  Edward,
  
  I agree that it would be helpful to know the number of "me too" customers and the forum should not block that option once a answer is marked as correct.
  
  I removed the "answer is correct" marker because i cannot validate if it is indeed a bug fixed in version 7.1.1 Patch 5
  
  Besides that in my oppinion the designed is flawed and RSA should restore de functionality that in case a technical role is both direct and indirect entitled you have the ability to remove the direct entitlement.
  1 person found this helpful
  Like • Show 1 Like1
  Actions
- Jamie Pryer @ Edward Bertsch on Feb 20, 2020 6:26 AM
  Mark Correct
  Correct Answer
  Hey Ed,
  good point
  We are actually moving over to a new platform later this year for the entire community, which is meant to be a LOAD better then this one. Once that happens, we need to check if that feature is there and then raise up if not for the whole community. Ive taken a note!
  Like • Show 0 Likes0
  Actions

Request for role removal not working when user is both member of a parent and child role

Outcomes

Related Content

Recommended Content