GRC EAM Authorizations: Few Anomalies in Standard Roles

[Akshay_G]

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

[Akshay_G · Accepted solution]

Hello All,

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

[Colleen · Accepted solution]

Hi Akshay

I've added my vote. It is a pity it was raised in Ideas Place back in February 2013 and has had no progress

Rather than build the roles you may want to look at Workflow for the owners. Allow them display access in the FF configuration area but do a routing rule to auto approve requests that they raise when they are the owner. This will allow them to capture reason for the FF as well. You could choose to only allow them only access to the FF Request type and prevent end users from requesting it. At least this way you won't need to constantly maintain roles all the time - that's unsustainable.

Hopefully others in SCN will see this and go add their vote - notice there are no votes rejecting the idea!

Regards

Colleen

[Akshay_G · Accepted solution]

Hi Colleen,

Yes that's kind of true, that its hasn't been manifested yet.

Lets Hope SAP pays some heed to it, and more votes are brought in for the idea!

I haven't had really thought about setting up the workflows. But will give it a try to convince my peers to consider and will do a POC myself. I believe, you wrote an article just a day ago on MSMP workflows, Voila Co-Incidence! I will check it out and will see how can I take it from there. Haven't ever done MSMP WF before, just read about it in SAP BPX and was overwhelmed by the content and routes/stages

On a candid note, How much effort would be required to bring MSMP workflows in place? Just simple routes not much of a complicated ones?

Regards,

Akshay

[Colleen · Accepted solution]

if you still have incident/message open in marketplace are you able to link in the Ideas and raise this?

if they couldn't control via authorisations it's a pity the GRC_USER field for OWNER doesn't have a value like _USER_ so it limits to own account only. This would negate the need to build roles

For your MSMP note - depends if you are using Access Request Approval for other purposes. You can have a look at a few examples on Initiator Rules/MSMP that have been in the community - i.e. build an initiator rule that checks straight up if Owner = Requester. Based on that you can return your result to go down a path that doesn't have stages (therefore auto approval) if the Owner is the Requester or send it to the owner approval path if they do not match. If you have Access Request for other system access you will need to include request type in the initiator rule as well

Yep my article is (noticed it was a common topic and thought the overview/concept was lacking in the community and most questions were around the steps)

There are also a few good documents for Initiator Rules/MSMP/BRFPlus such as:

by Amanjit Singh Bindra

See how you go with that material and search SCN for the rest

If sticking to simply routes and not using access request for other purposes then effort is not too much. You could set it up in a day (dev only) and then work through testing effort. It took me a few days first time but that' because there was no documentation other than GRC300 course guide. So much more activity on SCN and help.  Your challenge is to work out you design (process flow/decision points) and consider if growth to your system. I.e. what happens if you decide to include workflow for other request types.

Regards

Colleen

[Akshay_G · Accepted solution]

Hi Colleen,

Thanks for the heads up & resources regarding MSMP & workflow designs.

I will bug you in case of further assistance for that.

The support message is closed now, and moreover support team isn't entertaining any feedback & improvement areas in the OSS, and rather insisting to do the same on idea place (So much so that the Idea seems to be untouched yet).

Regards,

Akshay

[Colleen · Accepted solution]

I wonder if we need a message in SCN Support or Coffee Corner asking how long does it take SAP to review Ideas Place - especially when they are encouraging customers to put their ideas there

Good luck with it all

Regards

Colleen

[Former Member]

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

[Former Member]

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

[Former Member]

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.

[krysta_osborn]

Hi everybody,

I think I may have stumbled on a really hokey workaround for this. I found that if I put ANY user ID in object GRFN_FFOWNER, the owner is limited to the FF IDs they own. For example, I stuck DUMMY in there knowing that I don't have any users called DUMMY in the system, and the list was limited to only the FF IDs for that owner vs. * where the owner can sign out any FF ID.

I figured this out when I put one of the FF IDs that belongs to my test owner in the role, and the system still showed the other one. So I thought I'd try a bogus user and see what that did, and it worked!

It would be awesome if someone could also confirm this in their system. I have high hopes that it's not just wishful thinking / system gremlins over here. I really don't want to have to create a separate role for every FF owner!!!

Krysta

[krysta_osborn]

Correction - auth object is GRAC_FFOWN.

In further testing, I found that the FF owner can't delete a FF once it's set up. This auth object checks for delete access to the specific firefighter user ID you're trying to remove. BUT I think that's a small price to pay since I'm the administrator, and I set up and delete FF IDs for the owners anyway.

Krysta

[Former Member]

Hi Krysta, I have tried your trick as well. I maintained the auth. object with value " " with the same results as yours. It won't let the owner delete the assignment line item.

Janantik.

[krysta_osborn]

Thanks for your quick reply, Janantik.

I know this solution won't work for everyone, but I hope it'll at least help a few people.

Krysta

[Former Member]

Hi Krysta and everyone,

I also wanted to check if there is a way to configure the system such that deletion of Firefighter Controller assignment to Firefighter ID should not be possible if that Firefighter ID has a valid FF User assigned.

Another anomaly I have come across with the EAM functionality is as follows:

I want to configure the system such that FF Controller assignment to FF ID is mandatory. I did manage to configure that but still its not working 100%

As described in the below screen if I try to save FF ID to FF user assignment without FF Controller I get an error message saying "Select a mandatory Controller to proceed" which is fine.

But next as shown in the below snapshot I add an empy line-item for Controller ID and save it. The system saves the assignment with only a warning message. I would expect the system to not allow saving this.

Requesting you to advise if you know a solution for this.

Thanks, Janantik.

[Akshay_G]

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

[Colleen]

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

[Akshay_G]

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

[Colleen]

Hi Akshay

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.

Me neither... I taught myself very basic debug by putting a breakpoint in the code and single stepping through each line to see what happens. This was in conjunction with ST01/ST05 traces.

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?

I think we are in agreement that Owners should only be able to control their FF Ids. Unless someone else can comment, we do need SAP to advise if it's a design (albeit bad one if you had to create a heap of roles to restrict user authorisations) or bug (note required).

Therefore, Owners should be restricted by the master data whilst Administrations should be limited by Authorisations.

Are you able to test a scenario for the Owner to revoke GRAC_USER authorisation and see what they can/can't do in NWBC for FF setup?

Cheers

Colleen

[Akshay_G]

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