Analysis of SAP’s ability to use ABAC

[Former Member]

Author Bio

The author is a SAP HCM subject Matter Expert since 1997 where he started in SAP. Niels Knuzen worked as consultant for SAP Nordic where he participated in numerous global roll outs and worked as instructor on the SAP HCM academies. In 2003 he swapped to customer site and joined the global HCM customer group. In 2006 he started the company KNUZEN SAP HCM Security and has since been focusing on authorizations, identity management and security.

1.       About this document

This document describes the option for using ABAC within SAP R/3 systems. The need for more flexible and efficient access control mechanisms is increasing. The drivers for the adoption of ABAC are the need for efficient access management
and information sharing. Organizations need to govern how information is shared across systems, applications, and organizations. This governance needs to be automatic and in right time.

The ABAC principle seems to have properties which fulfill the demands for a future access control mechanism.  We have based our analysis on different sources such as NIST, NextLab, Gartner Group’s research and our own experiences with SAP authorizations.

2.       RBAC Role Based Access Control

Role-Based Access Control model (RBAC) employs customized roles that carry a specific set of access rights associated with them to which users are assigned. For example, a user assigned the role as HR consultant will have access to a different set of master data than someone assigned the role as finance controller.

In RBAC access is manually determined by the person assigning the roles to each individual and fixed by the master data owner when determining the authorizations associated with each role. To avoid the manual assignments Identity Management (IdM) has been implemented
by many companies on top of their existing RBAC model. The entire role generator delivered by SAP is usable for RBAC.

Figure 1: The mathematical set up for roles when the master derived concept is used.

Example: Total number of roles based on 10 template roles derived to 4 company codes equals 40

Within the existing set up for SAP security we have the profile generator, which supports different forms of RBAC variants. The most common used variant is the master/ derived concept, which is a restricted hierarchical RBAC where the functions, transactions and objects are inherited down to the derived roles and added information of where to use the roles through the organisational levels.  A mathematical model in figure 1 shows the aggregation of roles with master derived variant.

Figure 2: The mathematical set up for roles based on functional / organisational roles. This set up reduces the amount of roles are accumulated according to those dimension chosen for segregation. Example: Total number of roles 10 functional roles plus 4 organisational roles represented by company codes = 14 roles

Figure 3: The mathematical set up for roles based on a ABAC hybrid role model. This set up reduces the amount of roles by removing the organisational dimension from the roles. Example: Total number of roles 10 functional roles plus 4 company codes represented a rule set  = 10 roles. This is only for a hybrid solution I will in the next chapter explain the principles of ABAC.

3.       ABAC

ABAC is a logical access control methodology where authorization to perform a set of operations is determined by evaluating
attributes associated with the user against procedure, rules, or relationships that describe the allowable operations for a given set of attributes.

3.1     A Definition of ABAC: Attribute Based Access Control in SAP.

Attribute Based Access Control (ABAC): An access control method where user requests to perform operations on master data are
granted or denied based on assigned attributes of the user, assigned attributes of the master data, environmental conditions, and a set of policies that are specified in terms of those attributes and conditions.

3.1.1      Attributes

Attributes are defined characteristics which can be found in our master data such as company code, personnel area or employee group,
environment conditions is also attributes and they can be portal, NWBC, SAP GUI or SF. All these attributes are predefined and pre assigned either manually or automatic through the business procedures reflected in the SAP system.

Master data may receive their attributes either directly from the creator or as a result of automated procedures executed
during creation. When John Smith was hired he where assigned the personnel area 1250 Copenhagen which is assigned the company code 1200 Denmark, which is part of the business area 1000 EMEA.

3.1.2      Subject: The user who have a purpose for access.

A User is a person or NPE “non person entity” such as service or application. Users are assigned one or more attributes. One of the
main benefits of the ABAC set up is referred to as accommodating the external (unanticipated) user and is one of the primary benefits of employing ABAC. ABAC is in its full extension a merging of IdM and ACM.

ABAC enables master data and process owners to apply access control procedure without prior knowledge of the specific user and for
an unknown number of users, which also requires access.

For example, a user (subject) is assigned a set of subject attributes when hired (john Smith is hired as Senior Controller in the department: Group Finance and his contract belongs to Denmark, which is part of division EMEA

3.1.3      Object/ Master Data.

An object is a transaction or piece of master data for which access is managed by the ABAC system, e.g. transactions, files, records,
tables, processes, programs or RFC’s.

In SAP object will be the same as master data such as sales order or person which is assigned its attributes upon creation (e.g., a sales
order contains information of cost center, which belongs to a company code, A plant maintenance order contains information of plant, A payroll posting documents contains information of personnel numbers and company code.)

In its most basic form, ABAC relies upon the evaluation of attributes of the user, attributes of the master data, and the formal relationship or access control rule or procedure defining the allowable operations for user-master data attributes combinations. All ABAC solutions
contain these basic core capabilities to evaluate attributes and enforce rules or relationships between those attributes (see Figure 3).

Each time a new person is created or changed; these master data attributes must be captured. These master data attributes are often
embedded within existing procedure, but they may be captured in separate tables, incorporated by reference, or managed by a manual application. From a SAP perspective those attributes you select should be embedded in existing maintenance procedures which is already implemented and stable in production.  If the user attributes are picked up from SAP HCM they will normally be assigned and managed by the HR department/ service center who is responsible for the employee’s master data in the ERP system.

As time goes by, new users arrive, old users leave, and characteristics of users change, and the user attributes may need to be updated. This indicate that you must select attributes, which already is embedded in existing maintenance procedures and which is vital for major business processes in the organisation. The reason for this is based on the logic that vital processes rely on updated master data.

3.1.4      Rule creation

  The master data owner or process owner creates access control rules, which use attributes of subjects (the user who which to access
certain master data) and the object (those master data a user which to access) to manage the set of allowable transactions (example. Controllers can be found in a rule entry, which states that controllers from Denmark are allowed to display sales order, invoices and budgets belonging to a company code within EMEA).

All master data within the system must have at least one entry rule that defines the access mechanisms for users through transactions to these master data.

The rules that bind user and master data attributes specifies privileges (i.e., which users can perform which operations on which master data).
Allowable operation rules can be expressed through many forms and complexity such as:

• An array combination of attributes and conditions that satisfy the authorization for a specific transaction or master data.

• A set of relations associating user and master data attributes and allowable transactions.

Once master data attributes, user attributes, and policies are established, master data can be protected using ABAC. Access control mechanisms mediate access to the master data by limiting access to allowable operations by allowable users.

Example: For a HR partner, a rule states that he/she is only allowed access to employees within the personnel area, which the HR partner himself is assigned. If the HR partner tries to access employees with a different personnel area they will be denied access. Note that this is only one approach to implementing the connection between attributes and rules.

3.1.5       Attributes & Rule Set maintenance.

Attributes and their values may then be modified throughout the lifecycle of subjects and master data without modifying each and every subject/master data relationship, needing to update the rule sets, or modifying access lists.

This provides a dynamic access control and limits maintenance requirements of access control, as access decisions can change between requests when attribute values on users and master data change.

As new users join the organization, decision rules and master data does not need to be modified. As long as the users are assigned the
attributes necessary for access determination to the required master data, no modifications to existing rules or master data attributes are required.

If the master data used as attributes are changed you will need to modify your rule sets. This will be the same operation you will need to handle in the organisational levels though the PFCG “the role generator” in SAP today.

3.1.6      Operation

An operation is the execution of a transaction at the request of a user upon an object. Operations include modes like read, write, edit, delete, copy, execute, and modify.

The ABAC definition is depicted in Figure 3 where the ABAC ACM receives the user’s access request. The ACM then examines the user’s request to access transactions/ master data based on the attributes of the object/ subject against a specific procedure. The ACM then determines what operations the user may perform upon the requested master data.

Figure 4 ABAC Access Control Model.

3.2     Analysis and forecasts regarding ABAC.

ABAC is endorsed by NIST (The National Institute of Technology and Standards) as the best approach for handling complex and large access control needs because of its design.

Gartner group has in their analysis: Predicts 2014: Identity and Access Management - 26 November 2013: “By 2020, 70% of enterprises will use attribute-based access control (ABAC) as the dominant mechanism to protect critical assets, up from less than 5% today.” This will require a large changeover in access control mechanisms for companies in the following years.

4.       ABAC considerations.

Everybody wants to have consistent access control mechanisms across the enterprise, but to get there you need to do the big picture architectural thinking. However you also need to start with the particular: This means understanding control requirements from a business context.

4.1     The complexity and globalization

Companies are being more and more global and specialized. They have outsourced their production to Asia; have service centers in central Europe and customers in north and south America. All these agent interacts together and have different information needs. To handle all these interactions on a global basis you need an efficient access control mechanism in operation.

4.1.1 Existing issues with role based access control.

Administrators and supporters have noted that this approach to access control is often time consuming to manage given the need to associate roles directly to users or through reference users. The support need and complexity grows with the size of the company. It is also an issue that the requester and role administrators are often not aligned with the real-world access control policies.

4.2     ABAC –the dynamic business control mechanism.

ABAC grants users access based on characteristics of the users own attributes from SAP HCM/ AD and those rules which are entered on behalf of the company’s security procedure.

ABAC is a logical access control model, which is dynamical because it controls access to master data/ transactions by evaluating rules against the attributes of the user and object relevant to the request. In its most basic form, ABAC relies upon the evaluation of attributes of the user; attributes of the master data, and a formal relationship or access control rule defining the allowable transactions for user-master data interactions. All ABAC solutions contain these basic core capabilities to evaluate attributes and enforce rules for granting users access.

4.3     ABAC and complexity

ABAC makes sense in global set up where systems can be implemented to satisfy the requirements of multidimensional security models that fully leverage the flexibility of ABAC. The complexity in the organisations will however not disappear from your access control model. In ABAC you must keep a very structured eye on your rule sets otherwise you will swap the role explosions with explosions of entries in the rule set. ABAC allows an unlimited number of attributes on the user and master data to be accessed to be combined for each user to satisfy a high grained access control based on rules and policies. In a normal master derived set up from SAP’s PFCG role generator you will in large complex organisations see role explosions as a result.

Your selection criteria or attributes must be supported by the existence of master data, if your master data is not correct the access control will suffer, but this is an issue which is relevant for both RBAC and ABAC methods.

5.       Access Control definitions

To understand ABAC we must have a clear understanding of the basic principles of logical access control. The purpose of logical access control is to protect master data such as sales order, invoices, and budgets from unauthorized access. The master data are owned by a user or organization and have value that motivates their users to protect them.

As master data owners you have the authority to establish procedures that describe what must be performed upon the master data, by whom, and in which context the subjects/ users may access the master data.

If the user satisfies the access control procedures established by the master data owner, then the user is authorized to perform the wanted transactions. If the user does not satisfy the procedure, then he/she is denied access to the master data.

Security architects and administrators install access control mechanisms (ACM) to protect their master data by facilitating requests from users. These ACMs can use a variety of methods to enforce the access control procedure that applies master data.

5.1     The downfall of RBAC and rise of ABAC.

In many AC systems, logical access control solutions have been based primarily on the identity of a user requesting access to a transaction to read master data (e.g., a payroll posting file). Examples include RBAC where access to master data has been granted to an identified user through a derived role, or access to master data has been granted to the user with a local defined roles.

This approach to AC is often clumsy to manage. In this role based access method (illustrated below in Figure 5), authorized access to master data outside of the user’s own organization would require the user to be assigned additional access in the target organization and approvedaccess by this organisation.

Figure 5: Organization B provisions a user from organisation A access on front of user A’s access to Organisation B’s resources.

Additionally the user qualifiers, such as identity and roles, are often insufficient in the expression of real-world AC needs. RBAC makes a decision based on the user’s association with a role. RBAC does not easily support multi-factor decisions (for example, decisions dependent on physical location, specialized training, task assignments or job description.

RBAC role assignments tend to be based upon more static organizational positions, presenting challenges in certain RBAC architectures where dynamic access control decisions are required. Trying to implement these kinds of access control decisions would require the creation of numerous roles that are ad hoc and limited in membership, leading to what is often termed “role explosion”.  The explosion of roles will increase the time & cost in all steps related to the access control. See figure 6 below.

Figure 6 Cost accumulations on access controls.

A method is needed to make AC decisions without previous knowledge of the master data associated with the user or knowledge of the user associated with the master data owner. By relying upon the concepts of user and master data attributes used in SAP, ABAC avoids the need for explicit authorizations to be directly assigned to individual users prior to a request to perform a transaction on the master data.

Moreover, the ABAC model enables flexibility in a large enterprise where management of ACL’s or RBAC would be time consuming and complex.

Keeping master data for ABAC attributes which covers both users and object data up to date will secure authorization activities can be supported in SAP, while maintaining appropriate levels of security is maintained through the rule sets.

5.2     Size have an impact.

The use of RBAC is still a really useful principle especially for organisations who is small and where the complexity can be handled with new created roles which fit's with the need for changes. Globalization also have an impact on the need for swapping RBAC with ABAC. To set up a ABAC rule set for a small sized company who is operating in a couple of countries would properly not be efficient compared to using a classic set up with the role generator with the use of master - derived role concept. Even the organisational functional set up only make sense when you have large organisations. see figure 1 & 2.

6.       TORC: The OneRoleConcept for HCM based on ABAC.

TORC  The OneRoleConcept is a hybrid between RBAC and ABAC used in HCM for securing access control. TORC the OneRoleConcept is based on global business roles, an ABAC based global rule set, which grants access based on the attributes on subject and object and the relations defined in the rule set.

6.1     The business roles

The business role for TORC is based on the existing role generator within PFCG and is linked with the ABAC rule set through the structural authorizations. The structural authorizations read the rule set instead of the organisational structure and delivers those persons an employee is allowed to access within the respective business role.

The rule set takes into consideration the attributes of the subject as well as the object.

Figure 7 TORC: The OneRoleConcept is based on ABAC.

6.1     TORC is within SAP standard.

The OneRoleConcept can co-exist together with existing solutions so you have the option of using master derived, enabler or organisational and functional access mechanisms within some business roles and ABAC on others. It also gives the flexibility of phased roll outs instead of big bangs. The OneRoleConcept can use functional/ organisational roles as well as single business roles and the most common set up with master/ derived roles.

The OneRoleConcept will not make changes to SAP standard but uses those exits and configuration options, which is delivered from SAP. Remember to create your own function modules and reports so they can be used so they are not violating SAP standard.

Figure 8: Example of the OneRoleConcept.

6.2     TORC is a hybrid since it only uses ABAC for the content determination.

TORC is a hybrid since it uses the existing RBAC principles for roles in SAP’s PFCG and then uses the ABAC principle for content. In other words: “what I can do” is dictated by roles and “where I can do it” is determined through an ABAC rule set.

A demonstration of TORC can be found on our site here The SAP HCM Authorization concept: The OneRoleConcept

TORC actual removes the set up of the organisational levels from the derived roles to a ABAC rule set table which is why the OneRoleConcept can reuse the same business roles for different regions and service centers. This principle reduces the number of roles with a number of segregation dimensions which otherwise is used in the organisational levels.

6.2     ABAC based solutions must be true to SAP standard

The OneRoleConcept is created so it reuses the context based authorization objects made available for SAP HCM. By remaning true to the standard authorization objects we have kept all the standard tools for authorizations fully operational such as ST01 the trace, HRAUTh the HRauthorization workbench and the transaction SU53. If these tools are out of function any solution will fail.

Another important rule of thump for a new ABAC based solution in SAP will be to remain with SAP standard. The solutions must seek to reuse the existing authorization objects instead of creating new ones. The OneRoleConcept only uses the existing authorization objects from HCM such as P_ORGINCON, P_PERNR, PLOG and P_HAP_DOC. It will be interesting to see how others have solved it for finance and logistic.

7.       SAP’s ability to use ABAC

There is no specific SAP solution for ABAC in ERP. The solutions available are from partners who have developed solutions within SAP standard. Today we have ABAC principles used e.g. for content such as granting managers access for employees through the attribute A012 “manager of” or other dynamic structural profiles. The profile generator which is the tool everybody is using for generating authorizations in SAP is for generating roles. You can choose to create full business roles or functional roles, which consist of display and maintain parts.

7.1     Indirect role assignment is using the org structure as attributes

SAP have different forms for assigning roles indirectly from the organisational structure. There might be some who back in the late 90's tried to assign roles and profiles through the OM infotype's 1016 and 1017 and then assigned through report RHPROFIL0

The last indirect assignment set-up was based on roles which was linked to objects such as organisational units, jobs and positions. To automate the induction process you will have to use the attributes registered on the employees. All you need is to use the organisational assignment of your employees, such as personnel area ”site” , employee subgroup ”salaried or hourly employee”, Job assigned to employees position ”such as controller” or ”secretary” Screen shoot where user is inheriting the SAP role from the organisational structure in HCM. This assignment is granting the user access and will also secure the system to stay clean since the user will get the role removed when he or she moves away from the position within the organisation.

Figur 8. Indirectly assignment of SAP roles. Another hybrid solution.

The advantage of using the most common dimensions on the employee is because they are more reliable than dimensions, which is created for identity management only. If you as security organisation can get to a mutual agreement with the HR function how the global job catalog should be structured so it is for the benefit of both competence development and for user administration.

The use of the attributes from the organisational structure is also an ABAC way of provisioning access to the users. It is not a 100% ABAC way, since it is dependent on the roles, which has been created prior to you can assigning them in the organisational structure.

SAP is during a transition to cloud based solutions, which is founding their future security on XACML. In this transition there are many new options which must be investigated.