Overview

Instance-Based Access Control for Custom Developed Business Objects

This article gives you a brief overview of how you can use instance-based access control on custom developed Business Objects and the steps to implement it.

Table of Contents

When creating custom Business Objects (BO), one of the most common concept, is the instance-based access control concept. This is a well-known topic, but in development, it is not often used. You may even be unaware that SAP Cloud Applications Studio supports this.

To understand how you can apply instance-based access control to your custom Business Objects, start by analyzing a popular scenario in projects: “An employee should only see the data he or she created.”

The whole process can be divided into two steps:

1. Develop restrictions.
2. Assign access rights. 

The below sections go into detail on how to proceed.

Developing Restrictions

Before you get confused with terminologies, it should be clear that you are not going to actually “develop” any restriction here, it is just that you are going to use the existing restrictions which come with standard Business Objects.

There are several standard Business Objects with an Access Context tagged to it which is the base for restriction. This information is available in the Business Object Explorer of the Repository Explorer.

The “magic” behind this is to link these standard Business Objects in your custom Business Object to an association defined with specific annotation. NOTE: This will no longer be a normal association and will be used for a specific purpose.

Once this is clear, you can now consider the employee scenario mentioned above.

Since we don’t want an employee to see other employee’s records, the restriction is on Employee.

Next step, select the appropriate access context, for example, you can decide to use 1000 – Employee Self Service.

To get that Employee restriction, search in the Repository Explorer and notice that the Employee Business Object has the access context needed.

Now, that you have all the required information, create a custom Business Object (BO).

Let’s create a custom Business Object with the name “AccessControlObj”. The definition will be as shown below:

import AP.Common.GDT as apCommonGDT;
import AP.FO.BusinessPartner.Global;
businessobject AccessControlObj {
  element Employee:EmployeeID;
  element Consistent:ConsistencyStatusCode;
  [RelevantForAccessControl] association For_Access_Control to Employee;
}

You can also create screens using navigation.

Key Points:

• Above definition has a minimal set of elements which are needed for this experiment.
• [RelevantForAccessControl] is the annotation which is to be used to link association with standard objects to inherit the access context for your custom Business Object.
• You still didn’t specify in any way that you need Employee level restriction.

You need to create a Business Object Query for the custom object as there is Access Control List (ACL) data which will be retrieved only by the Fast Search Index (FSI) Business Object Query.

Below is a snapshot of the BO Query, Overview.qry, that was created:

Let’s talk more about the association now.

The question is what exactly is the base for creating the association?

The association links to Employee Business Object. This means that every custom Business Object instance should have this association linked with the creator (employee) of that instance so that you can use it for restricting later on.

You need to specify what can be used for filtering instances here. You can use an association relevant for access control which will be used against the ACL data of Business Object Query that you created.

Now comes the interesting part of writing code for creating the association. Create a BeforeSave script for your custom BO and add the following, for example:

import ABSL;
import AP.FO.BusinessPartner.Global;
import AP.PC.IdentityManagement.Global;
if( ! this.For_Access_Control.IsSet()){
  var currUUID = Identity.Retrieve(Context.GetCurrentIdentityUUID());
  if(currUUID.IsSet()){
       var q = Employee.QueryByIdentification;
       var q_selparams = q.CreateSelectionParams();
       q_selparams.Add(q.UUID.content,"I","EQ",currUUID.BusinessPartnerUUID.content);
       var q_res = q.Execute(q_selparams);
       foreach(var emp_ins in q_res){
            this.For_Access_Control = emp_ins;
       }
  }
  if(this.For_Access_Control.IsSet()){
       this.Consistent = "3"; // Consistent
       this.Employee.content = this.For_Access_Control.IdentificationEmployeeID.EmployeeID.content;
  }
  else{
       this.Consistent = "2"; // Inconsistent
  }
}

Now, that all of the code-related parts are completed, we can proceed with the User Interface (UI) Designer-related enhancements.

Open Object Work List (OWL) Changes:

Go to the Object Work List (OWL) of custom BO to change the query to the BO query that you created in the earlier step.

• The Query section, under the Controller tab, should look like this:
  
  
  
  

• Binding, under DataModel tab, should look like this:
  
  
  
  

• You can see here that you did not bring the association into the DataModel, as ACL is an instance level feature. 
• Save and Activate.
  
  

Quick Create/Thing Inspector/Thing Type Changes:

Open the following screens and change Properties as shown below under the RBAM Data section:

• Change the Access Check Mode to “PrivilegedExceptAccessControlBusinesssObjects”.
• Set Authorization Classification Code to “Application”.
• Select Access Controlled Business Object and make sure you see your object having Unrestricted Access unchecked.
• Save and Activate.
  
  

Work Center (WC) View Changes:

Open the custom WC view and change the AccessContextCode under the RBAM Data section to “1000 – Employee Self Service” as shown below:

At this point, you might want to check if all your linked UIs are assigned to your WC view by clicking on AssignedObjects.

This completes the first step.

Assign Access Rights

For the second step, pick two business users to test, for example, ATROCKSTAR01 and ATROCKSTAR02.

A common task for both users is to assign your custom Work Center view. Once that is completed, set access restrictions for both users.

You can start by opening the access rights for ATROCKSTAR01 and notice that the restrictions are set automatically.

You will see the same for ATROCKSTAR02 as well.

After checking the appropriate access context is assigned, proceed to test it.

Log in as ATROCKSTAR01 and create one instance in the custom WC view, as shown below. Once you are done, log off.

Log in as ATROCKSTAR02 and notice that you will not see the instance created by ATROCKSTAR01.

So, go ahead and create an instance as shown below.

Let’s get back to SAP Cloud Applications Studio and query your custom BO as shown below.

You should get two instances.

Possible Issues and Troubleshooting

Sometimes, this feature may not work immediately after setup. In our example, we took instances of ATROCKSTAR1 and ATROCKSTAR2. An employee may see another employee’s records regardless of the access restriction you had set in your custom work center view.

The reason behind this is that when you set access restriction to your WC view and activate it, Role-based Access Management (RBAM) policies are generated for that view. In the case where it doesn’t get generated, then this functionality will not work when you test it during runtime.

There is no option from SAP Cloud Applications Studio to generate these policies. Ideally, RBAM policies are generated when the UI model is generated. Therefore, when you deploy and activate a solution, it will be triggered.

The generation itself happens as an asynchronous job in the backend. So, sometimes it may take some time.

If the generation is incomplete, then this functionality won't work. In this case, raise an incident to investigate this issue.

Conclusion

This article introduced you to the instance-based access control concept for custom Business Objects. Now, you can leverage this knowledge to define your specific access control on your developed BO.