Access Control Lists 

Access control lists (ACLs) in cFolders, cProjects, and xRPM are used to define authorizations at object level.

·        Objects in cFolders are: collaborations, areas, folders, documents, status profiles, and user groups. There are six authorization activities: read, write, create, administration, delete, and none. It is also possible to create authorizations that depend on the status of an object. Authorization can be granted to users, user groups, and roles.

·        Objects in cProjects are: project definitions, phases, tasks, checklists, checklist items, project roles, and documents. There are four general authorization activities: no authorization, admin, write, and read. There are three authorization activities for project definitions only: evaluate, resource management, and accounting. Staffing management and candidate management are also available for project roles. Authorization can be granted to users, user groups, HR organizational units, and roles.

·        Objects in xRPM are: portfolios, buckets, items, reviews, collections. There are four general authorization activities: no authorization, admin, write, and read. There is one additional activity: owner. This activity simply documents that the user assigned is the person with business ownership of the specified object.

The administrator (creator) of the individual object maintains the ACLs. The first administrator can define additional administrators, or give write or read authorization, for example, to other users. The transition from role-based authorization to ACLs is as follows: If you have authorization to create an object, for example a collaboration or a project definition, as defined by your SAP role (see Authorization Objects and Roles in the cProject Suite), you are automatically the ACL administrator for the object you create. You can then add other users to the ACL list.

For more information, see the SAP Library under mySAP Business Suite → mySAP Product Lifecycle Management → SAP cProject Suite →

·        Collaboration Folders (cFolders) →  Authorizations

·        Collaboration Projects (cProjects)→ Authorizations

See also the section below, “Authorization Check”.

Superusers

cFolders and cProjects both have a superuser concept that overrides ACL authorizations. For more information, see the solution management content for:

·        cProjects under Solutions → mySAP PLM → Configuration Structures → SAP cProject Suite 4.00 → Basic Settings for cProjects → Business Customizing → Granting Administration Authorization for an Object.

·        cFolders under Solutions → mySAP PLM → Configuration Structures → SAP cProject Suite 4.00 → Basic Settings for cProjects → Business Customizing → Setting Up Administrators for cFolders.

Users who have the SAP_ALL authorization profile, which is generated automatically, also have the superuser role.

Authorization Check in cProject Suite

Prerequisites

You have implemented SAP Notes 688997 and 788139.

Authorization Check Sequence for cProjects and cFolders

Authorizations for an object are inherited from top to bottom in the project hierarchy (cProjects) and in the collaboration hierarchy (cFolders). They can also be assigned explicitly to each object. When the system carries out an authorization check, it first analyzes direct authorizations to an object and if none exist, it checks whether there is an inherited authorization. The system executes this process for the different authorization holders until an authorization is found. The system checks the authorization holders in the following order:

       1.      Users

       2.      User groups

       3.      Organizational units (cProjects only)

       4.      Roles

Individual users take precedence over user groups, user groups take precedence over roles, and so on. This also applies to inherited authorizations. This means that, for example, a user’s inherited authorization takes precedence over a user group’s direct authorization.

If a user is assigned to an object, for example, via several user groups, the most extensive authorization is valid.

A user is assigned to user groups A and B simultaneously. User group A has read authorization for a project definition, and user group B has write authorization for the same project definition. The user therefore has write authorization for the project definition.

 

Additional Information on ACLs in xRPM

You can either assign authorizations directly to a user or the user inherits them from parent business objects. Authorizations that are directly assigned always override inherited authorizations. The following hierarchy is used to determine authorization inheritance:

·        Portfolio → Bucket

·        Bucket → Bucket

·        Bucket → Item

·        Bucket → Review

·        Bucket → Collection

The following activities are supported on the above business objects:

·        None: The user to which this activity is assigned has no authorization for the business object.

·        Read: The user to which this activity is assigned has authorization to read the data of the specified business object.

·        Write: The user to which this activity is assigned has read authorization and also has authorization to change the data of the specified business object.

·        Admin: The user to which this activity is assigned has write authorization. He or she also has authorization to assign ACLs to other users for the business object, and can perform the additional activities specific to the following business objects:

¡        Portfolio: Create/delete and administer all business objects below the portfolio.

¡        Bucket:  Create/delete and administer items, reviews and collections assigned to the specific bucket. Reassign items to other buckets for which the user also has administrative access.

·        Owner: The user to which this activity is assigned is identified as the business owner or responsible person of the specified business object. This activity is a purely informative activity and provides no specific authorizations for the business object.