Retsrict Access request by User Group

[mark_wilson8]

Hello,

We have implemented ARM with workflow for approvals but restrictions on the functional area. A request is only permitted to assign / view roles for the functional area defined in the authorisations

The requestor should only be able to assign roles to users from their site (UserGroup) but from what we can see when the request is submitted the user can select any user in the system and submit the request . If approved at the seconf level the roles are auto provisioned without restriction. Is it possible to restrict a requestor to a specific user group or group of users.

Regards

Mark

[mark_wilson8]

Of course I am not referring to new users this is obvious just changes and deletions

We have a very restrictive role design based on the location (Plant). With Location A, not being able to see the data from location B, C, D...etc, We have over 300+ locations so we control the users by allocationg users to user groups that match the planat. So a user from Location A is only assigned roles for plant A.

The Financial controller from the site requests change for his users and the function location controls who approves the request, configured in BRF+. I am amazed that a tool allows a controller, who is responsible for location A to assign roles for location A to any user in the system without restriction or delete a user that is not under their control, even in error. This is a recipe for Fraud!

Hope this is clear

[Former Member]

I'm sorry, I must be missing the issue. If the role for Location A is configured to be approved only by  authorized personnel from location A, what difference does it make if someone from Location B requests it for a location B user? The location A approver rejects the request.  What am I missing here? Please help us understand the risk you are seeing.

Regards,

Gretchen

[Colleen]

Hi Mark

Gretchen has already summarised it. Requesting access shouldn't be a cause for access restriction. No differ to most things - anyone can complete and lodge a form but it's not a guarantee that it'll be approved.

Without an enhancement it cannot be done. Within MSMP, you can configure and route request to specific approvers based on the attributes.

Regards

Colleen

[rindia]

Hi Mark,

I am afraid that did i understood your question properly?

Imagine a scenario where a person newly joins the organization and a request is raised.

So it is obvious that he doesn't belongs to any usergroup.

Now how come a requester can raise the request based on usergroup for this new user?

Regards

Raj

[Former Member]

A better practice would be to not create users without user groups. The automatic job that creates the user ID should assign at least a basic user group,  such as ESS_ONLY or UNDETERMINED, and set up the GRC security so that anyone who can submit requests can modify users in that group as well as their own group.

How workable such a scheme would be is likely to depend on how granular the user group design is. If you have 200 user groups, do you really want to maintain 200 different versions of the requester role? Also, if users are constantly needing to be moved from one user group to another, it may not be practical.

.

Regards,

Gretchen