Access Control Engine in CRM

Access Control Engine

Introduction
All of big clients having big or complex CRM installations faces same problem: how can we restrict the users only to particular data that they need to see? We don’t mean authorizations related to functionality, but related to business content (Real time data). Imagine you run a big business and have a millions of customers worldwide. Then a sales representative responsible for a group of customers in Region AAA should not see any customers from Region XXX in his search results. Or a sales representative with responsibility for a certain branches should not be bothered with customers of other branches. Most important here is if the structure of the sales organization changes, you don’t want to end up changing all kind of authorization profiles/Roles.

To solve these issues, SAP came up in CRM with a pretty nice solution: CRM-ACE. This stands for Access Control Engine and is a framework to calculate user dependent access rights on object level that to dynamically. It originates from Channel Management but works in all PCUI (People Centric User Interface) functionalities. One Limitation here is, it doesn’t work in other environments like IC Web client or via the SAP GUI.

The access control engine (ACE) in SAP Customer Relationship Management (SAP CRM) is an additional authorization concept that exists in parallel to the SAP authorization concept. You can implement ACE independent from the SAP authorization concept, but to save time and effort when you create ACE user groups, you can reuse the authorization roles (PFCG roles) that were defined in the SAP authorization concept.

While you can use the SAP authorization concept to limit user access to transactions (such as creating an order) and activities for an object type (such as creating or deleting an order), ACE provides a framework that you can use to control user access to individual business objects and the usage of those business objects. This means that you can define which users see which business objects, and whether those users have the authorization to read, edit, or delete those business objects.

The access control is based on a combination of rules and rights that you can adjust individually for your internal organizational structures.

Users only see the business objects to which ACE grants them access. However, users do not see the ACE functions on the screen and do not consciously notice ACE.

ACE is of interest to large organizations because it uses organizational units that mirror territory management very effectively. In other areas, the advantage lies in the versatility of the business hierarchies in including external partners in internal business.

Example:

You can use ACE to define that a Business Partner has read authorization and write authorization for his opportunity, read authorization for the opportunity of her colleagues, and read authorization and write authorization for all new opportunity of the company.

Difference between Normal CRM authorizations and ACE.

·         The SAP authorization concept is registry-based. If there are new users or objects, we need to make adjustments to the SAP Roles.

·         In the traditional concept, we have to specify all values in the roles, that is we need to specify the sales organization from which the user is allowed to fetch data. Now, If we have 30 sales organizations you need 30 roles which will segregate all 30 sales org and will be assigned to 30 different user group in those organization. This is also known as Static authorizations.

·         Access Control Engine is based on rules, rights, relationships, and hierarchies. Once the ACE rules and rights are set up, it is not necessary to adjust these rules and rights if there are new or changed users or objects.

·         In Access control engine, we can specify in one role that all users who have this role will be able to see specific customers for the sales area to which they are linked to. So with 30 different sales organizations we only need one PFGC role. If a sales representative moves from one organization to another you don’t even need to change his Role/profile. This is known as Dynamic authorizations.

Features available in ACE

Below functions are available in ACE:

·         ACE provides an administrative tool for all rights and rules that influence access control. The administrator can assign these rights and rules to users and roles.

·         ACE supports changing user integration in business operations, such as changing the role or organizational unit. The new access control for users is calculated in day-to-day operation or asynchronously (time-shifted). If reorganization affects a large number of participants, an administration tool supports the changes to access control.

·         ACE first gives users temporary full access to new objects that they create. When users save, the system starts a process in the background to calculate the rules-based access control for these objects. The resulting user access rights replace the temporary full access.

·         The system changes the access control for changed objects during runtime. This is done by a process in the background. The new access control is effective after a delay.

·         ACE has a buffer for previously calculated access control information. You can use the buffer to check and monitor the access control during runtime.

·         You can define the relationship between objects and users, for example, for organizational units, partner companies, areas, or product lines. You can define access rights, for example, so that employees of a partner company can access business objects that were created in that partner company, but cannot access business objects that were created in other partner companies.

·         ACE has been designed as an add-on. It can be used in many different ways to take advantage of the business knowledge available in SAP CRM. The ACE framework serves all add-ons centrally. You can develop new add-ons for special enterprise requirements as necessary.

ACE Concept

The basic element in the concept of ACE is the actor. To explain this in the easiest way you can say this is the linking and filtering element between the user and the object. The actor determines if the user should see the object or not. As an example look at the following picture which explains the scenario that a user is only allowed to see business partners where he is in the sales team. The user is linked to an employee and these employees are stored in the sales teams of the business partners.

From the user’s perspective you can determine the employee id which is in the sales team. Also from the business partners perspective you can see who are in his sales team. If both of them match, the user can see the object.

How the actor from both perspectives is determined is stored in a rule. Here are three methods defined:

1.       How to determine the actors from the user.

2.       How to determine the actors for an object.

3.       Method to specify which objects to take into account.

This is shown in the following pic:

An ACE rule is a combination of a role and an action (read, write, delete). These rules you can assign to ACE user groups which you can link to individual users or in most cases to dummy ‘normal’ authorization roles which you can assign in the user master.

The good thing about the concept of ACE is that when you activate it, it fills the ACE tables with data so it can determine who is allowed to see what data object in a fast manner during runtime. Basically it determines before hands for all users and for all objects what its actors are and stores this in tables. During runtime it knows your user, so can quickly read your actors and then read all objects which have the same actor. If a new object is created after the activation it automatically in the background determines the actors and updates the corresponding tables.

Standard Technical Flow

ACE customizing

Business Scenario:  Any particular account and its Contacts can be displayed / edited / deleted by the employee who has created that account and the other employees who are related to that Account with the relationship type “Is the Responsible Colleague Of”.  

General parameters:

We need to maintain few of the Parameters as below

1. DISPATCHER_DESTINATION parameter should have the name of RFC destination through which ACE update job is scheduled. The default entry is “ACE_ACCESS”.
2. Then to deactivate/activate ACE you need to include the parameter “ACE_IS_INACTIVE” which when set to “X” makes ACE inactive and if blank then ACE is active.

Rule Customizing

Rule Customizing consists of defining the AFU, OBF and AFU class. AFU stands for Actor For User. This is used to determine actor_id the user is assigned to. This create  entries in the UCT table.OBF stands for Objects By Filter. This is used to determine which objects are relevant for the group.

AFO stands for Actors for Objects. This is used to determine the actors that are to be applied for the found objects.

IMG Path : IMG --> CRM --> Basic Functions --> Access Control Engine

Step 1: Add Super Object Type

You see default entries already maintained for our object ACCOUNTCRM. If the need arises one can add a new super object type too. We fill in the ACL table name, then GRP table name and UCT table name.

These are the runtime tables where in the authorization data is stored. You can have a look at the data of these tables from SE16. Because an individual set of runtime tables is created for each super object type, authorizations are spread across several tables. This enhances the performance.

Step 2: Add Object Type

For each CRM object type used in ACE, a default BOR object type is assigned in table CRMC_PRT_OTYPE. Say for example object type “ACCOUNTCRM” the corresponding BOR object type is “BUS1006”. To define an object type, refer to the screen shot below.

Then you have the concept of Action and Action group. Actions are summarized in action groups, and used in connection with rights, they grant users specific authorizations such as READ, CHANGE, or DELETE.

Step 3: Create Actor Type

An actor type describes the relationship type between the user and an object, for example, contact person, responsible employee. Whereas actor is an attribute of Actor Type. Refer to the screen shot below to create an Actor Type. Here we have created an Actor type “ZACC_EMP_RESP” for Employee Responsible as per our scenario explained in the start.

·         Create a new Actor Type.

·         Or use existing standard actor.

IMG Path: CRM à Basic Function à ACE à Rules à Create Rules à Create Actor Type

Step 4: Add AFO Class

AFO stands for 'Actors for objects'. Here we define AFO class ID for our Actor type created in the previous step. The class “ZCL_CRM_ACERULE_ACCOUNT” implements the interface “IF_CRM_ACE_ACTORS_FROM_OBJECT”.Create a custom class or use standard one to assign as AFO Class.

·         Find the object Type of your interest (Eg.: Opportunity)

·          Assign the Actor Type ID (Eg.: ZIRACTOR)

IMG Path: CRM à Basic Function à ACE à Rules à Create Rules à Add AFO Class

Step 5: Add OBF Class

OBF stands for ‘Objects by filter’. Here also we define the same ABAP class we defined in the previous step. We need to implement the interface “IF_CRM_ACE_OBJECTS_BY_FILTER“in that class.

·         Find the object Type of your interest (Eg.: Opportunity)

·         Create a custom class or use standard one to assign as OBF Class

IMG Path: CRM à Basic Function à ACE à Rules à Create Rules à Add OBF Class

Step 6: Add AFU Class

AFU stands for ‘Actors for User’. We need to implement the interface IF_CRM_ACE_ACTORS_FROM_USER in the class “ZCL_CRM_ACERULE_ACCOUNT”. 

·         Assign the Actor Type ID (Eg.: ZIRACTOR )

·         Create a custom class or use standard one to assign as AFU Class

IMG Path: CRM à Basic Function à ACE à Rules à Create Rules à Add AFU Class

Step 7: Create Rule

This is the final step in creation of ACE Rule. This rule would be used in the Right definition step.

·    Bind the actor type id, AFU class ID, AFO Class ID, and OBF Class ID  with a rule id for object type.

IMG Path: CRM à Basic Function à ACE à Rules à Create Rules à Create Rule

 Rights Customizing

Right Customizing consists of defining the user group, and combining the user group, the allowed action (read, write, delete) and the rule into a “Right”.

Step 1: Work Package Definition

A work package is an organizational unit of the ACE, which combines user groups and enables them for one or several object types. We define a work package for all our Account Related ACE Rules. The super object type assignment ensures that users of the user group(s) are only active ACE users of the respective super object types and their sub objects.

·         A work package combines user groups and enables them for one or several object types.

IMG Path: CRM à Basic Function à ACE à Create Rights à Work Package Definitions

Step 2: Object Type Assignment for Work Packages

·         Assign the super object type to a work package.

Step 3: User Group Definition

A user group contains users who should get authorizations for objects. User groups can contain single users, as well as roles. Furthermore, they can be nested. User groups are assigned to work packages.

A user group can be assigned to one work package only, nesting of user groups may result in non-unique assignments. For example, Group G1 is assigned to Package P1. Additionally, Group G1 is nested in Group G2, which in turn is assigned to Package P2. The user group in Package P1 is therefore not valid, because assignment to a package of Group G1 via nesting in Group G2 is not unique.

IMG Path: CRM à Basic Function à ACE à Create Rights à User Group Definitions

Step 4: User Group Entries

The entries in the User group can be defined as a User, Role and a User group. Normally it makes sense if you create a role for which ACE authorization is applied and add that here. For demo purposes I have added a set of user IDs here.

Step5: Right Definition

Right definition makes the connection between a rule, which provides the objects as well as the actors, and the users, who are stored in the right via the user group. The right also defines the possible actions that the user can execute with the objects of the rule. Furthermore, you can specify a validity period for the rights and hence control them chronologically. Refer to the below screen shot which shows the Right we had created.

IMG Path: CRM à Basic Function à ACE à Create Rights à Right Definition

Technical View in ACE

If you create a new ACE right you have to implement a new class (copy from an existing class in the range CL_CRM_ACERULE*). The class contains 5 methods:

1.       GET_ACTORS_FROM_USER: This method receives the user id in the field im_usr_name and determines the actors for this user which should be put in table ex_actor_id_table.

2.       GET_OBJECTS_BY_FILTER: This method determines which objects to take into account and puts their GUIDs in table ex_object_guid_table.

3.       CHECK_OBJECTS_BY_FILTER: This method receives the table from the GET_OBJECTS_BY_FILTER method and here you can add additional filtering.

4.       GET_ACTORS_FROM_OBJECTS: This method receives the internal table of method CHECK_OBJECTS_BY_FILTER and for all these object GUIDS it determines the actors at once. It puts these in the table et_actor_ids.

5.       GET_ACTORS_FROM_OBJECT: This method is called when there is a new object created after the activation; e.g. when you create a new prospect this method calculates its actors. It gets as input the object GUID in field im_object_guid and gives its actors in table ex_actor_id_table.

Note: Methods 1-4 are used during the activation of ACE and the last one is used when new objects are created.

Sample Code for the above methods:

In this example implementation of class ZCL_CRM_ACERULE_RELATION is done, which allows users only to see business partners for which they have a relation with. For example, they are defined as employee responsible, or as account manager.

Note : Check my blog for Sample code

Important tables in ACE

The relevant tables involved are the following (where XX can be BP for business partners, OO for ‘one order’ objects which can be activities, orders, opportunities and leads, and PR for products; these are the three objects for which SAP delivers tables)
1. CRM_ACE_XX_GRP: In this table all possible actors are stored (e.g. all employee numbers or all sales areas) with their ACE_GROUP_ID, which is the GUID linked to this actor. Here, rights are mapped to actor_id’s and ACE-groups. This table will generally not contain many entries.
2. CRM_ACE_XX_UCT: In this table all users with all their ACE_GROUP_Ids (=all their actors) are stored. Or in other words we can say it contains the mapping between actual USERID’s and the ACEGROUP.
3. CRM_ACE_XX_ACL: Here all object Ids with their actors (in the form of the ACE_GROUP_Ids) are stored. This is the actual Access Control List. All relevant business partners are linked to an ACE-group. One business partner can be assigned to several ace-groups. This table will generally contain many entries (at least one for every BP).

From these tables you can easily see how ACE internally works:  It knows your users, then reads in the user context table (*UCT) your ACE group Ids, and then in the access control list table (*ACL) it reads directly all objects you are allowed to see. It works as easy as that.

Activate Work Package and Rights

Once we are done with Configuration and technical coding (Which I have explained after this topic), we need to activate Work Package and Rights.

First activate you User Group from the User Groups tab and then activate your right from the Rights tab.

·         Activate Work Package

·         Activate Rights

·         This activity will fill the runtime tables for ACE

IMG Path: CRM à Basic Function à ACE à Activate/Deactivate Work Package and Rights

Once the right has been activated you can check out a job runs which can be checked in your SM37 TA and the runtime tables are filled in with the authorization data. After the job finishes, you can check out one of the runtime tables CRM_ACE2_BP_ACL filled in with authorization data.

ACE Design Report 

Finally once the entire configuration is done, then our design can be verified using the transaction “ACE_DESIGN” by giving the Right Name as input.

Now, check out the TA ACE_RUNTIME which will show the runtime data. One can check out the accounts a particular user can access. One can also check out whoever is allowed to access a particular account.  

Filter Selection To call the report, select at least one super object type. If you have selected a super object type, you can refine your search by additional criteria and display the list. 

IMG Path: CRM à Basic Function à ACE à Create and Analyze Runtime Data

Performance considerations

When applying ACE, you should consider performance, as ACE will generally create big ACL tables and call these tables often. You can influence the size of these tables from a functional perspective by focusing on the object groups rather than user groups when implementing ACE. I will explain this based on an example:

Let’s say you have 10.000.000 business partners in your system to which you want to apply ACE. You are implementing ACE for 5 user groups. All of these user groups have display rights for all business partners.

Each of these user groups has a specific group of 2 million BP’s they will get change-authorization for. You now have two ways to implement this:

Option 1

Create 5 work packages, one for each user group and contain the definition for the user group in the work package. The work package could consist of the following rules:

• Display rights for all business partners.

• Display rights for all contacts of the assigned business partners.

• Change rights for the 2 million business partners based on an attribute.

• Change rights for the contacts of the 2 million business partners.

Option 2

Create 6 work packages, one for each user group and one for the display all. The display work package would contain the display rights for all business partners; the change work package would contain the change rights for the specified group.

In the above example, even though from a customizing point of view, it doesn’t seem to matter, in practice, the second option would be the best, because in the first option, the access control lists of all 5 work packages would contain 12 million entries (10.000.000 + 2.000.000). These sums up to 12 * 5 = 60 million records to check when trying to display a business partner. Not to mention the fact that contact persons should also be counted in.

In the second example, there are 10 million entries in the display work package, and 5*2 million = 10 million in the other work packages, summing up to 20 million records to check when trying to display a business partner.

Conclusion

The conclusion is that when implementing ACE, think from an object perspective, and not from a user perspective. Rather assign more than one ace PFCG role to a user than assign more than one ‘right’ to a work package, unless they obviously belong together (such as accounts and their contacts).