BeyeNETWORK - The Global Vision for BI and Beyond

SAP R/3 Security

Would You Like Roles With That Logon?

Published: January 11, 2007

This article is the first in a two-part series regarding SAP R/3 security. This discussion is an overview of R/3 security concepts – its history and implications. In later discussions, we will look at the latest SAP security initiatives.

System-wide security is a key asset of your organization; therefore, it is paramount to develop company-wide security policies and procedures covering all aspects within your distributed data infrastructure.

In this article, we will look at the elements of SAP R/3 security – their history and concepts. In the last article of this series, we will examine where SAP security is headed in the near future. 

Knowledge learned in this article can be put to use when:

• Executives desire an understanding of SAP R/3 security concepts.
• Users require an understanding of the various methods used in establishing SAP R/3 security.

Why the Focus on Security?
Today, the convergence of the Internet within distributed enterprise resource planning (ERP) systems is ever increasing the demands on data and business process security almost exponentially. Organizations which employ distributed business processes and data systems require surety of both data and its accompanied processes – promising continued support of essential business needs whilst mitigating unauthorized access to critical information. This surety is demanded not only within the organization: clients and vendors alike require their shared data be protected as well – and not just from outside threats, but from inadvertent or deliberate access from within an organization.

Therefore, responsible organizations cannot afford user errors, negligence or attempted manipulation of their ERP systems leading to the loss of information or business process responsiveness. This is especially true with the introduction of Sarbanes-Oxley and other federally mandated policies and procedures – many having direct (read: potential fines and/or jail time) responsibility tied to the efficacious employment of recognized security measures.

As has been demonstrated on the world stage in recent years, security cannot be considered a single entity – it must consist of logical “layers,” with each layer reinforcing the other. Therefore, the security of any complex system will reside upon a number of interlaced factors:

• the operating system
• network landscape
• security and authorization plans
• communication protocols, etc.

Let’s look closer at how SAP R/3 security has evolved.

From Simple User Logons to Activity Groups
Every SAP R/3 user logs onto the system with these three elements: their user name, R/3 client and their password. It is via your user name and client that you are recognized and granted access and, hence, further access to transactions, etc.

SAP R/3’s security concept is very simple; it is security by permission (or exclusion). This means users initially have zero accessibility – you can’t do anything beyond logging on – until authorities are granted for specific transactions, tasks, etc. In other words, you must be granted permission to do something; otherwise it is not allowed. This concept permits locking down all procedures – except to those who must have access.

However, because SAP R/3 exists within a 3-tier system (and must remain database vendor agnostic), SAP had other considerations to address. For example, even in the 2.0 and early 3.1x days, SAP R/3’s conceptual approach to security required it to address protecting not just access to the application, but access and control over transactions and programs – protecting the system and its underlying data to unauthorized use and access.

Figure 1 shows an illustration of a simple transaction: a single business task or process. Transactions usually contain several screens – with the user selecting which path they need to take to complete the task.

Figure 1

This was especially true within R/3. Being an event-driven process chain application, each link of a transaction required completion and satisfaction of specific business rules. Otherwise, the user could not progress to the next process link (typically a new screen) of the transactional chain.

Therefore, the concept of R/3 authorization/security is based upon logical relationships – the User_ID and the various system authorizations it is configured around. As with most applications, the User_ID is the first step into the process of “authorization.” So, before you can progress from one screen to another, R/3 does an authorization check on the field data was either entered in or requested from.

Figure 2

A brief explanation of Figure 2: The SAP authorization concept is a combination of User_ID and various R/3 system permissions; included are profiles, objects, fields and authorizations. User_ID is directly linked to profiles – with a profile associated to specific access criteria (using complex, multi-conditional, algorithms) via the path on the right (authorization objects). These algorithms act as user tests for the access, creation and displaying of data.

Furthermore, several profiles can be concatenated into preset profiles known as composite profiles. Let’s investigate some of the other items listed in Figure 2.

User Profiles
User profiles match a user to their job function – so an accounts receivable clerk requires access to specific authorization objects enabling him or her to process the tasks required for his or her job. Standard profiles are supplied by SAP to expedite this process – in fact, SAP provides hundreds of standard profiles for many typical SAP profiles – from simple one-task jobs to multitask positions. Changing the content of a profile (the authorizations) will affect all users using that profile (it takes effect the next time the user logs on).

Composite Profiles
As the name implies, composite profiles are profiles consisting of one or more profiles – and the number of profiles is limitless. Typically, composite profiles are used for individuals who have eclectic jobs or tasks. At one time, a term in use was reference profiles – you would assign a reference profile to a large group of individuals having similar tasks or job responsibilities (such as data entry clerks, account payable clerks, etc). This was a quick and easy way to make mass changes (editing a composite profile will effect a change to all those who use that profile).

Authorizations
An authorization is how a user is permitted to perform a specific task or activity. This information is stored within the user master record tables. Permissions may be set manually or automatically (via the profile generator). The latter is the preferred method; the profile generator does not require intimate knowledge of available profiles and interdependencies.

Authorization Objects
First of all, what is an object?

A commonly employed explanation is: “An object is a logical entity used to group one or more related fields requiring authority checking within the system. Objects themselves contain no values; instead, the fields contain values for authority checking and the combination of field values for an object constitutes an authorization. Therefore, a profile references any number of authorizations that in themselves define the system resources that can be accessed. Every object and profile must be uniquely named. Authorizations, however, can be identically named but must hold different values for their constituent fields.”

Table TOBJ holds the information on authorization objects – listing the object name and associated field name. Authorization checking occurs when a user requests access to a particular transaction or process. A specific subroutine uses the ABAP function statement authorization check to check the user’s credentials against the request; if the values match, the user is permitted access.

Therefore, an authorization object is essentially a template granting access via the authorization fields (where the complex authorization checks are performed). Before a user can be granted access, all the fields within the object must be validated (as many as 10 fields are permitted within an object).

Figure 3

Authorization Fields
Within SAP R/3, transactional (or process) security is maintained within the authorization fields – within the fields authorization checking occurs. Examples of authorization fields include: company codes, sales distribution groups, user groups, activity, application areas and development classes.

Let’s expand upon two of those fields; activity and development classes. The activity field is a common field found within most authorization objects, and is used for the task “display” (with the associated visible code of 03). These elements are used to verify an activity – as an example, if the development classes field was given the visible code of “ * ” (the wild-card for all), the user would have permission to see (via display) all development classes. Once an authorization profile is created, it must be generated before it can be assigned to a user. An authorization will be generated for each authorization level within the browser view – together with an authorization profile for the entire role (as represented in the browser view).

The relationship between authorization objects and activities is stored within the table TACTZ. The associated table TACT lists the standardized list of activities. Figure 4 shows the two tables (from a 4.6D System).

Figure 4

Back to the Beginning
Although the employment of user master records was not a new concept, the total integration of the authorization process across the enterprise was. This meant that a user signing onto SAP R/3 had permissions for a host of business process transactions – permitting them to access (reading and writing to) the underlying data whilst progressing through a series of interleaved business processes – and all in real time (the “R” in R/3). Real-time authority checks was a very advanced concept – meaning, while the user was using the system, the system was constantly authorizing and re-authorizing the user’s credentials – giving access to and restricting access from each step of the process chain.

Figure 5 shows another look at the SAP authorization concept – with all the pieces included.

Figure 5

Groups
As SAP added additional functional areas (HR, CO, etc.), they saw the need to implement the concept of “groups” – meaning users performing similar tasks by “job category/association” and subcategory.

Employing groups by themselves did serve their purpose; for a time. But a key concept was missing – inheritance – something taken for granted today. What we are speaking of is known as “authority inheritance” or “permissions inheritance” – this means belonging to a subgroup permits the user to inherit the authorities of the parent or main group.

The natural outgrowth was to cluster profiles and groups into common tasks – this was accomplished via activity groups. This was a requirement to use the automated profile and role setting feature, the profile generator (more later…).

Activity Groups
Activity groups are just that, a grouping of activities (or tasks) a user has authorization to access and/or perform. This was a step away from simple groups and into the concept of role-based security.

Examples of activity groups might include jobs of system administrators, accounts payable clerks, sales managers, etc. Activities would include job-related transactions, reports, programs, etc. Even more specifically, activity groups are assigned to organizational objects. These include jobs, positions, organizational units, users, etc. Users within the user master may be assigned to one or more activity groups (and when an activity group contains more than 150 authorizations, a new profile is created).

With a user now categorized via activity groups, it is natural to leverage this within the HR module. To accomplish this goal, the first step is to make activity groups (and hence, authorization profiles) date dependent – this means they have validity periods. (The HR module within SAP R/3 leverages the concept of validity period to a very great extent.) Activity groups can have multiple validity periods – but per the HR rules, they may not overlap.

Figure 6 shows how activity groups correlate to a user’s profile, etc.

Figure 6

Role-based Security Arrives on the Scene
Role-based access control (RBAC – also called role-based security) was a turning point in ERP applications. This simple concept took role-based security to the next logical step: What do users do -- why are they using the application and what do they need to accomplish within the application?

The concept may be simple – but putting it into practice was not. However, the possible payoffs more than outweighed the implementation issues the application developers faced. Role-based security has become the predominant model for advanced access control – due to its reduction of the overall complexity and cost of security administration within large networked applications.

Role-based security is a form of user-level security where the application doesn't focus on the individual user's identity, but rather on a logical role the user occupies. This can be implemented many ways. One way is to recognize groups and activity groups that represent the roles. The application can query these groups (through the authority check process) and make security decisions based on the group’s authorization object settings. For example, if access to a particular transaction is restricted to members of the HR admin role, a local group called HR_Admin can be created to represent that role.

What's most appealing about this simple role-based architecture to SAP security administrators and users alike is how it simplifies life for both – because a well-understood mechanism to implement security now exists.

Another benefit to role-based security is the adoption of security federation – organizations using SAP can integrate the SAP security scheme with their existing deployments and centralize the management of access to IT systems.

With this integrated solution, each user is represented by a unique digital identity and assigned access privileges to applications and systems based on his or her job role in the organization. Employees are able to easily and transparently access all systems and applications needed to support their job roles without having to worry about the underlying infrastructure.

The user’s privileges are centrally maintained and continuously updated to reflect changes in the organization, automatically communicated across all relevant systems and withdrawn immediately if necessary.

One of the first uses of role-based security was when SAP launched the EnjoySAP initiative (also known as SAP My Way).

Combined with a new Web-like look and functionality, it is still employed today – it’s now called the Easy Access Menu.

Figure 7

Looking at the how the EnjoySAP screen was designed, it brought early portal designs and access to R/3 end users; the left panel contained a list of user-accessible transactions, reports, etc. “Personalization is part of the three-step approach to making the user a VIP,” said Peter Barth, technology marketing manager at SAP in 2001. “First you give the user a visual interface, next you give them an interactive design and then you provide them with personalization features.”

The “interactive design” and “personalization features” meant role-based access control had come to ERP. Users could see and access only those tasks for which they held R/3 authorization.

When a user is assigned to an R/3 a role, he or she is automatically given the user menu required for his or her daily work (and the authorizations required for it). This menu is the user’s home page when he/she logs onto the SAP R/3 system.

Once logged on, users can define their personal favorites from the functions assigned to them. The user calls transactions, programs or Internet and intranet applications from the favorites or the job structure tree. As always, before a security administrator begins creating roles for their staff (for the job descriptions in your company), it’s always a best practice to check whether they can first leverage the predefined roles delivered with the SAP system (starting with “SAP_”).

Figure 8

Enter the Profile Generator
Today, a user’s profile may be created manually or automatically. The manual method is via the user maintenance transaction code (T/C) SU01. However, as SAP states: “As of SAP R/3 4.6C, we strongly recommend that you do not maintain authorizations and profiles manually. Instead, use roles and role maintenance functions to maintain your user authorization data.”

The profile generator was developed during release 3.0F and was released for general use in release 3.1G. This tool was developed to reduce the time and attention to detail required to accurately allocate new users the proper authorizations. The tool employs predefined activity groups to discern the tasks and responsibilities (if the proper activity group does not exist, it can be created within the tool as well).

Special check tables are employed to verify that all authorizations are accurate.

The manual method of assigning profiles uses the following screens:

Figure 9

Figure 10 is an example of the profile generator using the role of HR_Benefits_Manager:

Figure 10

Figure 11 illustrates the menus this profile may access (includes display and create):

Figure 11

Clicking on the authorization tab displays the various authorizations attached to this role (the pop-up box displays authorization field values).

Figure 12

The profile generator is only as effective as the administrator is at defining the user’s various jobs and tasks. Remember, it’s role-based.

As SAP further states: “With the profile generator, you must first define all job descriptions in the job description for your organization. You define the desired authorizations for each job description. These authorizations consist of fields that contain values. The authorization checks in SAP systems use these values to determine whether a user is authorized to perform certain actions. You can combine multiple authorizations in a profile. You can also create composite profiles. You assign to each user the profiles that he or she requires to perform his or her tasks.”

Using activity groups makes creating user profiles easy when using the profile generator. Once the activity group is selected or created, the profile generator automatically retrieves the necessary authorization objects for the selected transactions.

The user master record is updated (either immediately or via a batch job) – allowing the user to logon and access their permitted transactions, programs, etc.

SAP, like all current ERP applications, has evolved their security schemes from basic logons to groups to today’s role-based access control. SAP’s security is progressing into what is known as identity federation or identity management. A recent SAP announcement promised a global, strategic alliance delivering a standards-based identity management solution.

Today’s RBAC methodology is an easy-to-implement and maintain security scheme. Tomorrow’s security challenges are evolving into robust solutions designed to meet the needs of Web-based applications – especially those offering access to data from multiple environments.

Coming Up
What’s the next phase in SAP security?

If you found this article helpful and would like to receive the latest insights each week from the experts featured on the BeyeNETWORK, please subscribe to the Bill Inmon Newsletter.