The decisive components of the authorization concept are therefore:
- Authorization objects
For objects that are to be protected, as applications within SAP, there are authorization objects created in the ABAP/4 Workbench. These objects contain fields that are meaningful to protect, and that can be restricted within the authorizations, that are created based on the respective authorization objects. All the relevant elements are already equipped from SAP with authorization objects per default. Additional authorization objects should only be created for company specific developments.
- Authorizations
An arbitrary number of authorizations can be created based on every already existing authorization object. They are the actual carriers of the access key. Here also, authorizations are delivered by SAP per default that is not limited on any organizational level.
- Profiles
SAP delivers standard profiles for all typical tasks within the SAP environment. Single and composite profiles will be distinguished; the lastnamed contain again further single or composite profiles. Included in the profiles are the necessary authorizations for the individual conceptual task.
- Activity groups / Roles
An activity group represents a collection of activities that describe a certain working area. It contains transactions as well as reports and can be extended through the creation of a user menu. A role is a release dependent synonym for an activity group. Activity groups can be combined in composite activity groups, roles in composite roles. Further nesting depths do not exist.
- User master data
User master records have to be created and managed individually in every client, provided with authorization profiles or transported from the test client into the production client via CTS (Change and Transport management System). No users exist per default, other than some SAP standard users like for example SAP* and DDIC.
Authorization objects
Structure
An authorization object is the central control element; it consists of up to 10 fields, (mostly two).
Authorization objects are sorted according to object classes. The authorization objects that are delivered per default can be identified by an underline on the second place of the technical name (for instance: F_BKPF_BED Accounting document: authorization for customers).
The result of this is that at a release change the authorization object is recognized as standard. Individual company authorization objects may not have an underline on the second place, so they will not be overwritten.
Any number of authorizations can be created based on authorization objects, so even several authorizations can have the same name, as long as they are created based on different authorization objects.
The naming convention of SAP for the authorization elements serves for the sorting in the respective modules. A letter is set on the first place that refers to the module:
A - Assets Accounting
C - Classification System
E - Consolidation
F - Financial Accounting
G - Special Ledger
K - Controlling
L - Logistic execution
M - Materials Management
P - Human Resources
S - Basis
V - Sales and Distribution
In the second place an underline is located, for example F_KNA1_BUK.
Each of these authorization objects consists of several fields (one to ten) and the possible values for these fields. The assignment of an authorization object to an action procedure (transaction, posting, report,…) is predefined by SAP® per default. Resulting from the assignment of corresponding values to these fields, an authorization is created out of an authorization object.
Only for special company interfaces the creation of company specific authorization objects will be necessary. In this case, the SAP naming conventions have to be followed; company specific objects should always start with “Y” or “Z”.
Important:
Never delete a standard authorization object!
