AnsweredAssumed Answered

Automation with Role Data Collectors - Revoking Access via Rules

Question asked by Sasha Browning on Sep 8, 2015
Latest reply on Apr 27, 2016 by Luis Lenin Guerrero

Like • Show 1 Like1
Comment • 3

All,

I've setup a Role Data Collector (RDC) that contains an inventory of all roles, owners, members, and entitlements. I've now setup a rule for missing entitlements. Basically, if anyone is added to a role (managed by this RDC), then add them to the entitlements associated with that role. That's the easy part.

I was curious if anyone had worked out a solution to revoke entitlements when users are removed from this role. The RDC updates members (add/removes) based on the back-end database I'm collecting from. I don't know of a straight forward method of revoking access to users who were recently in the role (and no longer a member), but still retain entitlements associated with that role.

I'm thinking that RSA hasn't thought of this as a possibility, perhaps they're assuming we're simply relying on user access reviews to be generated when role memberships change or when a user attribute changes.

Anyone have any experience using role collectors in this fashion?

-Thanks

1 person has this question

Outcomes

3 Replies

Edwin Mullie Jan 28, 2016 4:45 PM
Mark Correct
Correct Answer
Problem here is that when you run the RDC and a role is changed it doesn't create a CR.

For the users that are removed there is no rule you can trigger. What you could try is to create a custom WF that runs once a day that checks these roles for members that have been removed and then create a CR (e.g. via web services) to remove all the authorisations for that user.

regards

Edwin
Like • Show 0 Likes0
Actions
David Friedland Feb 12, 2016 2:05 PM
Mark Correct
Correct Answer
Hi Sasha,

I have leveraged the OOTB Membership Rule when wanting to add and remove Roles. Granted I have always done this with ACM managed Roles, but the logic would still remain the same. When configuring the rule within the Role, you have the ability to specify which identities to apply the rule to along with generating the joiners and leavers change requests for this specific Role. See the screenshot for an example. Once you have checked off the ability to generate the CR, you can then look in the rules section. You will see two different rules that were generated for in constraint and out of constraint.
Hope this helps.
David
Like • Show 1 Like1
Actions
- Luis Lenin Guerrero @ David Friedland on Apr 27, 2016 4:58 PM
  Mark Correct
  Correct Answer
  Hello David,
  
  I read your answer and I think I'm using your solution, although I'm still short of the solution to my requirement.
  
  The request is simple: each time a user is added to an AD group, he/she must be granted some Aveksa entitlements that allow him/her to work with certain reports. Similarly, when said user is removed from the AD group, his/her entitlements should be revoked so the user won't have access to the reports anymore.
  
  I've created a role called "OpsMonitorTest" with a Membership Rule [users.id in groups (groups.Name like '%Courion ARM Admins%')] and three sample Aveksa entitlements: Access Request Administrator, Aveksa Application Administrator, and Aveksa Business Unit Administrator.
  
  Also, I created two rules, since I didn't click on the "Create change requests" checkboxes for When members do not match the membership rule, nor When non-members match the membership rule:
  My two new rules, OpsMonitorJoiner and OpsMonitorLeaver are defined as follows:
  
  After I create the role and click on the "Apply Changes" button, the role definition is committed. Then I manually process both rules and the users who are already part of the "Courion ARM Admins" group are successfully added to the OpsMonitorTest role and their correct entitlements are granted.
  
  Then I make a change to the group in AD, adding a new user and removing an existing one, I collect the data again so this will automatically trigger the two rules (they're configured to run after any collection) and they are processed, but they do not detect any suggestion (indicating a new user was added to the AD group) nor any violation (indicating an existing user in the group doesn't exist anymore in the recently collected data), however, when I check the group, the system shows the correct members after I did my changes on AD.
  
  Is there anything else I need to do to make this work? We've tried different conditions and combinations, including changing the Role Set's Policy:
  I hope there's a simple configuration setup to successfully implement this (we're still working with IMG 6.9.1.101054 P09)
  Thank you for your help!
  
  Regards,
  Lenin
  Like • Show 0 Likes0
  Actions

Automation with Role Data Collectors - Revoking Access via Rules

Outcomes

Related Content

Recommended Content