Prompt for Authorization Object

[former_member343226]

Dear Experts,

I would like to have control on certain authorization objects which are common among the roles while creating them.

Is it possible that while maintaining or creating a role, if by mistake the administrator does not block the object OR add an entry which we do not authorize, the system should alert the administrator as a popup or alert message?

I am aware about the report "RSUSR008_009_NEW" for maintaing critical authorizations, however, running a report and giving a prompt are two different things.

Any possibility of an alert?

Thanks and Regards,

[Colleen]

Hi J K

by mistake the administrator does not block the object OR add an entry which we do not authorize

Would it be better to trust your administrators to know how to do their jobs and if necessary, include a validation process as a pre-requisite before releasing your transport? Part of this process could include running critical auth check (or if you have GRC SoD check) over the role to identify issues.

This functionality does not exist as Standard in PFCG. But if you were to develop such a thing what happens if you legitimately need to include the authorisation in the role?

If these authorisations are not required in your design, you could reduce this issue partly by cleaning up your SU24 proposals. By removing the proposal, the administrator would have to deliberately add the object to the role.

Do you have specific examples of such authorisations?

Regards

Colleen

[former_member343226]

Collen,

thank you for your detailed response. I was aware of the fact that such functionality does not exist and wanted to identify the closest available solution. I believe, the mentioned report and su24 are the only ways to cater this issue. it can be a problem during audit if we dont take corrective measures immediately.

Wonder why SAP prompts warning and errors messages doing a business/financial transaction and not security. just a point i was wondering upon which triggered the question.

Thanks.

Regards,

[former_member343226]

Though we are facing an issue, if you can suggest:

We created a display only role and adjusted each object with a display value which was a tedious task as you can imagine. However, "very frequently" there are continuous additions of one or two tcodes. Once we add that, the authorizaiton list contains new objects to be edited with display authorization.

Now if we set the proposals in su24, it will be applicable for other new roles as well for which we DO want the proposals to exist. But in the same manner we want to avoid it for this case (i.e. display only role).

We noted that every time we add a t-code, the authorization object added is marked as "new" in the list. we jsut disable those and generate it. however we have to go through "almost every object" in our case.

How can we avoid the "new authorizaiton objects" to be added to this display role. Keeping in mind we dont want this to impact the creation of new roles as we want the proposals to exist. Or if you can advice otherwise.

Thanks.

[Colleen]

Hi J K

I take the following approach with SU24:

1. Complete Proposal - completely maintain an authorisation proposal when that values applies for any situation in PFCG role build. E.g. transaction FB03 for object F_BKPF_BUK has fields ACTVT and BUKRS. You can allow the value as ACTVT = 03 and BURKS = $BUKRS (org value) or each scenario
2. Partial Proposal - only maintain some of the fields where it will be consistent. E.g transaction OB52 for posting periods and S_TABU_DIS with field ACTVT and DIBERCLS. You leave ACTVT blank as sometimes you want change whilst DIBERCLS for auth group is static so you can enter a value there
3. Empty Proposal - leave the proposal values completely blank as the requirement will depend on the scenario. E.g transaction SM30 you might leave S_TABU_DIS empty as it will depend on the role for both fields.

If you take this approach, you minimise the need for deactivating object, copying/changing and manual objects in PFCG. You maximise role authorisation under status of Standard or Maintained.

Now if we set the proposals in su24, it will be applicable for other new roles as well for which we DO want the proposals to exist.

Yes if you change SU24 you should clean up all impacted roles but before you build roles you should review

At the end of the day your need to have competent security administrators who know what a display activity is and have attention to detail/meticulous enough to build the role with appropriate restrictions (i.e. do not put change access in a display role).

How can we avoid the "new authorizaiton objects" to be added to this display role.

To avoid this you are trying to avoid using SU24 integration. If you are tying to build a SAP display all role then you might as well copy SAP_ALL and go through and deactivate/remove any display access from the role. In this case you would not use the role menu.

Not all solutions are technical. It's why you need to have a clearly defined process that is adhered to.

My trick of display roles - I got the AGR_1251 role and look at the entire contents of the role and scan this list of objects and what's in the role. However, I do this as I know the objects relatively well and can identify the specific objects that are change/display  but do not use ACTVT field (e.g. PLOG/P_ORGIN/P_PERNR)

Wonder why SAP prompts warning and errors messages doing a business/financial transaction and not security. 

Exactly what would you want the system to prompt? How would SAP know what a display role is?

We noted that every time we add a t-code, the authorization object added is marked as "new" in the list. we jsut disable those and generate it

If you take this approach you cannot guarantee the transaction code will work. The user may need the underlying values and that is why SU24 has them marked as proposal.

My summary - defined your process to include a quality check after building a role and hire security administrators who know more than how to tick and click buttons in PFCG (i.e. they understand security objects and why some are sensitive).

Regards

Colleen

[former_member343226]

Thats helpful however, still does not map our requirements the way we want. We have module based display roles for consultants and operational roles for our employees. Setting proposals only for having ease on consultants roles is not the solution. Su24 currently doesn't seem to work out for us but maybe in future.

Giving SAP_ALL profile to a role and giving it display is not what we want. Its a big security lapse as other modules will have access to your areas' confidential data which we would not like to happen.

But yes we are thankful to your descriptive and timely responses.

[Former Member]

Hi,

Various flavours of GRC all the way from Virsa days through to 10.1 have this sort of functionality - known as Risk Terminator.

To use it in it's preventative mode is a complete pain and every customer I know who has used it to prevent roles being generated with risks has switched off the preventative part ASAP.

If you can find an enhancement point in the code of PFCG then you can put in some custom code to do what you want.  I would imaging a check before role save or profile generation would do what you are looking for.

It may be a sledgehammer to crack a walnut but at risk of promoting a fellow SDNer's company there may be something here that suits: www.xiting.ch/en

Colleen's advice on SU24 is spot on and is (IMO) the right way to do it and will hugely reduce the occurance of "New" auths.

Good luck.

[Former Member]

Hi Alex,

Thanks for the reference, but I need to correct it:

We (Xiting) provide the ability to enrich SU24 so that decisions are transferred to the menu of the role as much as possible, and the ability to perform simulations of authorizations in role(s) to verify whether they would have failed without them actually having to fail. This transfers irritant test system activities to passive simulations in production and authorization sensitive code scans in development.

But we do not offer a GRC Risk Terminator alternative which warns admins in PFCG before they add access to a role. That is the domain of GRC.

While on the topic: What I would like to have however though is a webservice from GRC to integrate into the trace environment though. That way GRC could be used to perform SOD type checks at the time of trouble-shooting and not when making the changes. Unfortunately GRC does not provide this..  😞

Cheers,

Julius

[Colleen]

Hi Julius

"SOD type checks at time of trouble-shooting" - wouldn't that be risk simulation In GRC allowing you to check for introduced risks before changing the role?

regards

Colleen

[Former Member]

Thanks for the correction!  I was getting confused with Blacklists and grey lists for role generation.

[Former Member]

What our application does is that it does analysis of authorization relevant data as runtime and collects information about it. So there is no change to a role yet -> with terminator you must have the role and commit the change before you can simulate. I want to sent it raw data from a trace or simulation, and it must return whether that runtime problem if built into a role for the user would create a problem. But there is no API for that at trouble shooting time - you first have to change the role or predict what would happen if you added a role. In my case there is no role - only "raw" data.

Hope that explains the difference.

Cheers,

Julius

[Former Member]

In our case black lists are a prevention against doing things which are unwise in transaction contexts. Basically it removes noise from the data (trace, SU53, kernel data).

Grey lists collects information about solutions which worked so that they are suggested for other troubleshooting of the same problem. Basically it adds a self-learning effect to using the application and collects candidates for the "white lists". Marketing folks and Gary Larson use the term "artificial intelligence" for it, because it is actually quite simple.

But this has nothing to do with intentional maintenance in PFCG. There were exits for that in the past, but they are obsolete now as of 7.31.

Cheers,

Julius

[former_member343226]

@ Colleen and Julius,

I did another workaround for "eliminating" the "new" authorizaiton objects.

As we're working on an already created role (Eg; FI DISPALY Role) and adding tcodes introduce tons of new objects.

Workaround for this specific scenario:-

Now if any request for adding related tcode that comes in I goto SU24 and check which objects are checked for that specific tcode by SAP. These are minimal in standard settings (normally 2 or 3). I add the requested tcode in S_TCODE for that Role and verify other objects which are 99% already existing with display authorization done before. Therefore, my efforts are intestively reduced by just adding it in S_TCODE only and mainting the display authorization without going into the hassle of maintaining new objects.

Just thought of sharing it with the team!

Thanks for your informative and valuable inputs in the thread.

Regards,

[Former Member]

Downside is that you cannot leverage accurate proposals and where-used-list-references which SU24 brings. Additionally the user cannot see the tcode in their menu. I also dont understand how that is meant to warn you about critical objects pulled into a role, unless you know all objects and can "eyeball" them in SU24 and compare them in your mind to what you remember as having been in the role.

To be honest, you are breaking your roles.

Cheers,

Julius

[OttoGold]

Hello.

Because there is no such thing as a GRC simulation and no alternative functionality in the standard NW basis either, I got an idea for a "simplified impact analysis". Of course it is not a part of the standard PFCG and I am not using it in PFCG (so there is no improvement to using 008_009 in a separate window next to PFCG as mentioned earlier).

You only need to know a couple of things that you can put into such an IA:

a) how many objects will be pulled from SU24 into the role that are not in the role yet?

b) how many new values for existing objects will be pulled from SU24?

c) are any of the new things violating the role "status" or "mission" (non display proposals pulled into a display role)

d) are these objects or values on the company's blacklist?

...

x) is any of the SU24 proposals introducing a range etc.

There is a solution for every problem. Unfortunately the solution does not exist in the standard and one ad-hoc custom report will not save you. I have a suite of products where this thing works nicely with the rest. It can probably help you as a standalone report too, but you will face many organizational problems that you can't solve with custom reports anyway...

Cheers Otto