Authorization means that users are authorized to access assigned roles and profiles. Put another way, granting and managing the permissions the user has is called authorization.
Authorization Design in SAP Systems
Authorization studies are often needed when companies are transforming into S/4HANA or when they feel they have unmanageable authorization structures. So how does this design begin?
First of all, the main factors that will affect authorization should be identified.
- Activity differences: Which user can do what? Who has permission to change and create? Who can only view it? Who won’t have permission?
- Organizational structure differences: In which location is the user working? What company code do they need to use?
- Duties and responsibilities: What are the hierarchy and task structures of the organization?
After discussing and determining the basic distinctions, the first thing that can be done in SAP systems is data analysis. According to the usage patterns and habits of the users, a model can be created by considering the accepted Separation of Duties (SoD) standards and IT risks.
Since establishing an authorization structure from scratch will be a very laborious, complex, and experience-requiring process, we believe that we can offer the best solutions for organizations that need authorization studies by taking reference from our ready-made authorization risks, rule sets, and past projects in the extensive Solvia RS Risk Library.
Role Design Concepts
1. Single Role Design and Role Derivation
Typically, the single role classified by tasks, responsibilities, or positions includes all the required transaction codes, authorization objects, and organizational or functional fields.
If a user has an additional task or responsibility, they will have more than one single role. For example, a salesperson needs to take action in one of the warehouse processes, and this request is approved by the role owner. In this case, the required warehouse role is assigned to the user, separately from the salesperson role. If the transaction codes in the warehouse-related role were included in the existing sales manager role, rather than in a separate role, then all salespeople would have this warehouse role; this could mean a significant risk to organizational security.
Often the main role of users is not enough. Some employees may have different additional powers than employees in the same position as them. For these, an extra user-specific role can be opened that includes these special tasks.
Let’s get into the concept of Role Derivation. This structure consists of master roles without organizational privileges and child roles derived from these roles. While deriving this role, necessary organizational authorizations are made according to the needs of the user to whom the role will be assigned. Let’s try to concretize this structure with an example.
Assume that an organization has two branches in cities A and B. The accounting employee in city A of this company will be the owner of the role derived from the master role created for accounting employees, with the necessary authorizations for city A. The accounting employee in city B will have a derived role from the same master role according to their own city.
The Role Derivation approach is used faster and easier in all stages, especially in the establishment phase of the structure. For example, new employees can be assigned a role very quickly. As a disadvantage of this approach, it can be said that if there are too many single roles in the business processes, then the difficulty of maintaining these roles gradually increases. In addition, a mistake that can be made in the master roles can affect a large number of users.
2. Composite Role Design
The Composite Role approach is when multiple single roles come together to form a single role collectively. Usually, the name of the composite role will be the name of a position in the organization. The single roles in it also contain the transaction codes required by this position. Of course, users with extra responsibilities can also have more than one composite role when necessary.
It stands out as a role model as the fastest way to make role assignments. However, it should be noted that it is a complex structure that can get out of control if not managed carefully.
3. Enabler Role Design
In the enabler role approach, you separate organizational authorizations from functional authorizations. As a result, users need at least two roles to run a transaction successfully. Functional authorization values are placed in the functional enabler role, and organizational authorization values are placed in the organizational enabler role.
This structure is used to strengthen and simplify organizational and functional distinctions. It should also be noted that this design, which can achieve its purpose in its proper and careful use, may be difficult to use where organization objects or authorities vary according to the business process.
There is no obligation to use only one of these three different approaches. Companies can create a new role structure by blending these approaches in order to achieve the best outcome for them.
Access Control Approaches;
While establishing the authorization and role structure, it is important to consider which access control approach the structure will be designed with.
1. Role-Based Access Control (RBAC)
The RBAC approach is where the structure in which users are assigned permissions is based on the roles they are connected to. These roles are categorized and defined according to users’ responsibilities, seniority levels, and/or geographic location.
For example, a technology manager may have access to all the company’s servers, while a software engineer may have access to only a small subset of application servers.
Of course, the issue here is not just access. With this access, what can be done in that area may differ according to the roles. For example, some users can only view that area whereas users with more extensive authorizations can make new additions and changes.
Access time can be another factor that separates users according to roles. For example, a role created for a certain period of use from an external source may not grant access to the user after that period. In addition, more than one role can be assigned to a user according to his position and responsibilities. As an example, employees who have responsibilities in different projects can be given multiple roles.
Advantages
- It is much faster to define and implement roles.
- Allows the creation of an access hierarchy.
- It is a low-cost role structure if the creation of too many roles can be avoided.
Disadvantages
- In some cases, roles may need to have different details, which can lead to an excessive number of roles opening.
2. Attribute-based Access Control (ABAC)
The ABAC is an approach developed to allow or prevent access based on user attributes when the user logs in. So, what exactly could these attributes be?
- User: Business responsibilities, seniority, department, or security permissions
For example, let’s say an accounting employee is trying to access an accounting-related section. The system checks his/her department and responsibilities, and then this user can log in. However, if a warehouse clerk tries to enter the same partition, they will not be allowed as they do not meet the required attributes.
- Source Accessed: The name, document type, or sensitivity level of the source
For example, everyone in a company may be able to access the files that describe the companies maternity policy, but files that are for a specific sensitive customer project may be restricted to specific members of a team.
- Activity: What can be done on the system?
Managers or administrators in a project may have extensive privileges over files, such as creating, modifying, or deleting files, while less experienced employees or employees from a different project may only have view privileges.
- Environmental factors: Time, user location, resource location
While a user can perform a transaction today, they may not be able to do so after 1 month, depending on the duration of the defined authorizations. Or an employee in city A can change an order, while a user in city B may not be authorized to do so.
SAP UI Masking can be given as an example of ABAC approach. This product is designed to identify and protect sensitive information in SAP systems and to control who has access to it.
Advantages
- A detailed role structure can be established. In this way, it will be much easier to assign specific permissions to roles.
- It is not necessary to change existing rules when creating new users. The required attributes are assigned.
- Changing attributes is an easier and smoother way than changing roles.
Disadvantages
- Identifying attributes and assigning them to users can take a long time.
- Implementing it usually requires more time and resources for the initial setup.
Summarize
To summarize, depending on the organization’s size, budget, and security needs, the right structure or approach may vary. However, it is an undoubted fact that nowadays, where data breaches are increasing day by day and companies are paying huge prices, it is vitally important that these approaches and controls are applied correctly by companies. We believe that we can offer the best solutions for organizations that need authorization studies by taking reference from our ready-made authorization risks, rule sets, and past projects in the extensive Solvia RS Risk Library.
