GRC AR - authorization for access request approval

[Former Member]

Dear Colleagues,

we run on GRC 10.0 SP13.

We use access request for FF assignment a we face the problem that approval of request is not protected by a special authorization object/ value as for example Hold button which is protected by GRAC_ACTN with activity Hold. In fact anyone who can create request can also approve.

Do you have the same problem or did I miss something?

kind regards

Igor Šturma

[Former Member]

Thank you for your comments, help and ideas how to make a workaround.

But I still think that missing authority check for approval/rejection is an security issue which should be solved by authority-check implementation.

Regards

Igor

[Colleen]

Hi Igor

Have you raised an OSS message or alternatively raised an improvement suggestion to have it incorporated. For the example you cited of Request != Manager I think that would be better managed via Configuration Parameter or EUP (an additional line similar to multiple requests for user check) so you have greater flexibility to control scenarios as opposed to just authorisations.

[Former Member]

Hi Colleen,

yes, we are going to raise an OSS message regarding this issue.

Igor

[Colleen]

Hi Igor

For "In fact anyone who can create request can also approve" - could you look at your MSMP workflow and put routing rule/etc in place so the requester cannot be the approver? That is, use Workflow to add the control instead of authorisations.

[former_member193066]

This can be done in EUP(end user personilazation)

Where you can restrict user to approve own request.

The EUP has to be ampped to stage in MSMP.

Regards,

Prasant

[Former Member]

Hi Colleen,

I have restricted this combination (requestor cannot approve own request) in customizing. AC - User Provisioning - Maintain End User Personalization and it works fine.

My issue is that manager can be manually added or overwritten by a requestor at a time of request creation. So if the requestor fills in any other requestor as a manager I am not able to restrict the approval of this request via authorization.

regards

Igor

[Colleen]

If you are defaulting manager, change eup settings to make manager field display only

If not, create brf rule to check if user is manager (possibly db look up)

[former_member193066]

Hello,

That feild remains editable because you can enter in manager detaisl if you dont have LDAP.

and if your Manager has been changed and the changes has not been reflected in LDAP than you can manually edit it.

Just my views.

Regards,

Prasant

[Former Member]

Unfortunately not for all users can be manager defaulted by system so this field must be editable.

BRF rule sounds like workaround for missing functionality but I would probably maintain a list of managers somewhere what is not very comfortable.

Anyway I very appreciate your help.

Igor

[Colleen]

Hi Igor

Pity - I wasn't sure if your process would force user to fix manager issues, etc

For the BRFplus Rule - wouldn't it simply be a case check if Requester Id = Manager Id (possibly the request table header has all this) and then determine where to route to

Therefore, if user overwrites Manager then they system is still enforcing your Request != Manager check. You could treat this as a routing rule or at initiator stage on where to send to. You would avoiding maintaining list of Managers (which you are technically doing already via import from LDAP or HR).