As you see, [? PHL ?] and [? on ?] data has been synchronized. Let's have a look into SAP's user and role management. The SAP Basis synchronization project, not only managing user accounts and roles, provides the following schema objects and their mappings. Company in SAP is mapped to SAP company. GROUP or user group, SAP is mapped to a SAPGrp. Parameter in SAP is mapped to SAPParameter, PROFILE to SAPProfile, ROLE to SAPRole, and USER to SAPUser.
This is an incomplete list. There are far more schema objects that are mapped. And when the synchronization of the SAP client is performed, One Identity Manager will have a hyperview displaying the relationship of the synchronized objects.
A relevant distinction between SAP and most of the other target systems is the fact that in SAP, user can have the same role assigned multiple times with different validity periods. One Identity Manager supports this SAP behavior by providing the capability to assign the same SAP role multiple times. It also adds support for the origin information. This way, the SAP role assignment can be linked to a request or inheritance from a business role or a direct assignment on the correct instance of the SAP role assignment, and the user account can be removed when needed.
There are several configuration parameters for handling the validity period in SAP user account assignments to roles. For example, DoNotUsePWODate, if set to Active, will not copy the order date, but use 1st of January 1900 and 31st of December 9,999 as assignment dates. The default behavior is to use the PWO date for requests, though. Additionally, some considerations for migration from versions before 7.0 are needed, though I don't think there are any version 6.0 installations left anymore.
The SAP user account, as can be seen in the hyperview representation in One Identity Manager, contains the relationship between the roles and profiles from the SAP client as well as the link to the employee or person record in One Identity Manager. The same information can be displayed in the SAP GUI using the SU01 transaction.
When both systems are put side by side, we can see that One Identity Manager's details window for the SAP user account master data is closely following the SAP GUI approach. Even the detailed steps are named alike, login data in the SAP GUI and login data in One Identity Manager, for example, or user account type and user type in SAP GUI, user account parameter in SAP GUI and parameters in One Identity Manager, or SNC information in SAP GUI and SNC information and One Identity Manager.
This similarity, One Identity Manager following the SAP GUI approach, helps to convince the SAP administrators that One Identity has a deep understanding of the SAP admin tasks and is actually aligned with SAP's best practices or recommended approach. The SAP administrators will immediately feel home and understand One Identity Manager's approach to SAP. This is what they already know.
The SAPRole, as can be seen in the hyperview representation in One Identity Manager-- once again, it contains all the relationships between roles and profiles, transaction ranges, single and collective role relationships. And the same information can be displayed in the SAP GUI using the PFCG transaction.
Again, when we both put this information side by side, we can see that One Identity Manager's details window for the SAP role master data is closely following this SAP GUI approach. We can see the same information in SAP GUI One Identity Manager. We can see the profile name linked with this role. We can see the transactions assigned to the users by the role. This information can be displayed in SAP GUI by clicking on the glasses icon at the bottom to display the authorization data.
The SAP parameter information displayed in One Identity Manager and SAP parameter displayed in SAP GUI and in One Identity Manager put side by side. The parameter details show the same information. SAP parameters are used to prefill values in [INAUDIBLE]. Once again, One Identity Manager closely follows the SAP approach is very beneficial when talking to the technical SAP people.
One Identity Manager also synchronize licensing information from SAP and allows to assign licenses to user accounts. User account license information can be mapped in One Identity Manager. An employee can have several user account which belong to different clients and systems. The employee's most significant user account is required for system measurement. This user account is determined as a chargeable user account by system measurement.
One Identity Manager calculates user account ratings from the licenses assigned. The employee's most significant user account is automatically determined from all user accounts not managed through CUA. System measurement data is supplied in One Identity Manager. The actual measurement, though, takes place in the target system.
One Identity Manager also provides Cost Center information from an ERP system that can be used to reflect on Cost Center structures in the Identity Manager.
But how are roles and profiles different from SAP systems without CUA and with CUA? In a system without CUA, roles and profiles are directly mapped from the client and have a single representation. In a system with the CUA, the roles and profiles have representation in the CUA central client and the CUA child system.
And looking into SoD rules with SAP, we have to understand SAP authorization. SAP authorization model is far more complex than most other target systems that are being connected to identity governance systems. Once we understand how authorizations in SAP [INAUDIBLE], we can use this to build walls to match toxic combination of entitlements.
Let's look at the authorizations from an IGA perspective. A person, or an identity, in IGA system like One Identity can have one SAP user account assigned to him or more. The identity can have more than one regular SAP user account or can have a regular account and an admin account. Or the SAP user account can be on a different client on the same SAP system or even on a different SAP system. What is relevant is that the person can have more than one SAP user account assigned to him.
This SAP user account can be assigned an SAP role. This can be a composite role containing other roles or a single role. Each SAP role can contain SAP composite profiles that contain other SAP single profiles or SAP single profiles.
The SAP profiles are the actual objects containing the SAP permissions that grant user accounts the capabilities in the system. These SAP permissions are the actual information that need to be evaluated for checking off toxic combination of permissions. The profiles or roles are just containers holding this information. Actually, they can be changed, can be copied, et cetera.
With standard SAP role maintenance using PFCG transaction, the profiles' names are autogenerated. A simple role name checking on the SAP role level might be sufficient if the profile assignment would not be possible. But it is possible to assign roles and profiles to SAP user accounts. Actually, a role assignment also leads to a profile assignment to that user account.
So simply checking for a role or profile name isn't enough. The actual authorization must be checked. One Identity Manager supports profile assignments as well as the role assignment to SAP user account in One Identity Manager. And the user account will be linked to the single person in the Identity Manager.
Now you have to look deeper into the SAP permissions model. To understand how permissions in SAP work, the profile, or authorization profile, combines one or more authorizations. Authorizations are assigned authorization objects. And authorization object classes are assigned authorizations.
When we get a bit closer to the model, we can see that authorization objects contain authorization fields, and authorization objects are part of authorization object classes. So if you look at the authorization fields, let's say, BUKRS, or [GERMAN] in German, or company code in English, this is a specific field or attribute in an authorization object in an authorization object class.
Let's say authorization objects class FI, which is the finance module-- if you look at the field ACTVT, or activity, you can see the same. It is a specific field or attribute in an authorization object in an authorization object class. However, the activity field has also special meaning since it defines the specific activity or activities on the fields. Let's say, in this case, [GERMAN] or company code, which will define the values for the field or fields.
So if you're familiar with the One Identity Manager permissions model, this is relatively close to how One Identity Manager manages permissions. We have tables or objects. Each table has fields or attributes. And on each of these attributes, we can perform operations like insert, change, delete, or read. This is more or less the same approach with the authorizations in SAP. The authorization object assigns to you the list of allowed activities on the list of allowed fields with the list of allowed values.
When we look into role with the PFCG transaction and edit the authorization information, we will see the previously discussed elements in the role authorizations. For example, FI is the SAP authorization object class, or SAPAuthObject class, in One Identity Manager. In that context, F_KNA1_GRP is the SAP authorization object or SAPAuthObject in One Identity Manager. And ACTVT and VKORG, as seen in this sales organization, are the SAP authorization fields or SAP fields in One Identity Manager.
The customer account group authorization element allows the Activity 02, which is change, on every customer account group since it is marked with an asterisk. The field values can contain lower and upper limits for a range of values, or a list of comma-separated values, or a combination of these.
Now that we know the authorization model, we have to understand how these authorizations are checked in SAP. In SAP, authorizations are checked at several stages. The first check is performed at transactions start. The system program checks if the user is authorized to execute the specified transaction. The system checks for the S_TCODE. And if the user is not allowed to execute the transaction, the system will stop the execution. If the check is positive, the system will execute the program and transfer the authorization check to the ABAP program.
In the ABAP program, an authority check is being performed with the specific requirements on the authorization object fields. If the user does not have the permissions to execute the specific activity on the specific fields and values, the program execution is stopped. The permission check is being executed against so-called user buffer.
The user buffer is being calculated for each user upon login and holds all the authorizations a user has in the SAP client. One Identity Manager's SoD checks are also calculating the user buffer for a person and performing the checks against them.
Now with all the prerequisites ready, we can look into the SoD group configuration and support in One Identity Manager. One Identity Manager provides support for native SAP audit concepts. One Identity Manager audit rule setup is comparable to the concept of SAP Access Control. For example, a function in SAP GRC corresponds to a function in One Identity Manager. Or a RiskOwner corresponds to a rule supervisor in One Identity Manager.
This again is really useful in discussing the audit features of One Identity Manager with SAP admins. They would immediately understand the concept of One Identity Manager. The audit rules defined in SAP Access Control can be exported from SAP GRC and imported into One Identity Manager.
Identity Manager follows the lead of the SAP style and terminology, which means it is more readily adopted by the SAP team. One Identity Manager's support for SAP permissions provide the following schema objects and their mappings. Transaktionen in the SAP schema is mapped to SAPTransaction AUTHX in SAP schema is mapped to SAPField in One Identity Manager, for example. This is an incomplete list. There are far more schema objects that are mapped.
SAP permissions in the SAP GUI and the same information for an SAP role in One Identity Manager. Again, One Identity Manager is closely following SAP style and terminology.
The authorization editor. An SAP function definition can be configured in One Identity Manager. In this example, we can see that the two transactions, PFCG and SU01, are added to this function definition. Transactions are OR combined, and other objects are AND combined. In this specific example, any role or profile that assigns the SU01 or PFCG transaction, and if these transactions contain all of the authorization object classes and the fields with the specified values, then this function definition will match.
The field values can be filled with variable names. These variables can then be replaced with the values from variable sets. A variable set defines variables and their values. These variable sets can be used together with function definitions in so-called function instances. Function instance is an instance of a function definition that is applied to a specific SAP client with a specific variable set.
As can be seen in this example, the KTOPL, or chartered accounts, or [GERMAN] in German, field value has been set to 25, the value from the variable set. The function definition is a template of authorization objects. The function instance is the specific client-based instance of this function definition.
This way, the same function definition can be applied to different SAP clients with different values. In one SAP client, the approval limit for a sum might be 10k, And in another client, it might be 50k. Instead of maintaining two different function definitions, only one function definition is being created, and different variable sets are applied for different clients.
Once the function instance has been created, the system will automatically precalculate the list of affected SAP roles and profiles and user accounts that already match the function instance. This precalculation allows for faster calculation of violations and the reduction of calculation time. Preventive checks can be implemented much faster using this method.
As a final step, different function instances can be put together to an audit rule. In One Identity Manager, audit rules are being executed on the employee object. And the default setting is to calculate the rule violation for the combination of all the employees' identities. The check will find SoD violations across different user accounts because One Identity Manager checks on the employee level, whereas account-based systems can only check on the account level.
Thank you very much for attending the One Identity Manager and SAP section.
17:18