Web Dynpro and Authorization

Based on the RBAC (Role Based Access Control) pattern,we are going to present the SAP R/3 role based authorization mode. According to it, a user can dispose of a number of roles,which grants to him/her the authorization to access certain resources from the system. In this respect,we will create the development objects required to grant to the user the possibility to access the records from a database, and we will use,in Web Dynpro ABAP, the declaration AUTHORITYCHECK to verify the current user’s authorization.

For standalone Web Dynpro applications, being not integrated in the portal,the security shall be programmed into the application. For the applications that run into the Portal,we can use the Portal security to authenticate and authorize the access to the application.

The way we can do this depends on specific situations.For example,we can define in the portal the authorization for the content we offer to the user,but we cannot define the authorization for the backend application itself.

This kind of authorization shall be done in back-end, through development objects
as authorization fields,authorization object,etc.To check which functions can be executed by the user or which objects can be accessed by him,in backend,through a Web Dynpro application, we can use statements as AUTHORITY-CHECK.These statements are implemented at the program level in our application or into the model used for our application.

Now,we create a very simple example to show how we can use an Authorization Object into a Web Dynpro component to check the authorization of the current user and to grant access to the Open SQL delete action for our database table YPERSON.

We use a user administrator and a profile administrator to create the object class,the authorization object and the role,and to assign the created role to our test user Gellert.By using our test user, we create the Web Dynpro component and we check his right to perform the desired delete action.

The relationship user – roles – permissions, for our example

An Authorization Object is used to check a user authorization for special activities.Usually,the authorizations are combined into authorization profiles,and these profiles are assigned with a role.Then, a role (single or composite) can be assigned to users, and all the authorization changes affect all the users that have assigned the respective role.

The scope of the present chapter is to offer to the reader a general idea about the authorization concept SAP R/3 and about the modality of using this concept to create secure Web Dynpro applications.This is the reason why we chose an example where we could create all the required development elements, even if in practice this requirement appears only occasionally

SAP offers a large range of authorization objects and templates that we can use and customize according to our requirements.In most cases,to grant access to the tables, we use authorization groups(extended authorization for particular objects)and authorization objects, as: S_TABU_DIS,S_TABU_LINE.
We have already used an authorization group in Chap.11, where we have created table maintenance. In that example, we chose from the authorization group list “&NC&”(no security) and we saw that the authorization object has been predefined as S_TABU_DIS.

We can assign an authorization object,through the menu Utilities --> Assign Authorization Group,to a view and to a transparent table created in the ABAP Dictionary.

Because in our case we offer the capability to delete certain records from the YPERSON table by only one user, the usage of the authorization group has no meaning. Another reason for using the authorization groups in the example was to put forward the basic elements, without entering in the private objects field and,in the same time, to present the authorization field ACTVT we shall meet often during.

working with Web Dynpro applications,when we check the authorization for different activities,with tables.

Role Based Access Control Pattern - RBAC

The Pattern that stays at the basis of the presented concept is the Role Based Access Control pattern,an access control model currently used to develop secure systems.

This pattern was firstly formalised by Ferraiolo and Kuhn, in 1992 (the 15th National Computer Security Conference,1992, Baltimore MD, pages 554–563), in a form that allows the users to access the resources by using roles and permissions, and where the roles can inherit permissions from other roles.

Various forms of Role Based Access Control have been created and implemented in a variety of commercial systems. Hereunder,we present a extended form of the RBAC pattern.

Pattern Name: Role based access control.

Context:Any environment where we need to control the access to resources based on the user’s roles.

Problem: How we can assign rights to users in concordance with their roles,so that each user to have only the authorization required to carry out his responsibilities?

Solution: It is presented a classmodel for the Role Based Access Control

The role based access control pattern Schumacher et al.(2006)

We will explain this concept as regards to the Application Server ABAP. The Class User represents the user that attempts to access the protected object (transactions, programs, services),and the Role class represents the user roles.A role can be a single role or a composite role. The composite role can contain only single roles, and the single role can contain,for example,the logon menu for the user and authorization objects.SAP offers a large number of single roles to be used, but we can also create our own ones. Class Right describes the access type(delete, write, etc.).

Each user can be member of a group or more.Through the Session class,it is implemented the principle of “least privilege”, according to which a user gets,through every session, only the privileges required to perform his responsibilities.

In our example presented in Fig.the profile administrator creates a single role ZTEST_ROLE,assigns to it the authorization object ZTEST_AUTH,maintains the fields and generates the authorization profile. Our test user, Gellert, tries to perform a delete operation in the YPERSON database,but he doesn’t have assigned the ZTEST_ROLE yet.

That’s why he doesn’t have the authorization to perform this operation.Only after the user administrator assigns him the role, he can perform the delete operation for the database records found in the range 004–100. So,we have the separation between the role administrator and the right administrator. Besides this basic division, there are other different scenarios that can be used.

Applications: J2EE, SAP NetWeaver, Oracle, etc.

Authorization Object Class

One or more Authorization Objects shall be assigned to a Class. To create a new class,we can use,from the screen “Maintain Authorization Objects”(transaction SU21),the CREATE button.

Creating an object class

Authorization Object

After creating the class, we can create an Authorization Object directly in the created class or we can firstly create an Authorization Object and then assigning the Object to the created class.

Creating an authorization object

Assigning an Authorization Object to a class

Authorization Fields

An Authorization Object can contain maximum ten authorization fields.These fields can be chosen from the list of the existent ones(activities,actions, etc.) or we can create our own authorization fields.The structure of the Authorization Object named ZTEST_AUTH.

Defining the authorization field

We have chosen to add a field named ACTVT, because we need to check an activity.The possible activities that can be protected are stored in the table TACT that has a 1:CN key relation with the table TACTZ and a txt relationship with the table TACTT.In the table TACTT,there are stored the activities descriptions,and in the table TACTZ there are stored the valid activities for each authorization object.

TACT and some of its related tables

Table TACT

Actions from the TACT table

From the “Create authorization Object” screen,we can use the button “Field Maintenance” or we can use the SU20 transaction to navigate to the list of the authorization fields.

List of authorization fields

Authorization field

Then,we save the new created Field and go back to our Authorization Object. Here,we insert the ZAF_PERSON and,by using the “Permitted activities” from the end of the screen, we select the Delete activity from the activity list.In case we want to re-use this authorization object in the future,we can tick more activities, and we use for our request only the delete activity

Defining the activities

Creating a Single Role and Changing its Authorization Data

After creating the Authorization Object, we create a new single role by using the transaction PFCG.

Creating a new role

After this,we change the authorization data for the new created role.To realize it, we use the “Authorizations” tab,the “Maintain Authorization Data and Generate Profiles” area,and the “Change Authorization Data” button. By using the “Menu” tab,we can define fragments from the user menu that can be seen in SAP Easy Access. Because our authorization doesn’t require new transactions or other objects, we don’t use this tab. By using the “User” tab, we can assign users to the role. We will not use this option,but we will add later the new created role to our test user.

Changing authorization data for a role

In this case, we don’t want to use a Template to generate an authorization profile.This is the reason why we choose, from the pup-up window,the button “Do not select templates”.

Choosing the template window

For the scope of our example,we manually select our authorization object.We use the “Manually” Button and enter the name of the Authorization Object we have just created.

Manual selection of the authorization

After this,we choose the activity found in our list –“DELETE”

Choosing the DELETE activity

Then,we choose the range of IDs where the specified DELETE action is enabled to be performed.

Full authorization for IDs

We generate the authorization profile by using the Generate button .As a result, we can see our profile that offers the authorization to delete data from the database table YPERSON – records from 004 to 100.Creating

Generating the profile

Creating the Web Dynpro Component

Then, we create a WD component named Y_AUTHORIZATION.The component structure is presented.

WD component structure

By using this WD component, we can search for a record in the database table YPERSON and we can delete a record in case the authorization enabled us to perform the desired activity. The view layout and view context structure are presented.

Checking the Authorization of the Current User

When the user presses the Delete button, the Framework triggers the event handler method onactiondelete.

Context structure and view layout

The onactiondelete event handler method

  METHOD onactiondelete.
  DATA: lt_candidate TYPE TABLE OF yperson,
  lr_node TYPE REF TO if_wd_context_node,
  lv_id_person TYPE yidi.
  DATA lr_api_controller TYPE REF TO if_wd_controller.
  DATA lr_message_manager TYPE REF TO if_wd_message_manager.
  lr_api_controller ?= wd_this->wd_get_api( ).
  lr_message_manager = lr_api_controller->get_message_manager( ).
  lr_node = wd_context->get_child_node('DELETE').
  lr_node->get_attribute(EXPORTING name = 'ID_PERSON'
  IMPORTING value = lv_id_person).
  AUTHORITY-CHECK OBJECT 'ZTEST_AUTH'
  ID'ACTVT' FIELD '06'
  ID'ZAF_PERSON' FIELD lv_id_person.
  IF sy-subrc EQ 0.
  DELETE FROM yperson WHERE id_person = lv_id_person.
  IF sy-subrc EQ 0.
  lr_message_manager->report_t100_message(
  msgid = 'YCL_T100_MSG'
  msgno = '004'
  msgty = 'S').
  ENDIF.
  ELSE.
  lr_message_manager->report_t100_message(
  msgid ='YCL_T100_MSG'
  msgno ='003'
  msgty ='E'
  ).
  ENDIF.
  ENDMETHOD.

As we can see,we have implemented an authorization check before performing the delete action.

AUTHORITY-CHECK OBJECT ’ZTEST_AUTH’
ID ‘ACTVT’ FIELD ‘06’
ID ‘ZAF_PERSON’ FIELD lv_id_person. In this way, we check the authorization of the current user.

We can have minimum one and maximum ten authorization fields with specified IDs. In this case,we have the ACTVT and our own created authorization field ZAF_PERSON. For each authorization field, we can specify a value to be checked or we can use the additional DUMMY to avoid checking the respective field.

The check is successful only if all the conditions are fulfilled: the field ACTVT (Activity) with the permissible value 06 (Delete) AND the field “ZAF_PERSON” whose permissible value is one of the IDs from 004 to 100.If the check is successful,the sy-subrc = 0;otherwise, it is set to a value not equal with 0:

4 – Authorization check not successful.
12 – No authorization was found for the authorization object.
24 – Incorrect authorization fields or an incorrect number of authorization fields was found.

In the Message Class YCL_T100_MSG, we have defined two messages with the IDs 003 and 004,required to show the success message,or the error message in case the action is not allowed. We have created a role ZTEST_ROLE, but we haven’t assigned it to our user.

This is the reason why, at runtime, we are not allowed to delete the record with the ID “004”. Figure shows the User Interface at runtime.

Runtime

In case we don’t have a certain authorization, as developer for fulfilling the required tasks,we can use the transaction SU53 to find what authorization is missing and to inform the administrator about it.After receiving an exception message caused by a failed authorization,we have to use the specified transaction and to make a screenshot for the administrator.For example,if we try to use the transaction SE11 and we don’t have the proper authorization, in the transaction SU53 we will see the object class, the authorization object and the authorization field we need.The transaction ST01 offers the possibility to create a system trace to find the missing authorization objects.

The missing authorization check

Assigning the User-Role and Running the Application

To be able to perform the delete action, we have to assign the created role to the user that needs to perform this action (In our case, the test user Gellert). By using thetransaction SU01, we have the possibility to change user master records (e.g. change,lock or unlock,change this password),to delete user master records or to create a new user (directly or by copying an existing one).

User maintenance

In the tab “Roles”, we can assign our created role ZTEST_ROLE to the test user.

Assigning the role “ZTEST_ROLE” to our test user

We run again our Web Dynpro application.The authorization rights become effective and our test user can perform the delete action for the records 004–100 from the database table YPERSON.

The user is allowed to delete data

In case we are trying to delete a record not included in the range 004–100,we get the same “Not Authorized” message.In this case, the authorization check is performed and the system compares the values entered by the administrator in the authorization profile with the values required by the program.As a result,the check is not successful and he is not allowed to perform this task.

Deleting a record not included in the range 004–100

Other authorization objects, which we often check,are:
S_TCODE – to check the authorization to run a transaction
S_PROGRAM – to check the authorization to run a program
S_RFC – to check the authorization to run a RFC
S_TABU_DIS – for table maintenance