Step 1: Preparation
Set up a team responsible for the specification and implementation of the user roles and the authorization concept.
Identify the business areas affected and their special security requirements. Like the control mechanisms selected, these can vary from area to area. Normally, the security requirements of the Human Resources department are more demanding than those of other departments. Therefore, you must first determine the desired security level.
Hint
Consider the different security requirements for the production, test, and development environments. Bear in mind, too, that user roles often need to access a number of systems and may therefore require different functions and authorizations depending on the system.
Train the team for roles and authorizations with regard to specification and implementation topics.
The team members must be familiar with the basic principles of the SAP authorization concept and the available control and administration tools (such as central user administration). The members responsible for implementation must be able to use the Role Maintenance.
Since the role and authorization project requires the cooperation of various business areas and departments, SAP recommends that you inform the responsible employees of the project targets set and establish communication channels at an early stage to ensure efficient handling.
When developing the role and authorization concept, the challenge is to coordinate business requirements at a cross-department level and protect sensitive data against potential dangers.
While user roles and the authorization concept are specified with the cooperation of the individual business areas, they are normally implemented by the IT department. This is why you must set up a cross-area and cross-department project team.
The team members have the following tasks:
Create SAP-dependent role descriptions in the "Analysis & Conception" step.
Cooperate with the IT department during implementation.
Set up and run through test scenarios.
To ensure that both the authorization concept and the procedures for user administration and authorization management comply with the control regulations of the company, the internal invoice verification department must be involved in the authorization project at an early stage.
Step 2: Analysis & Conception
Specification of the role and authorization concept:
Identify required roles. Determine task profiles based on the organization chart and a business process analysis. Check if SAP role templates can be used.
Specify relevant applications functions (transactions, reports, Web links) to the roles. Make any required adjustments if role templates are used.
Specify if the roles are higher-level roles or specific roles; that is, if they are subject to any restrictions resulting from organizational or application-specific control mechanisms.
Identify required composite and individual roles for implementing the roles and the authorization concept.
Check the role and authorization concept. To detect any shortcomings in conception before actual implementation, SAP recommends that you create a prototype of the concept.
User roles are technically implemented using individual, composite, and derived roles. Based on the transactions and reports selected for each role, the Role Maintenance automatically determines all authorization objects required for performing the functions specified, and creates the corresponding authorization profile.
Using individual, composite, and derived roles, you can model the role structure in two ways:
You can model each role as an individual role that contains all required functions. If some functions are used unchanged in multiple roles, the associated transactions and reports are contained in several individual roles. If general function modifications are required, this consequently affects several individual roles.
Alternatively, you can model each role as a composite role consisting of individual and derived roles. In this case, the individual and derived roles represent activity blocks, that is, groups of interrelated functions (for example: all functions needed for a specific business scenario). Since individual and derived roles contain encapsulated functions, they can be used in multiple or composite roles. The advantage of this approach is that multiple access to transactions used in several individual roles is avoided. Therefore, organizational or process-related modifications that affect several user roles can be applied by adjusting a single role.
Step 2 "Business Blueprint for the Implementation Project" is used to analyze and determine the scope of the implementation. When creating the Business Blueprint, you determine which processes are to be implemented in the context of the implementation.
The result of all the business processes that can be used and mapped in the SAP system is saved as a Microsoft Excel list in this example.
The user roles are created and completed in this authorization list. A similar list can also be generated in the SAP system. In this case, the list is component-oriented, and not process-oriented as in our example.
SAP systems are delivered with a number of role templates in which the associated application functions (transactions and reports), the user menu, and the authorization data are predefined. These templates can be used as a basis for analyzing and developing the company-specific roles and the authorization concept.
Hint
These roles begin with SAP_* and the profiles for these roles have not yet been generated. They are only intended as templates with examples for the authorization setting.
The authorization list is a Microsoft Excel table that helps the project team to model the user roles before they are implemented in the SAP system. Using this list, the roles can be developed before the system is installed.
In the authorization list, you create user roles and specify the associated transactions. In this example, it consists of two worksheets:
Sheet 1: Process View (Roles Design - Scope)
The structure shows the business processes that were selected during the analysis and conception of the enterprise. The job roles and user roles are specified and linked with the processes here.
Sheet 2: Transaction Overview for Each Role (T Code for Each Role)
You can generate an overview of the transaction assignments for each role in the transaction overview (after the modeling on sheet 1).
Modeling the role structure: Analyze the authorization list and determine the areas in which access to several transactions is needed. Activity blocks such as this can be created as roles.
To simplify implementation, you can subsequently modify roles during the technical conception phase, for example, by choosing additional transactions to use activity blocks that have already been created.
Hint
Note that access to the same transactions and reports is not a sufficient criterion for the existence of an activity block. Since authorizations may vary even at field level, you must implement the different variants of individual activity blocks as separate or derived roles.
During the first conception and implementation approach, individual functions are encapsulated in separate roles (for example, the Basis authorizations of the end-users).
From a technical point of view, all elements of the authorization concept must be assigned a unique identifier. This is why you must define individual naming conventions for all role types.
You can define naming conventions based on different criteria, for example, country, business area (FI, CO, and so on), or application component (FI-AP, CO-PA, and so on).
If you want to decentralize user and authorization management, the naming conventions are also required for administrative purposes. In this case, the access rights of the decentralized administrators should be limited to those (composite) roles that belong to a specific business area and thus apply only to a restricted namespace.
Since roles are divided into individual and derived roles, the user roles created in this step may be different from the original specification defined during the development phase. For example, the roles may contain more or fewer activities (transactions and reports). This is why you must check that the roles are properly defined before implementation.
SAP recommends that you carry out a test implementation of the user roles and authorization concept to check the technical conception.
Step 3: Implementation
From a technical point of view, user roles (job roles) can be implemented as composite roles using the Role Maintenance. Composite roles consist of individual and composite roles that each contain the relevant authorizations and menu data. Authorizations specify the scope of access to data and functions. User menus use hierarchical structures to specify the access path to the transactions, reports, and Internet pages released for a specific user.
An example of how you create user roles:
Create individual roles: Individual roles either describe higher-level functions that are independent of organizational or application-specific restrictions or are used as templates for creating derived roles that are not subject to any restrictions.
Having checked the individual roles used as the derivation basis, you create the derived roles. These contain the desired organizational or application-specific restrictions. For each responsibility area, you create a derived role from an existing individual role.
Finally, the composite roles are created from the implemented individual and derived roles as the technical counterparts of the user roles.
Step 4: Quality Assurance & Tests
To ensure that productive operation is not affected, it is important to thoroughly test the user roles in connection with the authorizations before you switch over to production. In addition, the responsible area manager must approve of the role and authorization concept implemented.
To standardize the tests, the relevant process flows must be determined and published. You should use predefined test scenarios that cover all business processes implemented.
The test scenarios should include both positive checks and negative checks of the authorizations of the individual roles. The positive checks must determine whether the functions are executed as desired, while the negative checks must confirm that all restrictions defined are observed. For example, a human resources administrator can display the users for a specific work center, but not the records for other work centers. The test scenarios must cover all functions that are to be performed by a user role.
If a function cannot be called during the test, you must correct the user roles and the authorization concept. Note that changes may affect several (derived) roles. In extreme cases, you must revise the entire role and authorization concept.
You may also be required to modify the user menus to simplify access to the functions. To ensure that the system becomes more user-friendly, the project team responsible should closely cooperate with the representatives of the relevant business areas.
After fine-tuning the user roles, you must repeat the tests as often as necessary until the user roles implemented completely comply with the security and usability requirements.
Step 5: Cutover
Before you create the production users, you must create the master records for user management in your production environment, and possibly configure central user administration.
To simplify the creation of the individual user master records, you first create model records. These model records are used as copy templates for the records of the productive users. In the central system, create a user master record for each role specified in the company-wide role matrix (authorization list). If a role is subdivided into several responsibility areas that are subject to organizational restrictions (company code, cost center, plant, and so on) or application-specific control mechanisms (such as FI authorization groups), you must create a separate record for each responsibility area. Maintain the additional data (parameters, printers, and so on).
After consulting the area managers (data owners), define the roles for each user. Consider that some users may have several roles or different roles in various logical systems (clients). Enter the assignments in a user and role matrix.
To create a master record for a user, you copy the model record for the relevant role and customize this record as required.
Get the final approval of the area managers with regard to the users created and communicate all access-relevant data (system, client, ID, and password) to the end users.
