Session ID: AGS206: User Access Via The Access Control Engine (ACE) in Mysap CRM

Session ID: AGS206
User Access via the Access Control Engine (ACE) in mySAP CRM
Contributing Speaker(s) Larry Justice

Platinum Technical Consultant, SAP America
SAP AG 2005, SAP TechEd 05 / AGS206 / 2
Learning Objectives
As a result of this workshop, you will be able to:

Understand an overview of ACE functionality Understand the underlying architecture for ACE Have better understanding of developing and both from the developers perspective and from a security perspective using ACE Have a better understanding of the impact that implementing ACE has on user access management in CRM 4.0
Overview Section A Architecture Section B Development / Security Section C Summary Section D
Channel Management
Portal Role Object 1 Object 2 Object 3 Brand Owner Object 4 Object 5 Object 6 Company User Object action
Partner 1
Partner 2
Channel Manager
Partner Manager Partner Employee
Partner Manager Partner Employee
Miller
Jones
Smith
Gold
Silver
Relations in the Business Typical relations of business objects to a partner company organization
Relation to Assign Access Rights The relation MyCompaniesLeads
The Actor (Org-Element) in the Relation
Use Cases in the Channel Management

Partner Employee can create, read, edit, and analyze accounts within his partner company. He can also read and edit (but not delete) accounts assigned by Channel Manager
Partner Manager Channel Commerce creates, reads, edits,

deletes, and analyses partner specific condition records
Partner Manager and Partner Employees are only allowed to

see their accounts (Relation: "is account of" / "has accounts")
Partner Manager has read access to leads where his organization is

the Sales Partner of this lead
Use Cases in the Channel Management Partner Manager has full access (create, read, edit, delete, analyze)
to opportunities created by himself or an employee of the own company
Channel Manager has only access to read, edit and analyze an

order (not to create or delete) for all orders of all partners. View own organizations customer orders only; no further restrictions. View, edit, etc. own organizations catalog (i.e. catalog with subscribed products) only; Product Subscription & Lead Time maintenance: Partner Manager Channel Commerce only
Limitations to the Uses Cases Covered by existing authority concept

The create action is not possible for ACE
Future Releases
Integration of BW and ACE is a point for future releases to analysis requirements Additional actions like negotiate or dispatch planned for future releases Validating rights for a creation or dispatch process planned a for future release
Rule Administration Administration of rules:

Actor type is the type of the organization element in the relation between user and business object GetActorsFromUser calculates the Actors to every user assigned to that right GetActorsFromObject calculates the Actors to every object returned by the GetObjectsByFilter
Rule Relation ID (Rule ID) MyLeads MyCompaniesLeads Actor Type Contact Partner Company Object Type Lead Lead GetActors FromUser UserS Contacts UserSPartnerCompanies GetActors FromObject LeadSPartnerContacts LeadSPartnerCompanies GetObjectsByFilter * German Leads
Rights Administration Administration of rights

In the most cases user groups are based on roles (portal-roles) Rules describe the relation between user and objects Actions are the combination of the single actions of read, write and delete
Rights Right R314 R315 R316 User Group All Partner Roles Partner Manager All Partner Roles Object Type Lead Lead Lead Rule MyCompaniesLeads MyCompaniesLeads MyLeads Action Read Change Full
After some changes in the rights tables the administrator has to activate the changes with an activation-tool
Definition of Rights Access Control List
Rule (Scenario) interface To develop a rule, the scenario owner has to develop three interfaces:
Determine actors from user Determine actors from business object Determine lists of objects in the focus of the rule
The Channel Management team has to be involved with the development of the rules for their use cases
Application Interface For application integration SAP provides three kinds of interfaces:
Runtime interfaces:
Single
object check objects check
Multiple Get
access control list for some objects
Management interface:
Inform Inform
ACE about new objects (call synchronously if possible) ACE about changed objects
Authority mode interface:

Informs
about states of the ACE
Architecture Overview Architecture:

Instance-based authorization Building subset of users Building subset of objects Using business relations to calculate authorization
Processes:
Database cache User context calculation Activating rights Session cache and authorization check Object creation Object changes
Authorizations in Channel Management Basis Authorizations

Based on authorization objects Reaches down to transaction, field, and field value level
SAP Authorizations
Basis authorization concept
User Role object class authorization object authorization authorization fields
(ex. display, change)
Dynamic Authorizations
Framework to determine user dependent access rights on object level Application can check access rights for actions on business objects
Portal
Dynamic Authorizations
Portal Role A
User 1
action
User 2 Object 1 Object 2 action Company 2 Object 3
Company 1
Building Subset of Users

ACE User Groups Gr1 Gr1 Role User 1 Roles known by ACE User Groups (R1 & R2)
R1 R1
2 Gr2 Gr2 R2 R2
Roles assigned to Users Example: User 5 has Role R3 and R4
3 User not under ACE control 4
R3 R3 5
R4 R4
Building Subset of Objects

Objects Objects returned by an object filter ACE Object Filter F1
Lead 01 Lead 02 Lead 03 Lead 04 Lead 05 Lead 06 Lead 07 Lead 08

F3 F2
Objects not under ACE control
Lead 09 Lead 10 Lead 11 Lead 12

F4
User- and Object-Context User-context

The functions GetActorFormUser() calculate the user-context Examples for types in the user-context:
Companies Org-Unit Position Sales
Area
We call this types Actor-Type We call the values in the user context Actor
Object-context
The function GetActorFromObject() calculate the object-context Examples for values in the object-context:
Companies Org-Unit
User- and Object-Context II

ACE User Groups Gr1 Gr1 Role User 1 UserObjectContext Objects ACE Object Filter F1
Lead 01
R1 R1
Lead 03
2 Gr2 Gr2 R2 R2
Lead 04 Lead 05
F2
Lead 06 Lead 07
F3
4 R3 R3
Actor Business function to calculate the User/Object Context

Lead 10
F4
Definition of Rule
4
Lead
1 3 2
5 F1
Parts of a Rule:
2. Actor Type
1. User Context: GetActorFormUser() 3. Object Context: GetActorFormObject() 4. Object Type 5. Filter: GetObjectByFilter()
Rule Rule ID MyLeads MyCompaniesLeads Actor Type Contact Partner Company Object Type Lead Lead GetActors FromUser UserS Contacts UserSPartnerCompanies GetActors FromObject LeadSPartnerContacts LeadSPartnerCompanies GetObjectsByFilter * German Leads
Definition of Right
4 1 Gr1 Gr1 Role Role 3 Lead 01 2
Lead
Parts of a Right:
1. User Group 2. Rule
3. Action: What kind of action can a user do with his objects 4. (Not Object Type, makes administration easy)
Rights Right R314 R315 R316 User Group All Partner Roles Partner Manager All Partner Roles Object Type Lead Lead Lead Rule MyCompaniesLeads MyCompaniesLeads MyLeads Action Read Change Full
Results No new roles for authorization necessary Add new rights without code modification in the business object code
Customer code used as an add-on
Use of business relations make the coding of rules very easy

Definition of actor types is very important task when using ACE in a project
Runtime Cache
Calculate every rule by every authorization check?
Good performance can be achieved for authorizations by pre-calculation (caching) rule results
Structure of the database cache

User Context ACE Group ID User
* 1
ACE Group ACE Group ID Actor Right ID

1 *
Access Control List ACE Group ID Business Object ID Action
Additional memory caches exist There are processes working with this data:
First authorization check User Context Activating rights ACL (User Context) Authorization check Cheating objects ACL Changing objects ACL
Overview of Authorizations and ACE
SSO Authentication Portal User Portal Role Portal Content Authorization EP
Application CRM User Implicit Authorizations Access Control Engine Other concepts CRM R/3
CRM Business Partner
Authorization Objects
First Authorization Check (User Context) The first steps are:

1. Is the ACE inactive? (CUSTOM) 2. Is this query a Friendly Call ? 3. Is the action to be checked supported by the ACE? 4. Is the object type to be checked relevant for the ACE? 5. Is the user an active ACE user?
Now ACE starts working with:

Is the user cached? (App-Server) Has the user context expired? (customizable; default value = 16 hours) Determining the active status
Remark:
App-server cache and database cache are the same
User Context Cache Calculating the new user context

1. Get all Roles of the user 2. Get all ACE-User-Groups of the user 3. Get all Rights for the user 4. List all different GetActorFromUser() functions 5. Calculate all different Actors 6. Create all new ACE-Group entries (Right-ID, Actor) pair 7. Change Entries in User-Context-Table
Create App-Server-Cache for user context Remark:

Start and end-time of a right is only used in the user context, not in ACL If a users roles change, the administrator has to refresh the usercontext manually
Activation of Rights and User-Groups The first step of activating is to copy the design-time data into the corresponding runtime tables
Changing ACE configuration has no influence on the runtime until they are activated
You find the list of active rights and user groups by using the deactivation value-help
Activating Rights (ACL- Calculation) Two separate steps:

1. Get all objects, using the filter 2. Calculate all ACL-entries in small parallel processes
Retrieve all objects to be activated
Insert objects into the work table, block by block Create reporting data
Read N blocks of 100 objects at most
Enqueue objects in this block and proceed with activation Update information on the success/failure as well as reporting data Commit the work in this LUW and dequeue objects in the block
Enqueue objects in this block and proceed with activation Update information on the success/failure as well as reporting data Commit the work in this LUW and dequeue objects in the block
Runtime Authorization Check Some processes call the ACE authorization check very often for the same object
There is a runtime cache for checked ACE entries This cache is a session cache The runtime store is only for objects created in the same session
CHECK_SINGLE_OBJECT_GUID / CHECK_MULTIPLE_OBJECTS_GUID
UserObjectsCache
CL_ACE_USER_OBJECTS_CACH E
RuntimeStore
CL_ACE_RUNTIME_STORE
DB Table XX_ACL
e.g. read from ACL
Runtime Changes of Business Objects All business objects under ACE control send change and create notifications to ACE There are two different calls from the business object to ACE
HandleNewObjects() HandleChangedObjects()
Two different calls are necessary, because of different processes
Creating New Object During the creation process, the following happens:
Write full access in the session runtime store Write the temporary ACL entry (Full control for the creator) in the DB Start a background process to calculate the new ACL entries
In the background process

List all Filter for this Object Calculate all used GetActorFormObject() functions using the Filter Calculate all actors for this object Write all new ACE-Group entries Write all new ACL entries Remove temporary ACL entry
Remark
The creator can directly access his created object(s)
Change Object During the change process the following happens:

Start a background process to calculate the changes of ACL entries
In the background process

List all Filter for this object Calculate all used GetActorFormObject() functions using the Filter Calculate all actors for this object Write all new ACE-Group entries Calculate the delta of ACL entries Write all new ACL entries Remove all unused ACL entries
Remark:
If only right independent attributes are changed, there is no write access to the DB
Dynamic Authorizations Example 1 Megan (User A, manager with a partner company) wants to see the leads assigned to her company
Business objects
Hierarchical structure of partner organization

Business objects
Dynamic Authorizations Example Rules to determine access for the lead

Rule 1: Check which contact person the lead is associated with Rule 1b: Look up primary partner company for contact person Rule 2a: Retrieve the contact person for user Megan Rule 2b: Look up primary partner company for contact person Rule 3: Compare partner companies, if identical: show lead to Megan
3 2b 1b
1a
2a
Dynamic Authorizations Example Contd.

Portal Role Manager Maier 1600/99/34 Schmitt Employee Mller 1010/99/32 1520/99/40 ElektroHeinz
Rights Right R007 R008 User Group Manager Empoyee Object Type Customer Customer Rule MySalesAreasCustomes MySalesAreasCustomes Action Full Read
Sales Area User Object

Portal role consists of applications user is able to work with
No
application available in the role no access at all portal roles enable different authorization on role level
User is assigned to portal role

Different
Application itself consists of implicit authorization

E.g.
Sales Order Management does not include Opportunity Management
Application supports authorization checks via ACE

Application
(resp. the assigned CRM object) supports ACE checks, the current user is activated for ACE checks, and corresponding ACE rule is activated object is available, application does checks on authorization objects, and user is assigned to authorization objects
Application/CRM offers authorization checks via Basis Authorization

Authorization
Different levels and possibilities of authorizations:

Top-down view
To
implement an authorization matrix, as proposed, there are several possibilities and dependencies, which have to be taken into account of all, there is the portal role definition. If the authorization matrix does not have a mark for a specific role-application combination, this particular application should not be part of the role definition at all. Therefore the user assigned to this role does not have the application available and therefore no authorization at all
First

Top-down view
Next
level is to use specific BSP application view to implement "functional" authorizations on UI level, e.g. remove a create button restrict this capability for a specific role. role specific application may also be used in combination with underlying authorization concepts to implement an "ideal solution" means for example, if you only have read-access to a certain object without the right to create new ones, but there is a create button available, this button can be completely removed by defining a corresponding BSP application view
A
This

Top-down view
Now
ACE comes into play, if activated and if necessary for a specific business process. Authorizations implemented via ACE using rules (which) and rights (how) define which documents a user (assigned to a certain role) may see and how these documents may be accessed. Currently implemented and available actions are write, read, and delete. ACE sits on top of basis authorization

Top-down view
Last,
but not least, the basis authorization can be used to define "overall" authorizations in the system. Here authorization objects assigned to users/user groups define what access is allowed role itself represents the center of all authorization, and it is used at each "level" (portal role definition, BSP application view, ACE, and basis authorization) as a kind of anchor in the authorization model/matrix
The
Comments about Basis Authorizations Basis authorization and ACE:

Basis authorization may be used best to define basis authorizations, e.g. a whole role should only have read access to a certain transaction or application. This should be implemented using basis authorization objects assigned to a role/user group (even if it could be accomplished via ACE) By doing as much of the restrictions in the backend using basis authorizations for the affected roles, the development work using ACE is simplified
Comments about Basis Authorizations Basis authorization and ACE:

If a certain role should only have access to a specific range of documents, e.g. only for a particular channel partner (<=> sales partner), then the ACE should be used implementing corresponding rules (which documents should be visible) and rights (how documents are accessible) In this case it is necessary to clearly define which characteristics (partner functions; relations; etc.) are used to determine the rule process (actors from user; actors from object) To come to such a clear technical definition, a list of business rules describing the business requirement in a matrix is extremely helpful A combination of both, basis and ACE, can be used, but from a business perspective it can increase user administration costs (duplicated effort; potential confusion of access modes used in complex roles; etc.)
ACE Right Definition Process Detail contd.
Example of External Matrix Rights/Roles

Partner Manager Lead Manager Sales Manager Portal Administrator (web support center)
Roles
Partner Management Partner Profile Management Account Management User Management

Sales Cycle
Rights R/M/D/E R/M R R R R/M/D R/M/D/E R/M/D/E R/M/D/E
Activities Leads Opportunities Orders (B2B-Shop)

Legend:
R/M/D R R/M/D R/M/D

R = Read only
R/M/D R/M/D
R/M/D R R/M/D/E R/M/D/E
R/M/D
E = Execute (reports, search) D = Delete M = Maintain
ACE Right Definition Process Detail Steps for coming from an authorization matrix to ACE-based authorizations access control on document level:
Authorization matrix generated by business department Translation of authorization matrix into ACE-related building blocks Customizing and implementation of ACE building blocks
Overview (Preliminary) Testing
Activation for testing
Results of final ACE rights activation

Overview Testing
Runtime monitoring of ACE authorizations

Overview Testing
ACE Right Definition Process Detail Now lets look at the actual screen shots involved in setting up ACE functionality. This involves both developers and security resources working together. The first part of the process involves a developer resource to do the configuration part
Log on to CRM Development Instance
Execute /nspro
Select SAP Reference IMG
Select Customer Relationship Management
Next select Basic Functions
Now select Access Control Engine
Next select User Groups
Click on Assign Users to User Groups
Setting Up Rules for IDs/Roles for ACE
Finally, we are in the proper part of the IMG, so:
The first step in the process is to assign the role or user IDs to an ID or role. In this situation, we are going to tie a user ID to a specific role. If you are going to assign it to a group of people, you would assign the backend Z BASIS security role as shown in the following Screen Shot

But in this case, we are going to assign the CRD_SARF2 user to the SAP_CRM_PARTNER _EMP group and assign the user group child type as U User since this is a user ID.
Setting Up Rules for IDs/Roles for ACE Unfortunately, currently there is no search for the User Group Child functionality, you have to know the ID or the BASIS role you wish to attach. Once this is completed, we have to decide what rules we wish to activate. For this case, we are going to make it so a CP can maintain, edit, change, display BPs. If this is the first time ACE is being used, you must enter the developers tool to activate the necessary groups and rules. For this scenario I have activated the following groups and IDs.
SAP_CRM_PARTNER_EMP User Group is Activated
Rules which have been activated LEAD_CHP_CP_EMP a) PARTNER EMPLOYEE: CONTACTPERS. CHANGE b) Account (ACCOUNTCRM) c) Partner employee (SAP_CRM_PARTNER_EMP) d) Grants the partner employee, as contact person with the relationship type "is contact person for" and the portal role Partner Employee, access (read- and write authorization (ACT_GRP_CHANGE)) to all end customer business activities. Here, the business partner must be a contact person, who in turn has the relationship "is contact person for" a business partner who has the relationship "is end customer of" his or her own company
Rules which have been activated LEAD_CHP_ENDCUST_EMP a) PARTNER EMPLOYEE: END CUSTOMER CHANGE b) Account (ACCOUNTCRM) c) Partner employee (SAP_CRM_PARTNER_EMP) d) Grants the partner employee, as contact person with the relationship type "is contact person for" and the portal role "Partner Employee", access (read- and write authorization (ACT_GRP_CHANGE)) to his or her own companys end customers. The business partner must have the relationship "is end customer of" his or her own company
Rules which have been activated LEAD_CHP_PROSP_EMP a) PARTNER EMPLOYEE: PROSPECT CHANGE b) Account (ACCOUNTCRM) c) Partner employee (SAP_CRM_PARTNER_EMP) d) Grants the partner employee, as contact person with the relationship type "is contact person for and the portal role "Partner Employee", access (read- and write authorization (ACT_GRP_CHANGE)) to all of the users companys prospects. The "Prospect" must be in an "is end customer of" relationship to the "Company" that the current partner employee is a contact person of. Or the "Prospect" is the "Company" itself, then the current user also has access ("to own company as prospect "; this is only of interest if the lead is used as a quotation for the channel partner itself).
Rules which have been activated CHP_CONSUMER_EMP a) PARTNER EMPLOYEE: CONSUMERS DISPLAY b) Account (ACCOUNTCRM) c) Partner employee (SAP_CRM_PARTNER_EMP) d) Grants the partner employee, as contact person with the relationship type "is contact person for" and portal role Partner Employee, access (read authorization (ACT_GRP_READ)) to all consumers. The business partner must exist in the business partner role "Consumer".
Working with the Business Package The security team will be involved in this activity Once you have activated the rights, let us create/modify the Business Package (BP) associated with the test user ID and then assign them a organization. Open up the BP associated with the user ID. (note, if you are assigning ACE rules to a specific role you must maintain the Role in the Role area of the following screen shot) In the BP you have open, maintain a Contact Person as well as the internet user role of the partner Once this is done, now assign user to the organization that he represents when he logs in. For example, if I am an employee at Ace Apples than I would assign myself as a contact person at Ace.
Working with the Business Package
Create Ace Apples BP and Associate crd_Sarf2 to it
Activating User Group SAP_CRM_PARTNER_EMP Back in the ACE Administration Tool: Select the user group to activate (here it is the SAP_CRM_Partner_EMP) Once this is completed successfully, then you will notice all of the condition traffic lights will be green as seen on the next slide.
Activating User Group SAP_CRM_PARTNER_EMP
Rights Have Been Activated
Final Step Back to the administration tool and the last thing needed to do is to refresh the user (note, if you use roles you do not have to do this) Once this is done, everything should be active for the test ID
Schematic View of what has been set up
Summary ACE functionality based on Rules, Rights and Roles in the portal and the backend system It is important for the developer team and security to work together during the initial configuration of ACE functionality Where ever possible use the capabilities of the basis authorizations in the backend system to simplify the development and use of ACE functionality It is very important to have an overall naming convention for the portal roles, the ACE user groups, and backend user roles BEFORE implementing ACE
Final Comments When ACE is activated initially, there is no access to any documents for an activated user as long as there is no ACE rule to grant access! ACE cannot extend authorizations granted by Basis Authorizations, but refine
Extend: Refine:
the basis authorization object does not grant access at all, then no ACE rule can change this if the basis authorization object does allow change, but ACE rule(s) does not user is not able to change object(s). So it can act as an additional filter of allowed access.
ACE can be used if authorization per object based on object attributes are required for different user groups
Further Information
Public Web:
www.sap.com SAP Developer Network: www.sdn.sap.com NetWeaver Developers Guide: www.sdn.sap.com/sdn/developersguide.sdn SAP Customer Services Network: www.sap.com/services/
Related SAP Education Training Opportunities

http://www.sap.com/education/
Questions?
Q&A
Feedback
Please complete your session evaluation. Be courteous deposit your trash, and do not take the handouts for the following session.
Thank You !
Copyright 2005 SAP AG. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. Development section content contributed by Matthew Parker, SAP America

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.


Session ID: AGS206: User Access Via The Access Control Engine (ACE) in Mysap CRM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Session ID: AGS206: User Access Via The Access Control Engine (ACE) in Mysap CRM

Uploaded by

Copyright:

Available Formats

Session ID: AGS206

Contributing Speaker(s) Larry Justice

SAP AG 2005, SAP TechEd 05 / AGS206 / 2

As a result of this workshop, you will be able to:

SAP AG 2005, SAP TechEd 05 / AGS206 / 3

Overview Section A Architecture Section B Development / Security Section C Summary Section D

Partner Manager Partner Employee

Partner Manager Partner Employee

SAP AG 2005, SAP TechEd 05 / AGS206 / 5

SAP AG 2005, SAP TechEd 05 / AGS206 / 6

Relation to Assign Access Rights The relation MyCompaniesLeads

SAP AG 2005, SAP TechEd 05 / AGS206 / 7

The Actor (Org-Element) in the Relation

SAP AG 2005, SAP TechEd 05 / AGS206 / 8

Use Cases in the Channel Management

Partner Manager Channel Commerce creates, reads, edits,

Partner Manager and Partner Employees are only allowed to

Partner Manager has read access to leads where his organization is

SAP AG 2005, SAP TechEd 05 / AGS206 / 9

Channel Manager has only access to read, edit and analyze an

SAP AG 2005, SAP TechEd 05 / AGS206 / 10

Limitations to the Uses Cases Covered by existing authority concept

SAP AG 2005, SAP TechEd 05 / AGS206 / 11

Rule Administration Administration of rules:

SAP AG 2005, SAP TechEd 05 / AGS206 / 12

Rights Administration Administration of rights

SAP AG 2005, SAP TechEd 05 / AGS206 / 13

Definition of Rights Access Control List

SAP AG 2005, SAP TechEd 05 / AGS206 / 14

SAP AG 2005, SAP TechEd 05 / AGS206 / 15

object check objects check

access control list for some objects

Authority mode interface:

about states of the ACE

SAP AG 2005, SAP TechEd 05 / AGS206 / 16

Overview Section A Architecture Section B Development / Security Section C Summary Section D

Architecture Overview Architecture:

SAP AG 2005, SAP TechEd 05 / AGS206 / 18

Authorizations in Channel Management Basis Authorizations

User 2 Object 1 Object 2 action Company 2 Object 3

SAP AG 2005, SAP TechEd 05 / AGS206 / 19

Building Subset of Users

Roles assigned to Users Example: User 5 has Role R3 and R4

3 User not under ACE control 4

SAP AG 2005, SAP TechEd 05 / AGS206 / 20

Building Subset of Objects

Lead 01 Lead 02 Lead 03 Lead 04 Lead 05 Lead 06 Lead 07 Lead 08

Objects not under ACE control

Lead 09 Lead 10 Lead 11 Lead 12

SAP AG 2005, SAP TechEd 05 / AGS206 / 21

User- and Object-Context User-context

SAP AG 2005, SAP TechEd 05 / AGS206 / 22

User- and Object-Context II

Actor Business function to calculate the User/Object Context

SAP AG 2005, SAP TechEd 05 / AGS206 / 24

SAP AG 2005, SAP TechEd 05 / AGS206 / 25

Use of business relations make the coding of rules very easy

SAP AG 2005, SAP TechEd 05 / AGS206 / 26

Structure of the database cache

ACE Group ACE Group ID Actor Right ID

Access Control List ACE Group ID Business Object ID Action

Overview Section A Architecture Section B Development / Security Section C Summary Section D

Overview of Authorizations and ACE