By Soujanya Madhurapantula.

Recap: the 2-layer SAP authorization model

In our previous post, we introduced a 2-layer SAP authorisation model: a combination of Role-Based Access Control plus Attribute-Based Access Control. To comply with regulatory mandates such as export control, where access to data is dependent on multiple factors, such as location, nationality and content, it is prudent to augment SAP’s authorization model in order to control access at the data level.

Complying with Electronic Export Control (using ITAR/EAR as an example)

Let’s take the scenario of a large Aerospace and Defense firm that must comply with ITAR and EAR export control regulations.  These are pertinent today because they cover not only defense articles and services, but also the technical data associated (such as CAD drawings, Bills of Materials, etc) with the defense articles.

To comply, the firm will need to restrict access to technical data unless an explicit export authorization is granted. Examples of violation include:

  1. A  “Deemed Export” violation happens when technical data is accessed by a non-US person, even if the access is from US soil, unless an export license has been granted
  2. An “Export” violation happens when technical data is transmitted outside of the US, even if the recipient is a US person, unless an export license has been granted

In order to comply, we need to identify the access-control problems at a more granular level. Identifying US citizenship and role, and location where data is accessed and used, is easier when you apply ABAC. In this scenario, we can leverage SAP GRC Access Control to administer access at the application and transaction level, and leverage ABAC to authorize access at the data level.

Supercharging the authorization model with ABAC for location and license awareness helps effectively police data entitlements in complex projects. This hybrid design fully integrates the features and capabilities of SAP authorization, such as ease of user assignment, with the efficient support of data attributes that mitigates “role explosion” and custom development that would otherwise be necessary and costly.

Types of Attributes

So what are the fundamental considerations of Attribute-Based Access Control? A combination of 3 articles…


  1. Identity attributes like the ones I mentioned above (nationality, company, and department) identify who the user is in order to control access:
    • Is the person a foreign national?
    • Does the person belong to the relevant organization, department or team?
  2. Context attributes help us understand how the person is accessing and interacting with the data.
    • Is the person located outside your national soil at time of access request?
    • Is the person using a VPN or a browser to make access?
    • Is the requested file associated with a specific export license?
  3. The content of the document uses what it is to define its level of control. We don’t want to restrict access to all the documents in a site irrespective of whether they are controlled or not. So content attributes like metadata, custom tags, and labels extend the access control to a more fine grained level based on the data present.

A combination of GRC Access Control and ABAC can provide the best of both worlds: a way to easily administer and control access at the transaction level based on compliant user roles, and a way to dynamically authorize access at the data level.

Soujanya is the Product Manager for the Entitlement Manager for Enterprise Applications at NextLabs. She works with the Solutions Management team to devise best practices for securing and controlling data in order to develop solutions for Global 5000 business around partner collaboration, export regulations, IP and Data security.