User Access Via The Access-ACE

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
developer’s 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 4
Company
Object 2 Object 5 User
Object 3 Object 6 Object
action
Brand Owner
Partner 1 Partner 2
Channel Manager Partner Manager Partner Manager
Partner Employee 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
organization‘s customer orders only; no further restrictions. View, edit,
etc. own organization‘s 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 Actor Type Object GetActors GetActors GetOb-
(Rule ID) Type FromUser FromObject jectsByFilter
MyLeads Contact Lead UserS LeadSPartner- *
Contacts Contacts
MyCompa- Partner Lead UserSPartner- LeadSPartner- German
niesLeads Company Companies Companies 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 User Group Object Type Rule Action
R314 All Partner Roles Lead MyCompaniesLeads Read
R315 Partner Manager Lead MyCompaniesLeads Change
R316 All Partner Roles Lead MyLeads 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
Multiple objects check
Get access control list for some objects
Management interface:
Inform ACE about new objects (call synchronously if possible)
Inform ACE about changed objects
Authority mode interface:

Informs about states of the ACE

Overview Section A
Summary Section D
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
SAP Authorizations
Based on authorization objects
Basis authorization concept
Reaches down to transaction,
User
field, and field value level
Role
object class
authorization object
authorization
Dynamic Authorizations authorization fields
(ex. display, change)
Framework to determine user

dependent access rights on Dynamic
object level Authorizations
Portal
Application can check access Portal Role A
rights for actions on business

User 1
objects User 2
Object 1
action Object 2
Company 1 action Company 2
Object 3

Building Subset of Users
ACE Role User

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

4
R3
R3
R4
R4 6

Building Subset of Objects
ACE
Objects Object Filter
Objects returned by an object filter
Lead 01
F1
Lead 02
Lead 03
Lead 04
F2
Lead 05
Lead 06
Lead 07 F3
Lead 08
Objects not under ACE control Lead 09

Lead 10 F4
Lead 11
Lead 12

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
User- ACE
ACE Role User Object- Objects Object Filter
User Groups Context
Lead 01
1 F1
Gr1
Gr1 R1
R1
Lead 03
2 Lead 04
F2
Gr2
Gr2 Lead 05
R2
R2
3
Lead 06
Lead 07 F3
4
R3
R3
Actor Lead 10 F4
Business function to calculate the

User/Object Context

Definition of Rule
4
5
Lead
3 F1
1
Parts of a Rule: 2
1. User Context: GetActorFormUser()

2. Actor Type
3. Object Context: GetActorFormObject()
4. Object Type
5. Filter: GetObjectByFilter()
Rule
Rule ID Actor Type Object GetActors GetActors GetOb-
Type FromUser FromObject jectsByFilter
MyLeads Contact Lead UserS LeadSPartner- *
Contacts Contacts
MyCompa- Partner Lead UserSPartner- LeadSPartner- German
niesLeads Company Companies Companies Leads

Definition of Right
4
1
2 Lead
Gr1
Gr1 Role
Role
3
Parts of a Right:
Lead 01
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
R314 All Partner Roles Lead MyCompaniesLeads Read
R315 Partner Manager Lead MyCompaniesLeads Change
R316 All Partner Roles Lead MyLeads 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 Access Control List
* 1 1 *
ACE Group ID ACE Group ID ACE Group ID
User Actor Business Object ID
Right 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 Section A
Summary Section D
Overview of Authorizations and ACE
SSO
Authentication
Portal Role
Portal User
Authorization EP
Portal Content
Application
CRM User
Implicit
Authorizations
Access
CRM Other
Control
Business Partner concepts
Engine
CRM
Authorization
Objects R/3

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 user’s roles change, the administrator has to refresh the user-
context 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: Retrieve all objects to be activated
1. Get all objects, using the

filter Insert objects into the work table,
block by block
2. Calculate all ACL-entries
in small parallel Create reporting data
processes
Read N blocks of 100 objects at most
N
Enqueue objects in this block and Enqueue objects in this block and
proceed with activation proceed with activation
Update information on the Update information on the

success/failure as well as reporting success/failure as well as reporting
data data
Commit the work in this LUW and Commit the work in this LUW and
dequeue objects in the block dequeue objects in the block

Runtime Authorization Check
Some processes call the ACE

authorization check very often for the
CHECK_SINGLE_OBJECT_GUID /
same object CHECK_MULTIPLE_OBJECTS_GUID
There is a runtime
cache for checked
ACE entries UserObjects- CL_ACE_USER_OBJECTS_CACH
Cache E
This cache is a
session cache CL_ACE_RUNTIME_STORE
Runtime-
The runtime store is Store
only for objects created
in the same session DB e.g. read from ACL
Table
XX_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
2b 1b
1a
2a

Dynamic Authorizations – Example Cont’d.
Portal Role
Manager
Sales Area
Maier
User
1600/99/34 Object
Schmitt
1010/99/32
Employee
Müller
1520/99/40
Elektro-
Heinz
Rights
R007 Manager Customer MySalesAreasCustomes Full
R008 Empoyee Customer MySalesAreasCustomes Read

Portal role consists of applications user is able to work with

No application available in the role Î no access at all
User is assigned to portal role
Different portal roles enable different authorization on role level
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
Application/CRM offers authorization checks via Basis Authorization
Authorization object is available, application does checks on authorization
objects, and user is assigned to authorization objects

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
First 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


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.
A role specific application may also be used in combination with
underlying authorization concepts to implement an "ideal solution"
This 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


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
The 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

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 cont’d.
Example of External Matrix
Rights/Roles
Portal Administrator
Partner Lead Sales
Roles Manager Manager Manager
(web support
center)
Partner Management Rights
Partner Profile Management R/M/D/E R R R/M/D/E
Account Management R/M R R/M/D R/M/D/E
User Management R/M/D/E
Sales Cycle
Activities R/M/D R/M/D R/M/D R/M/D
Leads R R/M/D R
Opportunities R/M/D R/M/D/E
Orders (B2B-Shop) R/M/D R/M/D/E
Legend: R = Read only 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) Activation for testing

Testing
Results of final ACE rights activation

Overview
Testing
Runtime monitoring of ACE authorizations

Overview
Testing

ACE Right Definition Process Detail
Now let’s 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 ID’s/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’ ID’s 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.

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 BP’s. 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 group’s and ID’s.

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

LEAD_CHP_ENDCUST_EMP
a) PARTNER EMPLOYEE: END CUSTOMER CHANGE

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 company’s end
customers. The business partner must have the relationship "is
end customer of" his or her own company

LEAD_CHP_PROSP_EMP
a) PARTNER EMPLOYEE: PROSPECT CHANGE

relationship type "is contact person for” and the portal role
"Partner Employee", access (read- and write authorization
(ACT_GRP_CHANGE)) to all of the user’s company’s 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).

CHP_CONSUMER_EMP
a) PARTNER EMPLOYEE: CONSUMERS DISPLAY

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 Apple’s than I would assign myself as a contact person at Ace.

Working with the Business Package

Create Ace Apple’s 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

Overview Section A
Summary Section D
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: the basis authorization object does not grant access “at all”, then
no ACE rule can change this
Refine: 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 Developer‘s 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.

User Access Via The Access-ACE

Uploaded by

Document Information

Original Description:

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

User Access Via The Access-ACE

Uploaded by

Copyright:

Available Formats

Session ID: AGS206

User Access via the Access

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 2

As a result of this workshop, you will

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 3

Development / Security Section C

Object 3 Object 6 Object

Channel Manager Partner Manager Partner Manager

Partner Employee Partner Employee

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 5

Typical relations of business objects to a partner company

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 6

The relation “MyCompaniesLeads”

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 7

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 8

 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

Covered by existing authority concept

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 11

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 12

After some changes in the rights tables the administrator has to

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 13

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 14

To develop a rule, the scenario owner has to develop three

The Channel Management team has to be involved with the

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 15

For application integration SAP provides three kinds of interfaces:

 Authority mode interface:

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 16

Development / Security Section C

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 18

 Framework to determine user

rights for actions on business

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 19

ACE Role User

User not under ACE control

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 20

Objects not under ACE control Lead 09

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 21

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 22

Business function to calculate the

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 23

1. User Context: GetActorFormUser()

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 24

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 25

No new roles for authorization necessary

Add new rights without code modification in the business object

Use of business relations make the coding of rules very easy

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 26

Calculate every rule by every authorization check?

Structure of the database cache

User Actor Business Object ID

Additional memory caches exist

There are processes working with this data:

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 27

Development / Security Section C

© SAP AG 2005, SAP TechEd ’05 / AGS206 / 29

The first steps are:

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

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

Authority mode interface:

Framework to determine user

Portal role consists of applications user is able to work with

By doing as much of the restrictions in the backend using basis

(Preliminary) Activation for testing

Results of final ACE rights activation

Runtime monitoring of ACE authorizations