Authorizations

1. Program code that calls an authorization check using the authority-check statement. This will look something like:

   authority-check object id field

2. Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:

   ACTIVITY: defines the type of activity the user is doing with the data. Possible values are 'DISPLAY', 'MODIFY', 'DELETE', etc.

   
   

   COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as '0438' and '0600' thru '1100')

3. Authorization objects that define a group of fields. For example, an authorization object called 'CO_MDATA', containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.

4. Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object 'CO_MDATA', called 'CO_MDATA_ALL', that grants all access to all company master data. Then 'CO_MDATA_ALL' would have the following values:

   FIELD	VALUE
   ACTIVITY	*
   COMPANY_CODE	*

5. Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]

   Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.

6. Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user's system authorizations.

Access control in SAP is composed of several concepts:

1. Program code that calls an authorization check using the authority-check statement. This will look something like:

   authority-check object id field

2. Authorization fields (corresponding to the in the above code) that define a scope of possible values. Examples of authorization fields would be:

   ACTIVITY: defines the type of activity the user is doing with the data. Possible values are 'DISPLAY', 'MODIFY', 'DELETE', etc.

   
   

   COMPANY_CODE: possible values are any single value, or any range of values, or any combination thereof (such as '0438' and '0600' thru '1100')

3. Authorization objects that define a group of fields. For example, an authorization object called 'CO_MDATA', containing our above fields ACTIVITY and COMPANY_CODE, might used to control access to the company master data tables.

4. Authorizations, each of which belong to exactly one authorization object, that define authorization values (within the scopes defined by the authorization objects) to be granted to users. Note that an authorization is different from an authorization object!! Extending our previous examples, we might have an authorization, belonging to the authorization object 'CO_MDATA', called 'CO_MDATA_ALL', that grants all access to all company master data. Then 'CO_MDATA_ALL' would have the following values:

   FIELD	VALUE
   ACTIVITY	*
   COMPANY_CODE	*

5. Profiles, each of which may contain several authorizations or profiles. A simple profile contains a group of authorizations. A composite profile contains a group of profiles (simple or composite). [Profiles can be conceptualized as forming the structure of a tree, in which end nodes (leaves) are authorizations, and all other nodes are profiles. Simple profiles are nodes whose children are all end nodes, and composite profiles are nodes, other than end nodes, who have no end nodes for children.]

   Profiles are designed to define set or one or more functions or positions. For example, a functional profile might define all the authorizations that are required for doing a goods receipt, or for making a payment in the AP module. A position profile, on the other hand, might define all of the authorizations that are granted to an accountant, or to a warehouse supervisor. Often, a position profile is a composite profile consisting of several functional profiles.

6. Users, to whom profiles are assigned. A user is assigned one or more profiles by the system administrator. These profiles define all of the user's system authorizations.

When a user starts a transaction, the system performs the following checks:

• The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.
• The system then checks whether the user has authorization to start the transaction. The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.
  • The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.
  • If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).
    If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).
• The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.
  The check is not performed in the following cases:
  • You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.
  • This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.
  • You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25.
  • So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to “Y” (using transaction RZ10).

All of the above checks must be successful so that the user can start the transaction. Otherwise, the transaction is not called and the system displays an appropriate message.

Checking Assignment of Authorization Groups to Tables
You can also assign authorization groups to tables to avoid users accessing tables using general access tools (such as transaction SE16). A user requires not only authorization to execute the tool, but must also have authorization to be permitted to access tables with the relevant group assignments. For this case, we deliver tables with predefined assignments to authorization groups. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.

Authorization is the process of giving someone permission to do or have something. In multi-user computer systems, a system administrator defines for the system which users are allowed access to the system and what privileges of use (such as access to which file directories, hours of access, amount of allocated storage space, and so forth). Assuming that someone has logged in to a computer operating system or application, the system or application may want to identify what resources the user can be given during this session. Thus, authorization is sometimes seen as both the preliminary setting up of permissions by a system adminstrator and the actual checking of the permission values that have been set up when a user is getting access.

The following actions are subject to authorization checks that are performed

before the start of a program or table maintenance and which the SAP

applications cannot avoid:

* Starting SAP transactions (authorization object S_TCODE)

* starting reports (authorization object S_PROGRAM)

* Calling RFC function modules (authorization object S_RFC)

* Table maintenance with generic tools (S_TABU_DIS)

The authorization objects S_TCODE, S_PROGRAM, S_RFC, and S_TABU_DIS

are standard SAP provided.

Creating a new authorization object is not in the scope of ABAP developer. It will

be taken care by SAP BASIS team.

Question: Does anyone have any experience relating to performance impact of enabling/disabling the user buffer?

As of now, we have a system running with auth/new_buffering set to 4.
I have a feeling that not using the buffer may influence our performance, but it is hard to verify without running traces in the productive system?

If the buffering does indeed affect performance, will this effect be larger or smaller using structural authorizations?

I hope someone can help clarify the issue?

/Morten P. Koehler

Answer:
THe user buffer referenced in AUTH/New_buffering has nothing to do with structural authorizationsa as these are stored in a table ( if turned on) and only retreived if the user encounters a HR authorization check.

THe system impact from performance is based on logon time and the number of records SAP has to retreive from UST04 and UST10 and UST12. If you have a properly designed security it can be minimized but the use of composite and task oriented roles increase the records SAP must resolve at logon. It also impacts the size of the system you must have and the swap space you will need for processing if you have 1000's of records to store in memory. In either case the buffer exists, it has more to do with logon times.

The MAjor imact is opening up your system to a host of back doors id auth/new_buffering is > 0.

SAP's claim is a 4 must be used so you can change the users access without having them log off and back on, does not work 100% of the time.

Also the >0 setting is based on a table that are not in sync with the real security tables. SAP only syncs them once and if you do not sync them yourself ( you have to use the sync function module correctly or nothing happens) you are loading incorrect data and orphaned data.

Answer:
The symptom is "without connection to user". I.e. no logon time.

SAP also mentioned that we could also deactivate the buffering in the data-dictionary, but no client (with John's performance pre-requisities) has been willing to take the step to date. Would that (SE11) have an impact from any experiences?

Auditing Information System (AIS)

SAP Audit Information System (AIS) serves as a centralized repository for reports, queries, and views of interest to auditors. It is designed to address the overall system configuration as well as SAP business processes and their related control features, providing audit and security practitioners with the critical information they need to conduct effective reviews of their SAP systems. SAP administrators can use AIS for security auditing. The AIS plays a supportive role in providing security services for SAP systems. The primary function of AIS is auditing but auditing features can derive the measures that help in developing the security policy for SAP systems.

A successful security set up of a SAP system concludes with proper management and administration of user IDs, password resetting, audit trails, audit logs, access control list, and personnel responsibilities.

Security administration in SAP includes maintenance of the overall SAP security environment using the SAP Profile Generator, creating user-level activity groups and creating user master records.

The concept of SAP security is flexible as well as complex. SAP has a multi-layered integrated framework. To ensure adequate protection, security measures must be factored into all layers of the SAP infrastructure. With client/server architecture, SAP systems include many components that exchange information, each of which constitutes a layer of the SAP security infrastructure. Security is often not a priority in an implementation and as a result, the default security is not strong. SAP security functionality could be enhanced using various measures as discussed above.

Enterprises must develop a security strategy to ensure a secure and functional SAP system. A business critical application like SAP needs continuous monitoring and improvement of its security features.