A programmer wants to make an authorization check before bookings for business

customers can be changed.

To do this, the programmer should create authorization fields (ACTVT and CUSTTYPE)
and assign for each field defined the value to be checked (02, B). Authorization fields
are created under Tools → ABAP Workbench →Development → Other
tools → Authorization objects → Fields (transaction SU20).

Programmers should also create an authorization object (here S_TRVL_BKS) and assign
the authorization object to an object class.

Authorization fields are created

under Tools → ABAP Workbench → Development → Other tools →Authorization
objects → Objects (transaction SU21). Authorization objects can also be created in the
Object Navigator (transaction SE80).

You program the authorization check using the ABAP statement AUTHORITY-CHECK.

AUTHORITY-CHECK OBJECT 'S_TRVL_BKS'

ID 'ACTVT' FIELD '02'
ID 'CUSTTYPE' FIELD 'B'.
IF SY-SUBRC <> 0.
MESSAGE E...
ENDIF.

The AUTHORITY-CHECK checks whether a user has the appropriate authorization to

execute a particular activity.

When this happens, the system checks the authorization profiles in the user’s master
record for the appropriate authorization object (S_TRVL_BKS). If the authorization is
found and it contains the correct values, the check is successful.

The system administrator has defined the following authorizations for the authorization
object S_TRVL_BKS:

• S_TRVL_CUS1 with the following values:

* for customer type ( CUSTTYPE field) and
03 for activity (field: ACTVT).
Users with this authorization can display all customer bookings (activity 03 = display).
• S_TRVL_CUS2 with the following values:
B for customer type ( CUSTTYPE) and
02 for activity (ACTVT).
Users with this authorization can change all business customers (activity 02 = change).
When assigning profiles, the system administrator gave different authorizations to
different users.

User Miller has been assigned a profile containing both of these authorizations
(S_TRVL_CUS1 andS_TRVL_CUS2). Miller can therefore change bookings for
business customers.

User Meyers on the other hand, is only authorized to display the records
(S_TRVL_CUS1) and therefore cannot change bookings.

Authorization groups

The access protection system must ensure that only authorized individuals have access to the system and to

particular data. For achieving precise application security concerning authorization and to protect confidential

data against unauthorized access it is very important to focus on the use of authorization groups.

The table that contains all authorization objects is TOBJ.

The table that contains all activities is TACT.

The table that contains definition of all authorization groups is TBRG.

TBRG -- Contains all authorization groups and gives information about relation between authorization object and

authorization group. The description of the authorization groups is defined in table TBRGT.

The field name for authorization group -- BRGRU -- is used to make additional restrictions on authorizations /e.g.

for document maintenance/. In authorization objects and authorization checks, there are fields which are checked

to verify user authorizations. Customizing objects are combined in authorization groups, and the authorization

group is one of the two authorization fields, for example, in authorization object S_TABU_DIS which is in the

object class BC_A (Basis - Administration). This object is for displaying or maintaining tables. It controls access

using the standard table maintenance tool (transaction SM31), enhanced table maintenance (SM30) or the Data

Browser (SE16), including access in Customizing.

Authorization object S_TABU_DIS has the following fields: DICBERCLS - Authorization group, maximum field

length is four characters; and ACTVT - Activity (02: Add, change or delete table entries, 03: Only display table

contents).

Generally, SAP standard tables are assigned to authorization groups. Theseassignments can be changed. You can

then assign tables manually to a suitable authorization group. To do this, start Transaction SM30 for maintenance

view V_DDAT, and create an entry for each of these tables. In V_DDAT is stored the assignment of Tables/Views

to Authorization Groups. V_DDAT is cross-client; therefore, it can be viewed and used in all clients.
Note: If you don't make a selection, all tables maintained in Customizing transactions are assigned to

authorization groups

From www.sapnet.ru:
Credentials in ABAP programs.

The system of separation of powers in the R / 3 system based on the use of office facilities, which constitute the definition of a structure consisting of
simple fields. Object-based reference for you create your own powers, which are collections of specific values for the fields of objects of reference.
Example. Object reference F_KNA1_GRP «debtors - the authority to account group" consists of two fields:
- KTOKD - Group Accounts
- ACTVT - Operation
For this object reference can be created by the authority
{Group = Accounts 0004 (branches); Operation = * (all operations)}
And this power is assigned to the user.
In ABAP programs verification of powers made by the operator
authority-check object <ObjectName>
id <imya_polya1> {field <value1> | dummy}
id <imya_polya2> {field <value2> | dummy}
....
In the statement lists all the object's field office and provides value for testing, or used the keyword dummy if the value of a particular field we are
currently not interested.

Example. In the transaction view of the debtor, we produce first test:

authority-check object 'F_KNA1_GRP'
id 'KTOKD' field '0004 '
id 'ACTVT' dummy.
Then, when the user wants to switch to edit mode, perform a more detailed check:
authority-check object 'F_KNA1_GRP'
id 'KTOKD' field '0004 '
id 'ACTVT' field '02 '.

All the objects of reference are separated by grade, reflecting their functional purpose. View objects and their authority structures - the transaction SU21.

When should you use in your programs with authorization, it is best to use ready-reference objects, but objects are not always ready available and they
have to create.

For example, try to create an authority that will verify the user's authority to operate on a particular creditor (such a system does not).

Must first define the field, that will constitute the object. To do this, use transaction SU20. Our facility office will consist of two fields - the code of the
lender, and operation.
Initial screen of Transaction SU20:
To create your own objects using the Create button.
All created objects are called on Z. For the generated input field data element (often already existing and defining the essence of the field, in our case -
Lender), and a table to check the value (in our case, LFA1)
Save the box.
Second field - "Operation" - use the ready, it is already in the system:
Proceed to create an object reference. Transaction SU21.
"Fallthrough" in a class of objects, the relevant functional area corresponding to the created object
reference. In our case, this FI.
Create a new object using the Create button. Enter the name of the object and the first field.
Once we introduce a second field - ACTVT - you will see a new button - "Permissible operations." ACTVT field
office has a special meaning in the system, and after adding the object will need to enter a valid operation
for this object.
On the button "Available Operations" go to the management of values for field ACTVT. Pre prompted to save
the object.
In our case, mark the "Change" and "View", and keep a list of values.
Further, the exit of an object reference, because it has already been saved.
Feature of this transaction - we just do not see we created an object in the list. Needed to complete the transaction, then re-start it - the newly created
object will appear and you can view and modify if necessary.

It should also introduce the documentation to an object reference.

In order to have superusers, with the authority «SAP_ALL» also appeared all the powers at your facility, you need to regenerate the profile of reference
(the button on the toolbar).

After all this, the program is already possible to check on the powers created by the object:
In order to create your program in the future be included in the user role and bring up the powers should be as follows:
- Create a program based on your transaction, if it does not (Tr. SE93)
- Edit for the transaction list of the objects of reference as follows:

Start transaction SU24 (performed in the adjust mandante!). Enter the code of your transaction:
The following screen:
Need to select the desired transaction code and click on "Change ID verification"

For those transactions for which the appropriation of objects of reference have not yet taken place, will look like this:
Add your facility (click Paste). ID verification (green daw) set in the column of PP, as shown:
Save the data. Now for the object reference must be entered value is checked fields (if that makes sense). In our case, it would make sense if we develop
a transaction changes the lender and therefore for the field ACTVT in this transaction in any case be required to value '02 '.
Must be entered on the object reference and click on "Change the values of the fields."
A value changes by clicking on the icon "pencil".
Values of fields that are not known, for example ZLIFNR, leave blank.
Save the data. This setting is independent of mandanta, so within a single SAP system to carry anything anywhere is not necessary.

After this, when you turn on the transaction ZTEST01 a user role, in the corresponding profile of reference will be added to the power of ACTVT = '02 'and
undefined field ZLIFNR (its value is defined as, for example an interval or a value'*').

How to Create and Use the Authorization Objects in ABAP

Published by rson.

Authorization Objects are used to manipulate the current user's privileges for specific data selection and activities from within a program.

We could always create our own authorization objects and implement it in our own abap programs. As an example, we will create our own
authorization field similar to TCD used in S_TCODE Authorization object

Steps to create authorization field

1. Go to transaction code SU20
2. Click the create new button on the application toolbar.
3. Enter "ZTCODE" in the Field Name and "TCODE" in the Data Element, then hit Enter.
4. Click the save button on the system toolbar.

Steps to create authorization class

1. Go to transaction code SU21
2. Click on the Create button's drop down icon and select "Object Class".
3. Enter "ZTRN" on the Object Class field.
4. Give it a description and save it.

Steps to create authorization object

1. Again in SU21, in the list of authorization class (folder icon), click the one that we've created (ZTRN).
2. Click on the Create buttodrop down, this time selecting "Authorization Object".
3. Enter "Z_TCODE" on the Object field and give it a description.
4. On the authorization fields section, enter ACTVT and ZTCODE. ACTVT is used to set and limit the activity of the user, while the ZTCODE is
the authorization field that we've created earlier which is
responsible for holding a list of tcodes.
5. On the Further Authorization Object Settings, click on "Permitted activities" button. Here we will select the specific activities that we want
to be available for our authorization object.
6. As an example, we will select 01 (Create), 02 (Change), and 03 (Display).
7. Save and Exit.

Now we're done creating our own authorization object, let us now use and assign it to a user.

Steps to create a role

1. Go to transaction code PFCG.
2. Enter "ZAUTHTEST" on Role field and click the "Single Role" button.
3. Now give it a description, click the save button and click the Authorization tab.
4. Click the "Change Authorization Data" button inside the authorization tab.
5. Then click the "Manually" button on the application toolbar and type in the name of the authorization object that we've created earlier
("Z_TCODE") and press enter.
6. Expand all the nodes, double click on the input field of the Activity and select activity 01 and 02.
7. Enter the tcode of our own abap program in ZTCODE field, in our example I used "ZCOMM".
8. And also don't forget to add the S_TCODE authorization object and enter ZCOMM on it's field.
9. Now Click on the Generate button in the application toolbar and press enter on the pop-up screen.
10. press the back button and assign a specific user on the user tab and click User Comparison button.
11. Now create another role by repeating steps 1 to 9 but this time select activity 03 on step 6.
12. Then assign this 2nd role to another user.

Now let's implement this authorization in our ABAP program. Let say we have a dialog program (ZCOMM) wherein we have a button on the
screen that when clicked, the user will go to the Create / Edit screen (1000) if he's authorized. On the other hand, he will go to display only
screen (2000) if he's not authorized. To do that, simply add the code below on your program.

Code:
AUTHORITY-CHECK OBJECT 'Z_TCODE' "authorization object that we've created
ID 'ACTVT' FIELD '01 '"Activity = 01, authorized to create
ID 'ZTCODE' FIELD 'ZCOMM'. "Tcodes that we wants to check for authorization
IF sy-subrc EQ 0.
CALL SCREEN 1000. "The user is authorized to create
ELSE.
CALL SCREEN 2000. "User is not authorized to create (Display only)
ENDIF.