general authorization question

[Former Member]

Hi all,

this is a general question related to SAP's authorization concept (hope it goes into this forum). I basically understand how authorizations, authorization objects/-profiles and user master records work together. However, what I don't understand is how authorization is done when the 'thing' (trying to avoid the term 'object' here) a user may or may not do something with is

1) individually different and/or

2) changes during runtime.

Say a customer logs in and may only see the purchase orders he is creating or has already created, i.e. the 'thing' (here: purchase order) we want to restrict access to (so users have to be authorized) is dynamic data and various per user (so no groups of users or roles as such make sense).

So, is there a way to construct authorizations dynamically? Would one at all use authorization objects or create a custom authorization concept (with some table look-ups) here?

Regards,

Sebastian

[Former Member]

That's not how the SAP authorization concept is designed to work.

In general, an application performs authorisation by asking:

- Am I allowed to perform a certain activity

- On this type of object (eg. "purchase order", "thing")

- Where the object has a certain classification

That last bit is the key. We don't authorise users to perform activities on specific instances of a "thing", rather we allow users to perform activities on those "things" that have common attributes, such as belonging to a particular company code, having a certain authorisation group, etc.

If the thing is individually different, then you probably need to specify a unique authorisation group. Though this supposes the thing supports authorisation groups and is also not very friendly as authorisation groups tend to be free entry fields.

Regards,

Scott

Message was edited by: Scott Barden

[Former Member]

Hi Scott,

thanks for your prompt and clear answer. I understand that the objects (purchase orders) in the scenario I described lack the third property you listed - a common classification, i.e. some common properties that (in this particular context) make them similar.

However what would be a solution? Does this hint to a conceptional flaw as the abstraction of purchase orders - the objects authorizationwise relevant here - that has been chosen does not reveal their possible similarities (like e.g. common company)?

Or is their a decent way to authorize 'by table lookup'? Could you also explain the hint regarding the authorization groups in more detail please?

Regards,

Sebastian

[christian_wohlfahrt]

Hi Sebastian,

I guess, important question is classification of the things. Users aren't allowed to do something, there has to be a specific description (is allowed to create POs and change only 'own' ones).

As long this is clear, your problem is to define this classification in SAP (e.g. changes depend on field EKKO-ERNAM). Maybe sometimes additional tables have to be read (there might be no field ERNAM, but in change documents CDHDR-USERNAME can be found).

Surely that aren't standard checks (otherwise you would have finished your concept already).

One solution can be:

Creation of additional authorization objects (e.g. with ERNAM)

Insertion of additional authorization checks (hopefully in user-exits, otherwise modifications / own transactions)

Maintenance of many authorizations:

action ernam

01 *

02 KAMP <- for each user different - lot of work

03 TRAINEE01

03 TRAINEE02

03 BATCH

...

Hope you got the picture.

Concentrate first on defining the classification, then try to describe the maintenance work for the definition of 'what is allowes'. There will be users, which have more (but not necessarily * ) authority. If you can show, their ideas will lead to very complex (and huge) maintenance efforts - independent of any technical solution (adding some checks in PO is not so difficult), you might can get easier requirements.

Regards,

Christian

[Former Member]

Hi Christian,

I think it is getting clearer. As you and Scott also pointed out the key is the necessity of a certain classification of the objects (POs etc.) worth protecting. This means as for SAP's authorization concept certain properties of these object should imply the right to access them by certain users; it is not that these objects (their IDs) are listed explicitly as authorizations in some profile.

So what if indeed you want to protect an object that differs from all others individually (and that might even get created during runtime)? I guess one should doublecheck the concept first (as this is an odd requirement) and - if confirmed - construct your own authorization procedure as SAP's authorization concept is not suitable for this.

Regards,

Sebastian

[christian_wohlfahrt]

Hi Sebastian,

that's the point: how to identify a future key value, which has to be protected? By key number is quite stupid... (but don't mention this to your customer!).

Maybe release strategy is an option: a document (PO) is created, but won't be processed until several steps of confirmation are executed (perhaps depending on total value...).

I would go on with clarifying, if some<i>things</i> have to be protected, how <i>some</i>thing is defined - this should help to get a better requirement.

Christian

[Former Member]

Additionally, if the requirement were to allow users to only maintain their own PO's, then I wouldn't even bother with SAP authorisation. Just implement logic in some exit (as a last resort you could probably use a field exit).

If this were the case, then you might like to provide an authorisation check to override the exit logic. This might be done by creating a new auth object "Maintain Others PO's" with values that simply represent Yes and No. Of course, it all depends on your requirements as to how little work you can do...

Now, I don't follow what is meant in this context by "creating at runtime", but if you really have a unique purchase order, then I would ask what is it that makes the purchase order unique? Is it the order value, is it a particular item that is being procured? Perhaps following that line, you will be able to find a way to classify such PO's more generically.

As for authorisation groups, these tend to be fields of master data objects, like the vendor master. Most often, they are just a free text field. For example, if in the course of creating a vendor, I set the authorisation group field (often called BEGRU) to "ABCD", then the application will perform an authorisation check to see if I am authorised to create vendors with that authorisation group value (even though the value itself is free entry).

Suppose I create such a vendor, then when someone else goes to change that vendor, the application will check to see if they are authorised to change vendors in authorisation group "ABCD". The applications tend to be written so that if the object's authorisation group field is blank, then no authorisation check is made.

Cheers,

Scott