Authorization checks are a means of protecting functions or objects in the R/3 System. The programmer of the function determines where and how these checks are made, while the user administrator determines (within the framework defined by the programmer) who can execute a function or access an object.
The terms central to the SAP authorization concept are:
Authorization field
This is the smallest unit against which checks can be made. The programmer can create authorization fields by selecting Tools -> ABAP Workbench -> Development -> Other tools -> Authorization Objects -> Fields (SU20).
Example: ACTVT and CUSTTYPE.
Authorization object
An authorization object groups together 1 to 10 authorization fields which can then be checked as a combination. The programmer can create authorization fields by selecting Tools -> ABAP Workbench -> Development -> Other tools -> Authorization Objects -> Objects (SU21).
Example: The authorization objects S_TRVL_BKS groups together the authorization fields ACTVT and CUSTTYPE.
Authorization
An authorization is a combination of permitted values for each authorization field of an authorization object. The user administrator creates authorizations by selecting Tools -> Administration -> Maintain users -> Authorization.
Example:
S_TRVL_CUS1 is an authorization for the authorization object S_TRVL_BKS with the values for customer type (CUSTTYPE) and 02 for activity (ACTVT).
Users who have this authorization are allowed to change the bookings of all customers.
S_TRVL_CUS2 is an authorization for the authorization object S_TRVL_BKS with the values B for customer type (CUSTTYPE) and 03 for activity (ACTVT).
Users who have this authorization are allowed to display the postings of all customers.
Authorization profile
An authorization profile represents a simple workplace in the context of authorizations. An authorization profile contains authorizations for the authorization objects a user needs to operate effectively in a restricted task area. The user administrator creates authorizations by selecting Tools -> Administration -> Maintain users -> Profiles.
User master record
Your user master record is checked when you logon to the R/3 system. Through the authorization profiles, this provides restricted access to the functions and objects of the R/3 System. The user administrator creates authorizations by selecting Tools -> Administration -> Maintain users -> Users.
Authorization check
The programmer can perform authorization checks with the ABAP command AUTHORITY-CHECK by specifying the value to be checked for each authorization field defined. The system then scans the profiles in the user master record for the authorizations specified. If one of the authorizations found for all fields of the authorization object covers the values specified by AUTHORITY-CHECK, the check was successful.
Example: Check whether the user is allowed to change the postings of business customers:
AUTHORITY-CHECK OBJECT 'S_TRVL_BKS'
ID 'ACTVT' FIELD '02'
ID 'CUSTTYPE' FIELD 'B'.
IF SY-SUBRC <> 0.
MESSAGE E...
ENDIF.
If the authorization S_TRVL_CUS1 exists in the user's master record, the authorization check is successful. However, if the authorization S_TRVL_CUS2 exists, but not the authorization S_TRVL_CUS1, the check fails.
Authorization assignment
The system administrator is responsible for assigning user master records with the correct authorizations. You should use the Profile Generator to maintain authorization profiles. However, you can also change them manually. Each authorization object contains authorizations. These are grouped together in authorization profiles such that each authorization profile represents a job description, for example 'flight reservations clerk'. You assign one or more authorization profiles to each user master record. You can assign an authorization to as many authorization profiles as you like, and an authorization profile to as many composite profiles and users as you like. Composite profiles are used in manual authorization maintenance, and form a further division in the authorization structure. However, they are not strictly necessary.
Check this it a sample code :
FORM sub_check_auth_iwerk .
*--Constant for t code, no tcode hence value = '' (all)
CONSTANTS: lc_tcd LIKE tstc-tcode VALUE '*'.
*--Table for all the plants in selection screen. This table will be used for authority check.
DATA: BEGIN OF li_plant OCCURS 0,
iwerk LIKE t001w-werks,
END OF li_plant.
*--Select query to pick plant from table t001w
SELECT werks "Plant
INTO TABLE li_plant
FROM t001w
WHERE werks IN s_iwerk.
LOOP AT li_plant.
AUTHORITY-CHECK OBJECT 'I_SWERK'
ID 'TCD' FIELD lc_tcd
ID 'SWERK' FIELD li_plant-iwerk.
*--Check SUBRC
IF sy-subrc NE 0.
*--No Authorization for Plant
MESSAGE e016 WITH li_plant-iwerk.
ENDIF.
ENDLOOP. "loop at li_plant
ENDFORM. "sub_check_auth_iwerk
