Skip to Content

GRC EAM Authorizations: Few Anomalies in Standard Roles

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

Add a comment
10|10000 characters needed characters exceeded

Related questions

5 Answers

  • Best Answer
    Posted on Mar 19, 2014 at 06:44 AM

    Hello All,

    @Colleen Lee With the workaround of having individual roles for Owners to be able to work out only with the Owned FF IDs, I have re-produced the scenario by limiting the GRAC_USER field as below.

    In object GRAC_FFOWN I have kept the following to achieve this:

    ACTVT: 01, 02, 03 , 06

    GRAC_OWN_T: FFID

    GRAC_SYSID: *

    GRAC_USER: <User ID of the Firefighter Owner over here>

    This above setup limits the <Owner User> to work with the FF IDs assigned to him only.

    I Will have to now design as many roles as Owners 😢

    Colleen, Antti: I have had found an similar suggestion at the SAP Idea Place proposing to have this perhaps as an configuration parameter , and was wondering if you might have already added your vote in there. Here is the link, would be great if you can drop your vote and SAP considers this rationale.


    Regards,

    Akshay

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Mar 06, 2014 at 02:57 AM

    Hi Akshay

    Nice efforts here on investigation. I realise you have looked at documents I've mentioned below but thought I'd ask anyway....

    Looking at the note " 1663949 - EAM: Authorization Fixes for Central Owners and Reason Codes"

    it mentions that statement in the code and passes owner, etc

    Are you able to try debugging "CALL METHOD cl_grac_auth_engine=>authority_check"

    Possibly it's not calling the authority check to pick up in ST01 tracing. When you ran ST01 did you look at SQL checks as well (possibly switch to ST05).

    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)

    Regards

    Colleen

    Add a comment
    10|10000 characters needed characters exceeded

    • Hi Colleen,

      I raised an OSS on this to get the confirmation, if this is designed this way.

      Guess what, they pointed me to read the comments and understand the authorization concepts from this.

      I had to revert back to them with much controlled fury. The comments don't speak an iota of the original issue.

      I start to feel that it is a bug and should be designed in much restricted way its expected to work.

      Meanwhile I also, tried to restrict GRAC_USER to observer its behavior. It is still allowing owner to control other FF IDs.

      I think the required control is currently missing at Master Data level as you had suggested.

      Thanks though, for agreeing 😳

      Regards,

      Akshay

  • author's profile photo Former Member
    Former Member
    Posted on Jun 19, 2015 at 02:04 AM

    Hello Akshay and Colleen,

    While researching on the subject of "Firefighter Owner being able to assign ANY FF ID to FF User" I came across this discussion and was wondering if you guys were able to find a solution or if SAP was able to provide any solution with regards to this.

    We are using GRC 10.1 and I did come across a couple of notes (1663949 - Cannot be implemented in our system, 1730649 - does not provide any solution) concerning this issue but none of them were helpful in addressing the issue.

    Request you to share your wisdom and thoughts.

    Thanks, Janantik.

    Add a comment
    10|10000 characters needed characters exceeded

    • Janantik,

      I never really got any further development on this issue. As you can see my proposed solution i.e. Controlling the way owner can only assign the IDs owned using the GRAC_FFOWN Object, but also then each owner would have a separate role. That's all the latest i have on my tabs.

      Its been quite a while, actually over an year since that GRC Implementation I did and moved to other areas, but you guys post back if you find anything substantial as an real solution. That would be really nice.

      Have a great day,

      -Akshay

  • author's profile photo Former Member
    Former Member
    Posted on Apr 26, 2016 at 07:02 AM

    Hi All,

    I have implemeted what Krysta suggested regarding changing the user ID to "Dummy" in auth Object GRAC_FFOWN and it worked 😊 I'm very happy with that.

    But one more note:

    GRAC_FFOWN exist in GRAC_SUPER_USER_MGMT_ADMIN and not GRAC_SUPER_USER_OWNER in grc 10.1

    Thank you

    Suliman

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Jul 22, 2016 at 09:49 PM

    Hi Akshay,

    You've probably already created all the roles, but if you leave the value blank for GRAC_USER you will be able to use the same role for all the fire fighter owners.

    Hope this helps.

    Rick

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.