EAM ID based or Role based? Why settle for just one?

[leos]

G'Day All,

I've raised a question in the following blog, however I would like to open it up to other people as well so they might get something out of it and in the process might share their own thoughts on the matter at hand.

So this is where I am at this point:

From what I can gather so far, my understanding of EAM ID/ROLE based is as follows:

- Id Based: Logs in using own U.ID and through GRAC_SPM accesess FFID from the GRC Server and logs into the system assigned to them (ECC, SRM, CRM etc)

• Only one user at a time can use a FFID.
• Firefighter need not exist in every system assigned to them due to central logon however they need to exist in the GRC system
• Knows exactly when FFID is being used as he/she has to login so has a psychological effect (good thing)
• Better tracking of FF tasks - Specific log reports with Reason Codes. Bonus point from Auditors!
• Two Log ins so potential to commit fraud. (1 action using own UserID and 1 action using FFID)
• Could be hard to track and find out when a fraud has been committed so can be a problem with auditors.

      ID Based -> GRAC_SPM : TCode for Centralised FFighting -> You will see FFIDs assigned to you

      ID Based -> /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> You can see  the FFIDs assigned to you

- Role Based: Logs into the remote system only using U.ID, so everything gets logged against that one ID. 

• Multiple users can use the FFROLE at once.
• Firefighter has to exist in every system assigned to them - so multiple logons.
• Hard to differentiate between FF tasks and normal tasks as no login required  So easy to slip up
• Time consuming to track FF tasks - No Specific log reports. No Reason Codes

     R.Based -> GRAC_SPM : TCode for Centralised FFighting -> You will see FFROLEs

     R.Based -> /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> Not applicable so wont work

So based on this there are pros and cons in both however according to SAP only one can be used. To me personally,  it makes more sense to get the best of both the worlds right? So here is my question why can’t we just use both?

    . Really critical tasks -> FFID

    . Normal EAM tasks -> FFRole

Alessandaro from the original post pointed this out:

"Per design it isn't possible to achieve both types of firefighting at the same time. It's a system limitation and hence to configurable."

Well this is what I can't seem to get my head around. For a FFID, there is a logon session so it has to be enabled and as far as I can tell there is no way around it.

However for FFRole, there isn't such limitations/restrictions like starting a separate session. FFRole is just assigned to an end user for him/her to perform those tasks using their own user ID.

• So in what way is it different from any of their other tasks/roles, other than the fact that they've got an Owner/Controller assigned to the FFRole? and
• What is stopping us from using it when ID based is the default?

If I were to do the following does it mean I can use both ?

    . Config Parameter: 4000 = 1 (GRC System) -> ID Based

    . Config Parameter: 4000 = 2 (Plug-In)  - > Role Based

Please excuse me if my logic is a bit silly, Role Based firefighting is only done on Plug-in systems so the following should work just fine:

   . Config Parameter: 4000 = 2 (Plug-In)  - > Role Based

However for ID based, it is a Central Logon, so the following is a must:

    . Config Parameter: 4000 = 1 (GRC System) -> ID Based

Which means both ID/Role based can be used at the same time, which seems to be working just fine on my system. Either way I leave it you experts and I hope you will shed some light on it.

Cheers

Leo..

[Former Member]

Hi Leo,

Well, you do understand the concepts behind ID-FFighting and Role-FFighting pretty good.

But as far as you have concerns regarding usage of both of these at the same time in the same environment, I am sure that this is not possible as of now.

We (I) always prefer to opt ID-FFighting over Role-FFighting as there are some loopholes with role based and clearly mentioned by you like, logs et al.

Not sure, if this can be put up as an idea with SAP, unless they do overcome with the limitations and restrictions with role based. But it could be worth trying out for it.

Regards,

Ameet

[leos]

Hi Ameet,

Thank you for your response. My query is not in regards to which one is a better option or needs to be used. End of the day its up to the Company/Organization what they think is best for their needs or what they think is right for them.

In regards to using both of them at the same time, well that is what I am trying to find out. Everyone keeps saying that is not possible or keep referencing SAP that it has to be either this or that, but I'm yet find out why not and what's stopping us?

Regards,

Leo..

[Former Member]

Leo,

What is stopping us is the development time required to make that happen. It doesn't work that way today to allow both; therefore the options are for the customer to do some heavy customization to enable such flexibility, if that could even be done, or to get enough customers to agree that they want such functionality that SAP will invest their own development resources in modifying the solution. I have been involved in a number of SAP Influence initiatives; while SAP wants their solutions to meet customer needs, they generally, and in my view quite reasonably, require to get support from a minimum number of customers before they decide to invest in such modifications. You can submit it in Idea Place and see how many customers agree that they would find this useful.

Regards,

Gretchen

[leos]

Gretchen,

Thank you for thoughts on this.

Looks like I'm failing to articulate my thoughts properly as the conversation seems to be going in a different direction from what I am after. I'll try once more!

My query/issue is not in regards to if/what SAP needs to do about this or why there isn't more support from Companies/Organizations and not even, which one is a better option.

My query is what is stopping us(as in the end users ) from using both ID/Role based at the same time?

Now before people start referencing SAP documentation and about parameter 4000, humour me with the following scenario please. Again I would like to reiterate that I am still in the learning phase so my logic might be all wrong/misguided, so please do point out to me where I am going wrong in my thought process as I sincerely would like to know why I am the odd one out in regards to this.

Scenario

I've created the following:

• FFID
• FFROLE

Assigned them to, two end users

• John Doe
• Jane Doe

I set the Configuration Parameters as follows: 

• IMG-> GRC-> AC-> Maintain Configuration Settings -> 4000:1 - ID Based
• IMG-> GRC (Plug-in)-> AC-> Maintain Plug-In Configuration Settings-> 4000:2 - Role Based

User1

• John Doe logs into his regular backend system (ECCPROD001)-> executes GRAC_SPM-> Enters the GRC system (GRCPROD001)-> Because the parameter is set to ID based in the GRC Box, so he will be able to see the FFID assigned to him-> and will be presented with the logon screen-> Logs in -> Enters the assigned system (lets say CRMPROD001)
  • At this point the firefighting session is under progress

User2

• Jane Doe logs into her regular backend system (ECCPROD001) -> (can execute GRAC_SPM to check which FF Role has been assigned to her but she can see that in her regular menu, so there is no point) -> Executes the transactions assigned in FFROLE
  • This is done at the same time while FFID session is in progress

So all I want to know is if this scenario is possible? if the answer is No, then why not?

I physically carried out this scenario in my system and I had no problems(unless I am really missing the plot here), which brings me back to my original question: Why settle for just one?

Again to reiterate I am not getting into the efficacy or merits of this or even if one should use this. Just want to know if it is possible/feasible or not.

So there you have it. That's the whole enchilada(as they say there in Texas). I tried to word my thoughts as concisely as I can, if there are still any clarifications, more information you or anyone else reading this would like, please do let me know.

Regards,

Leo..

[kevin_tucholke1]

Leo:

This is NOT possible.  First, I think you may be misguided as to how Role Based FF works or is executed.

In Role based firefight, a security role is designated as a FF Role.  That role is subsequently assigned to an end user directly on their own User ID.  When a transaction is executed from that role, it is then deemed Firefight usage.  The user does NOT execute the transaction for the FF Logon Pad and does not select a ROLE for firefight; it is just automatically considered Firefighting.

So in effect, the Firefight User does not even know when they are actually firefighting.

It is also important to note, that in Role based Firefight, if a transaction is in Firefight and the user has that transaction in a different role as well, the transaction will ALWAYS be considered firefight.

The way that this is intended to be used is to make everyone firefight in the same fashion.  Either you make a conscious decision to execute firefight (ID Based Firefight) OR you use role based firefight and the user just executes the transaction from their own user ID and that also means that there is no process to understand why a firefighter actually did the firefight activity.  There are also other technical considerations as Gretchen was referencing above as well  (for example, What if a FFID has a FFROLE, so at that point, is the FFID having to do a different firefight session??)  The coordination and maintenance in using both would be horrendous, even if this was possible.

Now, you can use Role based firefight truly only decentralized as it is a role directly on the user.  ID Based firefight can either be Centralized (Firefight Session executed from the GRC system) or Decentralized (Firefight Session executed in the target system).

I hope that this helps here.

Kevin Tucholke

Principal Consultant

SAP America

[leos]

Kevin,

Thank you for your feedback and suggestions.

I am aware of how Role based firefighting works and I have already mentioned most of the points raised by you in this blog.

"In Role based firefight, a security role is designated as a FF Role.  That role is subsequently assigned to an end user directly on their own User ID.  When a transaction is executed from that role, it is then deemed Firefight usage.  The user does NOT execute the transaction for the FF Logon Pad and does not select a ROLE for firefight; it is just automatically considered Firefighting."

• Precisely my point. This will in no way affect the FFID session as FFROLE is independent of  FFID session.

"(for example, What if a FFID has a FFROLE, so at that point, is the FFID having to do a different firefight session??)"

• I don't see why anyone would want to do this. It seems redundant!

"Now, you can use Role based firefight truly only decentralized as it is a role directly on the user.  ID Based firefight can either be Centralized (Firefight Session executed from the GRC system) or Decentralized (Firefight Session executed in the target system)."

• I am aware of this and considering both Centralized and Decentralized can be enabled at the same time now so I don't see why we cannot have both Firefighting sessions at the same time

* Reminds me that I forgot to mention in my scenario earlier, that I have enabled both Centralized and Decentralized in my system when testing it.

Regards

Leo..

[kevin_tucholke1]

Leo:

Sorry, I had seen some comments that I made me think that you did not totally understand the role based scenario.  You mentioned about looking at the Logon Pad with Role based, and that is not possible with that.  No offence meant.

I also want to mention that from a Centralized vs Decentralized scenario, this is only relevant to ID Based FF.  and truly the choice is Centralized ONLY or Centralized and Decentralized and the latter is really dependent on the security you allow to your Firefight users.

Again at the end of the day, the situation to have both is not possible at this time based upon the intent of the program and the way it is currently configured.  Having done this from both a customer and consulting standpoint, I have never heard this request before, and truly I feel that this would be horrendous to try to manage.  Just my opinion.

Thanks,

Kevin Tucholke

[leos]

Thanks Kevin. I can see where you coming from.

"You mentioned about looking at the Logon Pad with Role based, and that is not possible with that.  No offence meant."

• None taken (I strongly believe the best way to learn is to ask questions even though if they sound silly) I am aware that this is only possible in Role based(look at the logon pad) and that we cannot look at the logon Pad if ID based is enabled, however as I mentioned it wouldn't make any difference considering the Firefighter will not be needing the logon pad in Role based!

"I also want to mention that from a Centralized vs Decentralized scenario, this is only relevant to ID Based FF.  and truly the choice is Centralized ONLY or Centralized and Decentralized and the latter is really dependent on the security you allow to your Firefight users."

• Roger that! I am aware of that but thank you for confirming it.

"Having done this from both a customer and consulting standpoint, I have never heard this request before, and truly I feel that this would be horrendous to try to manage.  Just my opinion."

• It might be true and at this point my focus is not so much on the efficacy of this scenario but as to the functionality of the module. Considering Role based FF looks like a better option if some how the risk involved (No designated log reports, tracking etc) can be countered, It would make sense to to give regular FF tasks as Role based and really critical tasks as ID based (Given its better security measures).

Once again thank you for your valuable input on this matter Kevin.Much appreciate it.

* I know there is a fine line between Stubbornness and Persistence, so I'll make sure I don't cross over.

Regards,

Leo..

[chandani_kaur]

Hello Leo,

Even if from the plugin side you are able to do FFRole logon but as in GRC box application type is YES so only FFID logon done via centralize or decentralize launchpad will be considered. The logs will be collected for FFID logon only. Also this will make application not work properly for following scenario:

(1)  As when a user logon at that time user exit is called to check if FFID is trying to logon. At that time if application type at plugin is set to  2 then no checks will be done and FFID can diretcly logon into the system..

(2) When using decentralize firefighting, some scenarios start failing as always application type is checked before.

Thanks & Regards,
Chandani Kaur

[leos]

Hello Chandani,

Thank You. Finally I'm making some headway. This is what I was after all along. The functionality of the module. At the moment I just want to know if there is a possibility to have both sessions at the same time and if so then what would be the potential problems. Not the logistics of enabling this scenario or if its going to be a nightmare to have both at once. I'll cross that bridge when I get to it.

"Even if from the plugin side you are able to do FFRole logon but as in GRC box application type is YES so only FFID logon done via centralize or decentralize launchpad will be considered. The logs will be collected for FFID logon only."

• FFRole does not have a designated log report like FFID, so as long as the FFID logs reports are collected then FFRole reports can be checked out using other reports like SUIM etc, which is what they would do anyway right?

"As when a user logon at that time user exit is called to check if FFID is trying to logon. At that time if application type at plugin is set to 2 then no checks will be done and FFID can diretcly logon into the system."

• I based my assumptions on the fact that it is working on my system without any errors. Having said that, I still haven't covered user exits so I need to do some reading. From what you mentioned, it could be a factor.

"When using decentralize firefighting, some scenarios start failing as always application type is checked before."

• It would make sense if we were to just use Decentralized firefighting however now we have the option of using both at once, so I don't think this would be a problem. Of course if the end user wants only Decentralized firefighting enabled then yes, I agree that it would be problem.

It would be nice to know if someone can carry this out in their sandbox to check it out. Either way I think I'm done with this topic and its time to move on I suppose.

Regards,

Leo..

[Former Member]

Two things:
1. Role based Firefighter usage was introduced as a backup plan for ID based, and to align with the functionality of older 5.3 and 4.0 versions - so ideally only one should be used.
2. Since the application does not allow 4000 param to be set multiple values, hence only can be used at one time.

Any concerns, please mark your idea over SAP Idea Place with more details should you expect your scenario to be acknowledged further.

[leos]

Thanks for your response Manik. I believe there are two places where you need to set the 4000 Parameter:

1. IMG-> GRC-> AC-> Maintain Configuration Settings -> 4000:1 - ID Based
   • This is for the GRC System where the FF needs to login centrally
2. IMG-> GRC (Plug-in)-> AC-> Maintain Plug-In Configuration Settings-> 4000:2 - Role Based
   • This only applies to the plug-in system so Role Based will/should work just fine
     • However considering we enabled ID based in GRC System Config(above), so ID based should work as well. That's in theory anyway and unless I missed something or getting confused, it seems to work on my system.

In regards to the SAP Idea Place, I don't see if this is an Idea, considering nothing needs to be changed from what I can tell. Unlike FFID, there is no designated Role that needs to be assigned for Role Based Firefighting. As long as we tick the box to enable a Role for Firefighting in BRM and map that role to Owners and Controllers, I don't think there is anything else that needs to be done. Well that's what I think anyway at this stage but I would like to corrected if I am wrong or if there is more to it.

Regards

Leo..