BTP - Authorization Object

Table of contents

• Introduction
• Authorization Field
• Authorization Object
• Creation
• Object
• Activities
• Core Data Service
• Access Control
• Inheritance
• Access
• SQL Console
• Complete Example
• Conclusion

In this episode, we'll look at how to create an authorization object in the ABAP environment and use it to restrict data access in a Core Data Service, in order to make our app more controllable later on.

 

Introduction

We'll be extending our Sales App, which we've already created and extended in many previous articles. The idea is to restrict access to the data within the application so that employees can only work with the data they are authorized to access. To do this, we first need a classic authorization object to define the data and visibility.

 

Authorization Field

First, we need an authorization field that allows us to restrict access to a specific field. Generally, we can reuse fields from the standard if we also have the corresponding information in our application. In this case, we want to restrict access to the partner, which is part of the data within the sales app. This means we create a new authorization field for the corresponding data element that we created for the partners.

 

In the lower section, we can assign a table that provides information for the field, in order to later provide a selection when maintaining authorizations. Using the "Search Help" button, we can check which values are retrieved that the authorization colleague will later have available for maintenance. We don't need to specify a table here if, for example, we are using a data element that has a fixed value domain. Then the values of this domain, just like the texts, are automatically used and offered later in maintenance.

 

Authorization Object

Let's look at the most important element in this chapter, the authorization object, and how we can configure its settings.

 

Creation

In the next step, we need the actual authorization object. In the classic world, we could create this via SU21. In the new world, no transaction is available for this; instead, we have to create the element normally using the ABAP Development Tools. Aside from the actual element, which is relatively short, and the description, we don't need to provide any further information to create the element.

 

Object

In the actual authorization object, various pieces of information are available to us. In the upper part, we first have general information about the type of authorization object. In the middle part, we find the various fields, such as the field we previously created for the partner ID. It is generally best practice to also include the activity. In the lower part, we then find the various activities that are activated for the object. We can further control these in a more granular way. More on this in the next section.

 

We now add our new authorization field to our current authorization object so that we can later restrict access together with the activity. The various activities are already correctly defined, so we'll leave them as they are for now.

 

Activities

Activities are found in virtually every authorization object and control the different scenarios for how we interact with the data. For example, the default in most cases is 01 for creating, 02 for modifying, and 03 for displaying. Additionally, there are other activities such as 06 for deleting or 16 for executing. The activities are standardized so that every administrator and developer immediately understands what they can do when they see an activity. Therefore, this information is also important because in most cases, when working with data, we not only restrict viewing permissions, but also define, for example, how we can interact with the data, whether we are allowed to modify it, or whether we are allowed to delete it, with deletion in most cases only being possible for administrators.

 

Core Data Service

After creating the permission object, we want to use it directly. For this, we adapt our Core Data Service and examine the change within the process.

 

Access Control

Let's now extend our Access Control, which is currently only implemented as a dummy, but is nevertheless already present. To do this, we add the partner field to the WHERE condition and perform an authorization check using PFCG_AUTH. First, we specify the authorization object against which we are checking, second, the various fields against which we are matching the database, and third, we can specify the activity, which we assign a fixed value to, in this case 03 for display purposes.

@EndUserText.label: 'ZBS_R_SASALE'
@MappingRole: true
define role ZBS_R_SASALE {
  grant select on ZBS_R_SASALE
  where ( PartnerNumber ) = aspect pfcg_auth( ZBSDMOPART, ZBSDMOPART, ACTVT = '03' );
}

 

Inheritance

Through inheritance within the Core Data Services, the authorization check is also passed on to our Consumption View. This means that if we now run our application and display the data, we will find that we currently see no data at all, as we do not have permission to view this information. This is the first good test to verify whether our authorization check is working.

 

Access

Since we have implemented the authorization check at the lowest level, we also do not receive any data if we call the Data Preview (F8 in CDS) directly from the Core Data Service. Even in the Data Preview, the authorization check or access control is used, and we only see the data for which we are actually authorized.

 

SQL Console

However, as developers, we can use a little trick here. To do this, we go from the Data Preview to the SQL console, which is possible via the button at the top, and then add the addition WITH PRIVILEGED ACCESS to the statement to disable the authorization check and gain direct access to all data. On the right side in the Data Preview, all data records that exist in the database are then loaded.

 

Hint: It is important to note that you use the WITH addition. This is necessary in the SQL console. If you are already using statements in ABAP, PRIVILEGED ACCESS is used to access all data in the SELECT statement.

 

Complete Example

You can find the complete example in GitHub in the corresponding package for the Sales App. The changes from this article can be found in this Commit and you can follow the changes, plus the additional information.

 

Conclusion

Besides a good application, a good authorization concept is also crucial if an application is to be good and secure. The authorization object is the first step in securing the data and enabling standardized access. In addition to the actual authorization field, you should also maintain the activity, which is offered and available in almost every authorization object, in order to map the various actions.