In my experience with SAP ERP HCM implementations, security gets a bad rap, or no rap at all, which is actually worse. Security in SAP ERP HCM is complex, and it’s not pretty. After years of experience with implementing numerous SAP ERP HCM modules and functionalities, I had the opportunity to implement structural authorizations and apply the practice for multiple clients. With this experience has come an understanding of the complexities and nuances of HR security, and I developed a new appreciation for the importance of HR security not only to IT, but also vis-à-vis HR.

SAP ERP HCM security experts are hard to come by. Even rarer are ones who actually understand the HR data that is being secured. I often see security playing catch-up during SAP ERP HCM implementations; too often it is an afterthought to the core functionality that takes all the attention. It’s not until auditors get involved, security gaffes are realized, or users miss critical deadlines that SAP ERP HCM security strategy gets the attention it deserves.

IT security strategy in general is a hot topic these days. HR security strategy needs to come more into focus as well for companies using SAP ERP HCM systems. Oftentimes, users who have experience with SAP ERP HCM and who have built security roles up over time overlook the importance of building a good HR security strategy. While IT should — and does — drive HR in determining the implementation strategy, it is not IT’s role to define the organization’s strategy for securing HR data — these should be driven by HR as HR is the owner of the data. The HR department and the organization should work alongside the IT department to align SAP ERP HCM security to the organization and not just rely on IT to figure it out. Structural authorizations, in addition to position-based security in SAP, allow for just this type of strategy; one that is driven by the HR organization and how it is structured.

What Are Structural Authorizations?

Structural authorizations in SAP introduce the concept of applying pieces of an organization’s structure in granting access to SAP ERP HCM data. There are two main authorization objects in HR data access: P_ORGIN and PLOG. These authorization objects grant access to personnel infotypes (P_ORGIN) and organizational management objects and infotypes (PLOG) with a limited number of criteria around them. This combination of P_ORGIN and PLOG access is commonly referred to as a general profile.

Structural authorizations use the concept of structural profiles that combine with general profiles to grant HR access to end users. I dive into the technical details for doing this later in this article. It is this overlap of common objects between these two profiles that results in access being granted to a user. Structural profiles allow you to get creative with authorizations, providing numerous ways to fill profiles with various parts of the organizational structure, statically or dynamically, based on the individual user. Combined with general profiles, this provides for more robust security capabilities.

Why Structural Authorizations?

Traditional role-based security in SAP ERP HCM is fraught with peril. Maybe I’m being a little dramatic, but I’ve seen, first-hand, some of the problems that can arise. Here are some example scenarios you might encounter (and, as you look at them, think about how you might accomplish these via normal role-based security):

• Managers needing access to certain HR data for reporting employees only (those employees cannot be grouped together in unique personnel areas, employee groups, or subgroups).
• Certain areas of your course catalog or qualification catalog that are sensitive and need to be available only to certain types of users (e.g., specific leadership competencies that are only for senior managers or online courses in the course catalog that are offered only to certain types of employees — these offerings should be viewable only for the approved employee group).
• Performance appraisals need to be managed by HR administrators who should have access to only certain groups of people for performance management purposes, but need broader personnel access in other areas of SAP ERP HCM

You’re not going to be able to accomplish the above tasks with standard role-based security; it’s just not that flexible. However, with structural authorizations, the options for solving challenging security scenarios like these examples are plentiful.

Even with these examples, perhaps the best argument for using structural authorizations is its impact on the bottom line. When I use the terms “more robust” and “more flexible,” the natural inclination may be to think they are more complex and costly as well. Although this can sometimes be a fair assumption, in this case it is incorrect.

Any business with a robust SAP ERP HCM landscape knows the administrative effort that comes with HR security. Structural authorizations, along with a position-based security strategy, can greatly reduce this effort. I go into more detail about how to do this later in this article. Security admins can tell you how challenging it is to manage access for people as they proceed through the employment life cycle within an organization. From hire to position changes, to termination, traditional role-based security in SAP requires security admins to manually adjust role assignments to users, run periodic audits, and do other typical security functions.

 It’s common to have security admins that perform only this function on a day-to-day basis, or at the very least spend several hours a day doing this type of work. If a company incorporates a security strategy using position-based security and inheritance from the org structure, this administration time can be greatly reduced, if not eliminated altogether. Add up a few hours of admin time every day of the week for a year, and you can see how the savings add up.

Additionally, designing a proper HR security strategy with structural authorizations and position-based security in mind can result in simplification of the management of the actual security roles built and available in the system. I have seen companies with hundreds of security roles built solely for HR purposes. At some point it becomes easier for security admins to build new roles for new requests instead of modifying existing roles due to the sheer number and confusion that sets in. This can easily lead to granting inadvertent access to users. In my experience, with proper security design mirroring the HR org and job structures, this method can result in vast reductions in the number of roles the SAP ERP HCM system needs to access – as much as a 90 percent reduction. Fewer roles to manage leads to less administration effort required for changes and increased clarity in what roles are truly needed for what users and functions.

To summarize, structural authorizations and position-based security provide benefits of flexibility, additional security, and time and cost savings. Figure 1 summarizes what I call “The Big Three” of structural authorizations.

Figure 1

Summary of three structural authorizations

Implementing Structural Authorizations

Once you decide to take SAP ERP HCM security to the next level and implement structural authorizations, where do you begin?

Before you dive into designing your new security strategy and configuring and building structural authorizations, ask yourself these questions:

• What types of HR functions are performed in my organization (i.e., payroll, manager, or trainer)?
• Who should the HR functions be performed on within your organization (i.e., the entire population, subordinate reporting employees, specific departments or positions, or specific parts of the qualification or course catalogs)?
• Is there anyone — or any role — in my company that performs more than one of these functions?

The last question is important. If you answer yes, you have one more aspect of structural authorizations to understand before diving into an implementation.

Understanding the Context-Sensitive Approach to Structural Authorizations

Earlier, I discussed the combination of a general profile and a structural profile. It is this combination that gives a user access to HR data with structural authorizations. However, what does this mean if you have users who need to perform different functions for different sets of people or objects in HR? For example, what about a typical manager who needs access to subordinates as it relates to Organizational Management and pay and time information?

Now think of managers in the benefits department of your organization who need access to certain personnel and organizational data for all employees in the organization. In context, on the one hand these managers need access to specific data for their own people only, while on the other hand, they need access to other data for all employees in the organization. With the collaborative functionality of structural authorizations, access that should be more restrictive in one context for a user can be overwritten by the other authorization for the user involving a broader context. In my benefits manager example, the broader access for benefits information for the entire organization would overlap the more restricted access required for subordinates in regards to time and pay information, potentially providing access to time and pay data for the entire organization instead of the limited subordinate view.

This is where the concept of context-sensitive structural authorizations comes into play. This functionality within structural authorizations expands on the basic workings of structural authorizations by allowing you to specify precise structural profiles to specific authorization objects (P_ORGINCON replacing P_ORGIN, for example). With context-sensitive structural authorizations, you can specify certain access for particular people in your organizational structure while keeping other access separate, and also applicable to other profiles. Using the benefits department manager example from above, context-sensitive structural authorizations can be used to grant the appropriate access (Figure 2).

Figure 2

Diagram of how to use context-sensitive structural authorizations

Proper HR Security Strategy (Position-Based Security)

While structural authorizations in SAP systems provide a more flexible and more secure landscape within SAP ERP HCM, structural authorizations in and of themselves are not an HR security strategy. A proper HR security strategy involves the design and administration of the security in addition to the application of the security. Effective HR security design is a challenge in many ever-changing organizations. HR itself should drive the design of HR security, not IT.

The first step is to analyze your HR structure in your SAP system. Familiarize yourself with the organizational structure and job catalog. Before implementing structural authorizations, ask yourself: How does HR define jobs or positions? Define what HR-related functions are performed in your organization and, using your job catalog as a starting point, move down to positions where necessary. Then define on paper what HR functions are needed in your organization. These should be your starting point for defining any security roles you create.

While there is no optimal organization structure for every company, you should focus on the quality of your job catalog and model your security around it as much as possible. A job catalog should not be so broad that you have people sitting on the same job that perform different job duties and functions. It should also not be so specific that you have almost as many jobs as positions. If job catalogs are defined appropriately, security can then be assigned at the job level, which results in fewer assignments and easier maintenance.

The second question to ask is: What profiles do each of these functions need in order to function properly for end users? In other words, the profiles define whom these functions should operate around. This combination of what each HR function performs along with for whom each function should be performed provides the blueprint to build SAP ERP HCM security roles using structural authorizations (Figure 3). To be concise, the structural profile provides the who and the security roles themselves provide the what.

Figure 3

Example of defined HR functions (who has access and what they have access to)

After appropriately designing your SAP ERP HCM security around your HR organization, placing particular emphasis on the defined job functions or catalog from HR, the development required to build proper SAP ERP HCM security and structural authorizations becomes clearer. The result is a more efficient and effective security landscape for the future.

Getting Down to It – Critical Setup and Configuration Steps for Structural Authorizations

So what is involved in setting up structural authorizations? What are the challenges and key elements of which to be aware? Structural authorizations are not the easiest thing to implement in SAP, but following the steps below puts you on the right path for implementing the solution in your HR landscape.

Step 1. Use New Authorization Objects (Context Sensitive)

If you decide to implement context-sensitive structural authorizations, instead of P_ORGIN you have to use different authorization objects. The traditional P_ORGIN authorization object is replaced by P_ORGINCON or P_ORGINXXCON (Figure 4). The only difference in these new authorization objects is the addition of a new authorization field (PROFL) for the assignment of structural profiles to specific authorization objects. This is unique to context-sensitive structural authorizations, for which the system allows you to directly relate specific authorization objects to specific structural profiles.

Figure 4

Additional PROFL field introduced in P_ORGINCON authorization object

Step 2. Set Switches for Structural Authorizations

Various switches are used to activate and set up critical aspects of structural authorizations. These switches can be maintained in table T77S0 (transaction code OOAC). Table 1 provides details on important switches for structural authorizations.

Table 1

Details of important structural authorization switches

Keep in mind transaction HRAUTH, which is a tool for analyzing your authorization environment. Here you can get a snapshot of authorization switch settings described in this step, in addition to further information on authorization specific Business Add-Ins (BAdIs) and their status, structural profile entries, and index reports. This transaction can also allow you to analyze authorizations for specific users. More detail can be found on this tool at the link: https://wiki.sdn.sap.com/wiki/display/ERPHCM/Transactions+and+Reports+for+checking+HR+authorizations

Step 3. Define Structural Profiles

After activating and setting the applicable switches for structural authorizations, you must define your structural profiles. Since, at this point, you should have already created an HR security design, these profiles should be defined on paper regarding what pieces of the organizational structure each profile should return. Structural profiles are defined in table T77PR (transaction code OOSP). A profile can have numerous steps that return various organizational objects.

The most important parts of a structural profile are the root object and the evaluation path. The root object defines the starting point (HR object) for a step in a structural profile (statically defined, like a specific org unit, or dynamically determined by a function module specified within the structural profile). The evaluation path assigned to this step is used to evaluate the organizational structure from the root object, and return the objects defined from the evaluation path. Structural profiles can be used to return objects in a variety of ways, including the following:

• No root object, no evaluation path – Returns defined object type only
  • General access allowed for all objects of specified object type
• Defined root object, no evaluation path – Returns root object only
  • Access allowed for specific object only
• Defined root object, defined evaluation path – Returns multiple objects
  • Access allowed for objects returned along evaluation path
• Dynamically defined root object, defined evaluation path – Returns multiple objects
  • Access allowed for objects returned along evaluation path; the root object is determined dynamically from the function module (I explain more about function modules in the next step)

The detailed elements used to define structural profiles are provided in Table 2.

Table 2

Elements for defining structural profiles

When creating your structural profiles, apply a naming convention that your organization can use to simplify the understanding for individuals looking at the profiles across your security and SAP HR support. While there is no recommendation for an optimal number of profiles, it is common to see a manageable set of around 10–20 profiles depending on the size and complexity of your organization. Remember, the profiles should map from your design of whom your HR functions should operate around.

Step 4. Use Function Modules for Dynamic Root Determinations

As mentioned in the prior step, function modules can be used within the definition of structural profiles to dynamically return root objects for evaluation. This is particularly useful when structural profiles need to return different objects depending on the user in question. Two standard function modules are available from SAP (RH_GET_MANAGER_ASSIGNMENT and RH_GET_ORG_ASSIGNMENT) that can be used to return organizational units by chief assignment or general assignment. You can define your own function modules as needed and utilize them in your structural profiles as well. Function modules do not have to just return one single root object. A function module can return many root objects, which can then be further evaluated by a defined evaluation path, or the structural profile can return the root objects from the function module only if no evaluation path is defined.

Step 5. Assign Profiles and Security Roles to Organizational Objects

Once your structural profiles are defined, users must be assigned profiles as needed. Structural profile assignments are assigned to user IDs in table T77UA. While you could maintain these directly in table T77UA, this is not desired as it does not help ease any administration efforts on the part of your SAP system security team. Instead, if you did your due diligence when designing an appropriate HR security strategy based on your HR organization, in your blueprinting process you should have identified organizational objects (such as organizational units, jobs, and positions) that perform HR functions, and what profiles each function requires to operate correctly. Once this is done, you are ready to assign your structural profiles and security roles to these organizational objects according to your HR security design.

These assignments can be made to organizational units, jobs, and positions via infotype 1017 (personnel development profiles). Structural profiles can be flagged on these infotypes for exclusion if, instead of granting authorization to a user for objects returned by a specific profile, you wish to exclude access from the user for these objects. In your previous design exercises, defining what HR functions are required in your organization, those functions belong to various org objects (jobs and positions), thus these org objects should be assigned the appropriate structural profiles. Use this information from your design to properly assign structural profiles accordingly to org objects.

Alternatively, structural profiles can be assigned to users via a BAdI (HRBAS00_GET_PROFL) that can look at the role assignments a user has and the structural profiles these roles require, thereby assigning these profiles to the user automatically based on his or her assigned roles. Implementing this BAdI removes the requirement to maintain structural profile assignments via infotype 1017 and table T77UA to users, which can be a plus from an administration standpoint. However, this means that when users are assigned security roles, the users automatically gets the structural profile assigned to them as well, completing the access.

In my opinion, assigning security roles and profiles separately allows for a better segregation of duties. It is common to see security roles assigned to users incorrectly. If this is done while requiring structural profiles to be assigned separately, potential security gaffes can be avoided as the missing structural profile assignment prevent the access from working. Be aware of these pros and cons for your organization when determining how to assign structural profiles to your users, whether via the organizational structure or using this BAdI.

To further automate security administration, your defined security roles can also be assigned to organizational objects per your HR security design. Instead of the traditional direct user ID assignment of security roles, this practice allows for security to be assigned within your organizational structure and inherit to appropriate users in real time. This means that no more security administration is needed to grant or remove access as people move within the structure (a major plus for security administrators).

Security roles can be assigned to organizational units, jobs, and positions via infotype 1001 (relations), using relation A/B 007 (describes). This relationship between security roles and objects like org units, jobs, and positions is a standard allowed relationship via table T777E, so no extra configuration is needed here. Ensure that your defined security roles (using the new authorization objects and structural profile assignments for context-sensitive authorizations, if applicable) are assigned to the correct organizational objects.

Step 6. Run SAP System Standard Programs

Now that your security roles are built, your structural profiles are defined, and both are assigned to the correct organizational objects in your structure, the final step before the authorizations take effect is to perform the inheritance of these roles or profile assignments to user IDs. The inheritance of profiles is accomplished via standard SAP program RHPROFL0. Schedule this program to run in background daily. The program maintains user ID and profile assignments in table T77UA.

Transaction code PFUD, which is used commonly in security to manage role assignments to user IDs, manages the inheritance of security role assignments to user IDs from inheritance in the organizational structure. When running this program, ensure that the HR Organizational Management: Reconciliation check box is selected (Figure 5). This program should be set up to run daily as well.

Figure 5

Running program RHPROFL0

Step 7. Perform Indexing to Ensure Efficient System Performance

Structural authorizations come with one word of caution, especially in the use of context-sensitive structural authorizations. If you have many users with structural profile assignments, and users who have profiles that return large numbers of objects for access from their assigned structural profiles, this can result in system performance issues. This is due to the system’s need to constantly evaluate the objects from a user’s structural profiles and determine appropriate access. With a large number of users or objects, processing time can increase and lead to performance issues.

Indexing is a standard process provided in the SAP system to accommodate for these situations and index user profiles or objects for quicker access when security is evaluated. The steps below can be followed for successful indexing:

1. Run program RHBAUS02 to analyze user population and place a certain level of assigned objects in table T77UU.
2. Run program RHBAUS00 to index users in table T77UU (this can be run for the entire population of a table or specific individuals).
3. Run program RHBAUS01 periodically to clean up previously indexed users that are no longer in table T77UU.

If you have a large number of users that need indexing, it is recommended that you break the indexing job up around these users as issues can occur in the running of the indexing program for large groups of employees. Break up the job into multiple runs of the program for smaller groups of employees, staggering the jobs to not run concurrently. This helps ensure that the indexing jobs run in an appropriate amount of time and don’t create issues with jobs overlapping each other while modifying indexing information.

Eric Wood

Eric Wood is an SAP ERP HCM/SuccessFactors Solution Architect at Presence of IT.  He has 11 years of experience in corporate and consulting roles, focused on the strategy and development of HRIS solutions, specifically SAP ERP HCM. Eric has worked across a range of HR modules, both on-premise and in the cloud, for clients across various industries while based in the United States and Australia.  Eric is also a frequent conference speaker at SAP conferences in the U.S., Europe, Australia, and Singapore.

You may contact the author at eric.wood@presenceofit.com.au.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.