Field values for Authorization object assignment

[Former Member]

Dear Experts,

I am trying to understand how SAP behaves when there are conflicting field values are provided when accessing a T.Code.

For instance, i am trying to evaluate users having access to T.Code VA01 (Create Sales order).

As i understand, BOTH the below authorization objects are required to access VA01.

a) V_VBAK_AAT - Sales Document: Authorization for Sales Document Types

b) V_VBAK_VKO - Sales Document: Authorization for Sales Areas

I have a scenario, where the first aurhorization object (V_VBAK_AAT) has been given ACTVT value of 01 (Create), but the second authorization object V_VBAK_VKO has been given ACTVT value of 03 (Display)

In the above scenario, would be user be able to create sales order through VA01 ? 

My understanding is, since the user has "Create" access to Sales document type, but only "Display" access to sales area, the user would NOT be able to create a sales order.

Kindly advise.

Thanks !

Uday

[Colleen]

why don't you create a test user in non production and test your theory

[Former Member]

he he he.. I wish i can.. But i don't have access to non-prod instance

[Former Member]

You should get yourself a sandbox then to make tests in, as this is just a matter of testing, or reading  the code. Additionally you should verify the answers you get in the internet...  🙂

Sometimes the combination of multiple objects is needed, sometimes 1 stronger object can override a weaker one and in most cases config (SU24) can control the behaviour.

Where you are correct in this case is that the role has a conflict as both are required to complete the document. This means that another (probably bolt-on-role) is needed for the sales area authorization. This means you are dealing with a very unfortunate design of the roles (enabler concept) and will have to evaluate the access at a user level and not a role level as the role appears to be disfunctional.

The concept in such a case is not disfunctional, it is just rubbish. Often the cause of it is that roles must be free of being functionally capable of doing anything critical (or anything at all) so that the role concept "looks" fine, but trying to put it together at user assignment level is a nightmare.

You should not break the role concept and make it unmanageable just so that the roles look "nice" from an SOD analysis perspective, when in actual fact it is a mess and the buck is just being passed on to the assignments.

That is what you should right into your audit report as a bigger risk than the ability to create customer orders combined with anything else...

Cheers,

Julius

[Jelena_Perfiljeva]

Where you are correct in this case is that the role has a conflict as both are required to complete the document. This means that another (probably bolt-on-role) is needed for the sales area authorization. This means you are dealing with a very unfortunate design of the roles (enabler concept) and will have to evaluate the access at a user level and not a role level as the role appears to be disfunctional.

To be fair, in this particular case it's a completely normal role configuration when there is more than one Sales Area available. A user might have access only to one Sales Area but not the other.

Anyways, since OP's question has been answered already perhaps they could kindly close the discussion ( see this blog: http://scn.sap.com/community/support/blog/2013/04/03/how-to-close-a-discussion-and-why )

[Former Member]

What I meant by "conflict" is that the user and the transaction code needs both objects: the document type and activity, and, the sales area and activity fields.

The roles contains the document type activity (01) to create but can only display (03) in the sales area it can create in. That is contradictory and mean that if the user can work at all, then there is some other "bold on" enabler role for the sales area and if the user is not meant to post sales orders then what is the authorization for the document type creation doing in the role?

-> kaput.. 

Cheers,

Julius

[Former Member]

Thanks this helps

[Colleen]

Hi Julius

This means you are dealing with a very unfortunate design of the roles (enabler concept) ....

Do you believe the Enable concept is complete "rubbish" or has some valid scenarios?

I have seen it used effectively for material type purchasing of sensitive materials (e.g. explosives/chemicals/etc). Only specific users were allowed to make this purchasing decisions. All other users had the full access. The "enabler role" only contained the authorisation for that material type and was an extension of the user's purchasing access.

This was exception based and not to achieve SoD. I doubt that applied in this case.

Regards

Colleen

[Former Member]

The risk with the enabler approach is more the folks who think it is scalable and less the use-case as exceptions.

The acid test for me is that it must be isolatable to only one or two auth objects without org.levels in them and the assignment to users must follow a logic which is related to their person. Basically you need something like derivation, but there is no derivation rule for you and the field does not support org.levels and you cannot maintain it in SU24.

In addition to your example, valid use-case is also granular controlling module access for cost center owners (at center or hierarchy node or profit center level) or release codes in purchasing. Things where you literally need to know who slept with whom to work out the role design..  🙂

To split VA01 into various enabler roles when everything you need fits into SU24 and org.levels is however a fail. There is no valid reason for it which I can imagine.

Cheers,

Julius

[Jelena_Perfiljeva]

Julius von dem Bussche wrote:

if the user is not meant to post sales orders then what is the authorization for the document type creation doing in the role?

In this scenario the user is probably meant to create the sales orders, just in a different sales area. For example, we have two Sales Orgs in the same system (different companies). There are the sales reps who only have access to create regular orders (like OR type) only in their Sales Org (say the SOrg codes are 1000 and 2000). There are AR folks who can also create credits/debits (CR/DR), also in their SOrg only. And there are some FI people who have Create access in their SOrg but also Display access (for analysis or some inter-company inquiries) to all the documents for all SOrgs.

So for the last group you'll see these authorizations:

1) V_VBAK_AAT = CR / DR, activity 01/02

2) V_VBAK_AAT = OR, activity 03

3) V_VBAK_VKO = 1000 activity 01/02

4) V_VBAK_VKO = 2000 activity 03

Naturally, if they go to VA01 then they can only do something with the combination of (1) and (3). But in VA03 any combination of 1-2 and 3-4 would allow them to view all the documents.

Of course, to give someone only the access 1 and 4 would be just completely meaningless, but I don't believe the OP looked at all the authorizations for the user, just at one particular scenario.

[Former Member]

Besides display of sales orders not being particularly critical in any way, the user would be limited to the sales doc type OR and sales org 2000.

Where a "cross pollination" of objects would happen is create authorizations for CR + DR in 1000 and create authorizations for OR in 2000 and in both cases VA01 is used -> the user would be able to create OR in 1000 as well. But there is no number of roles which would help to get around that problem as it is at authorization instance level.

In hindsight perhaps SAP should have considered making 1 object out of it with 3 fields, instead of 2 objects each with 2 fields.

This is however a rather unlikely scenario to happen to one person though - however I have heard of consultants recommending that a completely foreign business unit (eg. Japan) perform some tasks for another (eg. Brazil) just so that SOD issues are reduced...

Cheers,

Julius

[Jelena_Perfiljeva]

Julius von dem Bussche wrote:

Where a "cross pollination" of objects would happen is create authorizations for CR + DR in 1000 and create authorizations for OR in 2000 and in both cases VA01 is used -> the user would be able to create OR in 1000 as well. 

OK, I see what you mean now. That would be a very strange setup though since these document types usually correspond to different roles in real life.

I do agree that it would've made more sense to have just one object here. I don't think these objects are even used anywhere separately. Don't really see in what business context the document type check would be sufficient...

[Former Member]

Jelena Perfiljeva wrote:


That would be a very strange setup though since these document types usually correspond to different roles in real life. 

Exactly that. The 2 objects with their activities and even document types and peripheral authorization objects which are needed can be proposed together from SU24 and make building roles for it literally idiot-proof as long as the tcode is in the menu and the status is standard.

If you check the SAP proposals then that is also always the case (proposed together, or set to "no check" together).

Hence my conclusion that someone tried to implement an enabler concept for org.levels here and, as it always does, a mess resulted beyond the imaginable boundaries of the original PowerPoint slide which was the designer of it...  🙂

That is from an audit perspective also more important and more risk for the concept than simply using SUIM to look at results of who can and who cannot.

Cheers,

Julius

[michael_kozlowski]

In general authorizations are additive. So user would be able to create sales order through VA01. Set a breakpoint in Include MV45AF0B_BERECHTIGUNG_PRUEFEN to verify.

[Jelena_Perfiljeva]

Does authorization trace in ST01 not explain this?

These are not "conflicting" values, these are different authorization levels. One might have access to a document type but only in certain sales area. Authorization checks are performed in sequence, all checks need to pass in order to proceed.

[Former Member]

Former Member thanks for the reply..  I too think these are not conflicts, but as @julius mentioned, these are not ideal authorization combination to have.