SAP CRM Access Control Engine

ACE (Access Control Engine) - Introduction

2
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.




Features
3
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 a 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-Enabled Objects
4
Differences Between ACE and the SAP Authorization Concept
5
The SAP authorization concept is registry-based.

If there are new users 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 users or objects.

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

The concept and implementation of CRM-ACE
6
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 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.


The concept and implementation of CRM-ACE
7
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 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.


The concept and implementation of CRM-ACE
8
From the users 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: how to determine the actors from the user, how to determine the actors
for an object, and a method to specify which objects to take into account in the first
place. This is shown in the following pic:



The concept and implementation of CRM-ACE
9
From the users 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: how to determine the actors from the user, how to determine the actors
for an object, and a method to specify which objects to take into account in the first
place. This is shown in the following pic:



The concept and implementation of CRM-ACE
1
0
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 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 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.



The concept and implementation of CRM-ACE
1
1
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_USER: this method receives the userid in the field
im_usr_name and determines the actors for this user 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
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 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



The concept and implementation of CRM-ACE
1
2
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 users 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 users,
then reads in the user 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.



The concept and implementation of CRM-ACE
1
3
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.




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.