Sap Crm Access Control Engine 2j3d1v

SAP CRM Access Control Engine

ACE (Access Control Engine) - Introduction  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 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 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 access to individual business objects and the usage of those business objects. This means that you can define which s see which business objects, and whether those s 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.  s only see the business objects to which ACE grants them access. However, s 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. 2

Features • •

•

• • •

•

ACE provides an istrative tool for all rights and rules that influence access control. The can assign these rights and rules to s and roles. ACE s changing integration in business operations, such as changing the role or organizational unit. The new access control for s is calculated in day-today operation or asynchronously (time-shifted). If a reorganization affects a large number of participants, an istration tool s the changes to access control. ACE first gives s temporary full access to new objects that they create. When s save, the system starts a process in the background to calculate the rulesbased access control for these objects. The resulting 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 s, 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. 3

ACE-Enabled Objects

4

Differences Between ACE and the SAP Authorization Concept •

The SAP authorization concept is registry-based.

•

If there are new s or objects, you must make adjustments to the SAP authorization concept.

•

ACE 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 s or objects.

•

Since ACE is rules-based, it covers changed relationships and hierarchies.

5

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

6

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

7

The concept and implementation of CRM-ACE From the ’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 can see the object.

How the actor from both perspectives is determined is stored in a rule. Here are three methods defined: how to determine the actors from the , how to determine the actors for an object, and a method to specify which objects to take into in the first place. This is shown in the following pic:

8

The concept and implementation of CRM-ACE From the ’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 can see the object.

How the actor from both perspectives is determined is stored in a rule. Here are three methods defined: how to determine the actors from the , how to determine the actors for an object, and a method to specify which objects to take into in the first place. This is shown in the following pic:

9

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

The nice thing about the concept of ACE is that when you activate it it fills the ACE tables with data so it can later during runtime determine very fast who is allowed to see what data objects. Basically it determines beforehands for all s and for all objects what it’s actors are and stores this in tables. During runtime it knows your 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.

1 0

The concept and implementation of CRM-ACE Technical Details 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_: this method receives the id in the field im_usr_name and determines the actors for this which should be put in table ex_actor_id_table. Code samples will be below in this blog. 2. GET_OBJECTS_BY_FILTER: this method determines which objects to take into 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 itab 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

1 1

The concept and implementation of CRM-ACE So methods 1-4 are used during the activation of ACE and the last one is used when new objects are created. At the end of this blog you will find some code samples. 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. 2. CRM_ACE_XX_UCT: in this table all s with all their ACE_GROUP_Ids (=all their actors) are stored 3. CRM_ACE_XX_ACL: here all object Ids with their actors (in the form of the ACE_GROUP_Ids) are stored. From these tables you can easily see how ACE internally works: it knows your s, then reads in the context table (UCT) your acegroup 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.

1 2

The concept and implementation of CRM-ACE Performance Does ACE boost the performance of your system? Seen the logic of the tables above, it should. However unfortunately the answer is no, or maybe just a very little. When you search for business partners, in the background it still retrieves all business partners, and then at a later stage it limits the result list according to the ACE rules. So from that point in time the result list is smaller, but the first search already spoiled the response time. But maybe in future releases SAP will improve the logic of searching in the PCUI so it first reads the ACE tables, and then the other tables. In most SAP systems this will be quicker, depending on how the employees are mapped to the business partners.

1 3

THANK YOU www.infosys.com The contents of this document are proprietary and confidential to Infosys Limited and may not be disclosed in whole or in part at any time, to any third party without the prior written consent of Infosys Limited. © 2011 Infosys Limited. All rights reserved. Copyright in the whole and any part of this document belongs to Infosys Limited. This work may not be used, sold, transferred, adapted, abridged, copied or reproduced in whole or in part, in any manner or form, or in any media, without the prior written consent of Infosys Limited.