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