When you are going to do identity audit checks or SoD checks in your identity and access management systems and when it comes to SAP, the checking of permissions is more complex than in regular target systems like Active Directory or LDAP. This is due to the fact that SAP contains roles, like composite roles or single roles, which again can contain composite or single profiles.
And the checking of the permissions actually are not done by checking the profiles of roles but checking the transactions' authorizations like authorization object classes, authorization object fields, activities values, and the combination of these. This can be used to retrieve the information and do SoD checks on the authorization or SAP permissions level without relying on the names of composite or single roles or profiles.
By using authorizations in transactions or using authorization without transactions, you can find the corresponding profiles or roles in the One Identity Manager system. One Identity Manager does this without relying on additional functionality in the SAP system and can replace by this functionality of SAP Access Control. Authorizations will be checked. The user buffer will be calculated. And the user's permissions will be fine and listed. And these permissions will be checked in SoD rules.
So when we look into the Identity Manager, we have SoD rules that can contain SAP function instances. And SAP function instances, again, contain SAP function definitions. And these functions definitions actually define the authorizations, the fields, the values, that are being checked.
So an authorization can be assigned through multiple profiles or multiple roles. And we don't check for the SAP role or profile name. But we check for the actual permission in the SAP system. And by that, changing names of roles or profiles will not affect checking of the corresponding authorizations.
These checking SoD rules can be combined with SAP or non-SAP systems. Even if the user, for example, has a user account in multiple SAP clients, the checking can be executed across clients. Or if the user should have more than one user account assigned to him on the same client, the checking can still be done across user accounts on the employee level matching any toxic combination of authorizations for the employee and not only for the user account that is being checked.
One Identity Manager's SoD rule checking is not only restricted to checking SoD violations on a single platform or a single target system or an instance of a single target system, like an SAP client, but is also capable of synchronizing different instances of the same target system and doing cross-target system or cross-instance checking of authorization violations.
So if a user account is-- if an employee should have different user accounts on the same instance of their target system, like in an SAP client, he has a privilege user account and a default user account, or if you have different accounts on different instances or clients of the same system, or if he should have user accounts on an AD, LDAP, cloud-based system, or SAP clients, the authorization engine is capable of combining all these combinations of the employee's user accounts into a single employee and execute the check of the toxic combination of permissions on the employee level.
Even if you implement a master subidentity concept, which is very useful if you have to deal with different work contracts for the same employee, then you could do the checks on the master identity level and find all the combination of user accounts and identities that are linked together and find these toxical permissions that a user can have. Other platforms that SoD checks are only restricted or mostly restricted to single clients or single systems and can't do a cross-target system or cross-system checks for rule violations.
Now if we switch to the manager tool to check how these-- SoD checks, cross-platform SoD checks, can be implemented in One Identity Manager, you can still see the SoD rule that has been created for the SAP platform. Now to add an additional permission that is going to be checked, simply click on the Add icon and select a target system and entitlement, in this case, an Active Directory entitlement. And enter the group name, for example, to check.
So now this rule has been extended, not only to check the SAP entitlements that are granted through profiles or roles, but also to check for an existence in a group membership in Active Directory. This is as simple as that to add additional target systems for the checking for a toxic combination of permissions.
SAP profiles are the containers that contain the SAP authorizations from a target system. SAP profiles contain transactions, which are permissions that allow you to execute specific ABEP programs, which are functions or programs in an SAP system. These SAP functions and programs will execute on specific activities, on specific tables, fields, with specific values.
This information contain the fine-grained authorization that are being assigned to a user account in a specific SAP client. These informations will need to be synchronized from the SAP system through another SAP synchronization project. In this case, the SAP authorization object synchronization project will be used to synchronize these objects into the One Identity Manager database.
As you can see in this example, that specific project has been selected in the Synchronization Editor tool of One Identity Manager and the different mappings that are being provided by this project. As you can see, this contains a lot of different mappings in contrast to the other projects. And these mappings are different from any previous project.
In this mapping, the profile's content will be synchronized. The profile's content can be very extensive, since these fine-grained permissions can go down until the database object like tables, fields, and activities, and filters on these activities and fields.
So for example, the next object that will be synchronized is a transaction. As I mentioned, the transaction will allow you to execute specific programs in an SAP system. The transaction itself is just a container, again, that is being synchronized. But the transaction in combination with the fields, values, and objects consists the profile and hence the permissions that are being assigned to the user account. So this will be synchronized into One Identity Manager and will be linked with the profile and the role that is containing this information.
So when we go into the SAP module, we will see there are lots of profiles synchronized. And when we scroll down to one of the profiles that contain authorizations, we will see in the Authorizations Editor that a lot of this information has been synchronized. And this information is actually used later in the Authorization Editor to build the SAP function definitions that will match the specific profiles and roles to be used in an identity audit function instance.
10:11