GRC EAM Authorizations: Few Anomalies in Standard Roles

Question

Hi GRC/ Security Experts,
To brief you quickly, we have an SAP GRC AC 10 SP13 about to be deployed with ARA & EAM Modules as a first phase deployment.
All of the functionality is almost setup, just refining few things before going live.
About the GRC Authorizations, I observed few anomalies in the standard delivered SAP Roles for EAM.
I am aware that processes & compliance's, can vary from organization to organization. I am trying to redesign some of the EAM related authorizations, especially for Firefighter Owner/Controller.
In the standard delivered EAM roles, there are few things missing and few unnecessarily attached.
I am already aware of the provided information in the following resources:
- 1730649 - Firefighter owner can assign ANY Firefighter ID to Firefighter User
- 1663949 - EAM: Authorization Fixes for Central Owners and Reason Codes and have referred to EAM Authorization
- EAM Authorization Concepts & Guide
- GRC AC Latest Security Guide.
I am wondering, many of GRC AC 10 implementations must have gone live by now, and how can be the following authorization hardening concerns be addressed.
I observed the following anomalies, and used ST01 tracing to refine and address few of them still some of them I cant seem to get hold of:
1) [SOLVED] EAM Owners should technically not be allowed to Create/Maintain Reason Codes, that should be EAM Administrator's task. This was addressed by adjusting the auth objects from Owner's Role and only Reason Codes Display was provisioned to the owner's, hence this is addressed.
2) [SOLVED] EAM Owners should not be allowed to Create/Maintain EAM Controllers. This is a grey controversy I believe, as in my organization EAM Controller is treated on even Higher Scale than Owner and thus EAM Controller maintenance should only be done by the EAM admin rather than EAM Owner. This also I have addressed by adjusting few auth objects, which leaves the EAM Owners with Display only access of EAM Controllers.
3) [UNSOLVED] EAM Owner is able to assign any Firefighter ID to End-User: This is anomaly as per me, and is also specified in notes 1730649 & 1663949, but I find it hard to figure out the real solution of that specific issue. The notes just point to EAM Authorization Guide, which explain the GRC Authorization concept in general, which I of course get it. The GRC SP13 is already higher than the one applicable for the issue.
Technically EAM Owner should only be able ASSIGN the FF IDs that are Owned by him, this I cant seem to figure out how exactly.
I have gone through the Authorization Guide, Security Guide, Played too much with System Trace ST01 trying to redesign the authorizations. How would you have done it? This wasn't there in Virsa earlier, it used to bug you back saying that FF ID is not owned by you.
4) [UNSOLVED] Similarly like above, EAM Owner is able to modify assignments/delete assignments of any FF ID. This is of course cascaded from the above issue. I believe it doesn't has to be like this, EAM Owner should only be able to access/modify/maintain the FF IDs owned. Maintenance of the FF IDs not owned by EAM Owner should be truly abstained.
5) EAM Owners should not be able to Add/Delete the Assignments of Owner with FF ID. This is the starting point of the Firefighter Structure and must be restricted to EAM Administrator. In the Standard EAM Owner role, an EAM Owner can created another OWner, assign a FF ID to another Owner, Delete a Owner-FF ID assignment. EAM Owner should have display only access as far as it is concerned about the EAM Owners access Area. This one I have yet to test, which I think would be possible. Can't get hold of points 3 & 4.
I have already studied/implemented the suggestions/recommendations/corrections from Authorization Guide.
But i still feel that these are few loopholes and must be closed before I conclude the implementation.
What do you think?
Would truly appreciate, if you can point out the objects and values that can help to address the open issues.
Apologies, for such a lengthy post, but the authorization goes deep here I guess and ST01 isn't helping me anymore to get over this.
Regards,
Akshay

Answer 1

Hi Colleen,
Thanks for your reply, I was sure I will be getting first response from you, as you are really proactive in GRC Space.
W.r.t. your suggestions:
1) I am not able to follow what you mean by "Are you able to try debugging "CALL METHOD cl_grac_auth_engine=>authority_check" ?? I am not much of a ABAPper/DEBUGGer, but if you can point what exactly is to be done/or to be get done I wouldn't mind getting my hands dirty at this too.
Correct me if I am wrong, do you imply that, even though the specified correction in note is available in system (SP13), still this inbuilt authority check is not happening and is being bypassed?
2) I checked the EAM Authorization Guide for Auth Object GRAC_USER.
With what you feel in the below message of yours=>
Starting to wonder if it is as the EAM Guide attached to the above notes mentions authorisation GRAC_USER which contains a field for user (quote from guide below).
User ID : This Field Specifies which firefighter users you can Display and Perform other activities based on the Activity Field .
That suggests you need different roles to restrict owners? I would have thought SAP would differentiate between authorisation to maintain FF as and Administrator versus Owner allow access to their Ids.
I would have thought Administrator would get the GRAC* authorisations whilst Owners would obtain access via owner setup (mapping for FF Id)
I went back to the EAM Guide and tried to put it all together to make sense.
With my below observations, I think too that there is no such thing as mapping of FF ID with the Owner, out of the Box in GRC AC 10 so that Owner is able to access only the FF IDs owned.
So, if that would be true, then to achieve this sort of wish, I would have to have separate roles from each EAM Owner specifying, the FF IDs that particular EAM Owner is able to access. And then there would be n number of Roles for n number of Owners, which is subject to change and has to be maintained again. Then also, the FF ID owned could also be added/removed etc, Whoa! That wouldn't make me far away from rationalizing the whole objective.
I just wonder, if this is actually Ok? If there is no approach to this, would it be OK to let any EAM Owner work with any FF ID subject to their own desire.
Anyways, check this out below , I will sideways open a message with SAP just to have my closure.
From EAM Authorizations Guide in the note=>
Now from the EAM Owner's Role=>
This no where mentions of Restricting the FF IDs in the Role, if at all this concept exists, it would be through some internal check like the one above i.e. CALL METHOD cl_grac_auth_engine=>authority_check or something.
Also, found these few specifications as well, which affirms the same I believe.
Much thanks for your effort and patience.
Regards,
Akshay