Accounts and Security

The SAP Sourcing application must ensure that only properly authenticated users access the system, and that those users only see appropriate documents and are only able to perform authorized actions. This section describes those mechanisms: the authentication of users, the mechanisms that associate those users with their rights and roles, and support for system access click-through access terms.

At the simplest level, a user belongs to one or more groups. A series of general rights are associated with those groups, and users can perform actions when one of the groups they belong to provides the necessary rights. In addition to this basic level of access control, sourcing documents define collaborator security. Each collaborator's role is defined in a document, for example, Reviewer, Owner, or Approver. Additional access rights are associated with these roles through Collaborator Role Definitions, and are granted to the users associated with that role in a document. Finally, Document Security Templates provide the ability to define default collaborator associations when new documents are created.

For information about directories, see Directory Configuration.

Security Overview: Assigning Rights and Roles to Users

After you define Buy-side User Accounts, you must associate the users with their rights. All actions in the system are controlled by access rights. These range from basic class-level actions (which determine whether a user can view Contracts or edit Projects, for example) to more role-based actions (which determine whether a user must be the Document Owner to publish an RFP, for example). The system performs validation to determine that a user performing an action has the required rights. A user's set of rights is a combination of rights specifically assigned to that user, rights assigned to Groups of which the user is a member, and rights associated with the role the user has in a specific document (generally, as a collaborator). This section describes how those rights are defined, how they are associated with users, and how the system grants or denies access based on that collection of rights.

Access Rights and the Trust Barrier

Before examining the details of access rights and their usage, it is important to understand the basic security concepts used in the SAP Sourcing system.

When a user attempts to perform an action through the user interface (such as viewing an RFx or canceling a project) the security framework, using a trust barrier model, ensures that the user has the rights to perform that action.

For example, a user attempts to publish an RFx to suppliers. To process this action, the system validates that the user has the rights required to publish the RFx. Once this validation is completed, the user is considered to be inside the trust barrier. The system then performs any additional steps necessary to complete the request, without requiring the user to have additional rights.

Subsequently, the system must open the supplier objects representing each of the invited suppliers to retrieve information required for delivery of the invitation e-mail. Accessing the supplier objects is considered as work the system needs to do fulfill the user's request. The supplier objects are accessed on a trusted basis, without validating that the user has view access to supplier records.

The trust barrier approach is designed to implement security from a user's perspective, making it easier to implement and administer. Requiring users and administrators to understand all the objects accessed by the system “behind the scenes” to correctly assign security rights would be extremely complicated. The trust barrier model provides effective security with simplified administration.

Access rights are validated in the SAP Sourcing framework system, and are not implemented at the database level. This reduces the complexity of managing the security model, and ensures that access checks are applied to objects even when they are retrieved from in-memory cache instead of the database.

Class-Level Access Rights

Access rights begin with basic class-level operations: the ability to View, Edit and Create objects are defined separately for each class of object in the system. A user might be able to create projects but not create RFPs, for example. For sourcing documents, the additional rights of Create Template and Cancel are defined. For categories and menu options on the Setup page, a Setup right is also defined.

These class-level access rights are grouped into Security Profiles. A class-level Security Profile defines settings for View, Edit, Create, and where applicable, Create Template and Cancel for each class of object in the system. Since there are a large number of object classes, the settings in a Security Profile are organized into Access Groups. This is strictly a convenience and does not affect the definition or granting of rights. The Show Only drop down list displays the permissions for each group.

The system has a defined set of classes, so the set of Access Rights is not user-configurable. The application of these class-level rights is detailed below, but the pattern is straightforward. A user must minimally have the right to View, Edit, Create, or Create Template on a class when attempting to perform that action directly from the user interface.

Role-Level Access Rights

The second type of Access Right is role based: a user's ability to perform a function is based on the user's collaborator role in a specific document. Sourcing documents support the assignment of one or more document collaborators, as follows:

Each collaborator can be a single user, a user group, or a company.
Each collaborator is assigned a role for that document, and as noted above, the role determines the role-level access rights for this document.
A single user may have several roles in the document, based on multiple assignments as an individual, group, or company collaborator for that document.
In addition to the security component of collaborator assignments, including users as collaborators enables their participation in the system's collaboration functionality, such as showing events related to the document in the users' To Do, Alert and Discussion channels. A flag on the collaborator entry specifies whether alerts and notices should be sent to the collaborators represented by the entry.

To sum up, class-level access rights, described in the previous section, identify a user's rights with respect to an entire class of objects (for example, all RFxs), but role-level access rights describe the user's rights regarding a specific object (for example, the single RFx in which the user is assigned a collaborator role). Since the rights attached to the user's role affect a single object, and not the entire class, they are referred to as object-level rights in the administration of the system.

Object-level rights cover some of the same actions that class-level rights control, and, as indicated in the picture below, some additional rights.

For Create and Create Template actions, the document does not exist, and therefore has no assigned collaborators. Therefore, the class-level rights alone govern whether the operation can be performed.
For View and Edit actions, it is first necessary to have the rights at the class level, and then also at the role level. This means that the user must be either an individual or a group-level collaborator in a document (which is the only way to obtain the role-level rights) to view or edit a sourcing document.
For higher-level actions controlled by the role-based rights (for example. publishing an RFx), it is necessary to have class-level Edit rights (the action of publishing changes or edits the state of the RFx document) and then the specific right at the role level (in this case, Publish). Each of these higher-level rights is explained later, identifying how they are used in the application.

Master Data objects and Queries and Reports also support role-based object level rights, with a slight variation. For sourcing documents, a user has no object-level rights unless the user is explicitly included as a collaborator on the document. For Master Data and Query objects, the assumption is that a user's class-level rights provide the appropriate level of security. Additionally, these objects generally support only the basic actions of Create, View, and Edit. Therefore, the assignment of collaborators to those objects is optional. In fact, in most cases, the UI does not provide a mechanism to assign collaborators.

Query objects are the exception to this rule: each has an Access tab that allows the assignment of collaborators. If no collaborators are assigned to the object, all users with appropriate class-level rights are granted access. This is different than with business documents; a business document without collaborators cannot be accessed by anyone other than its creator. Once a collaborator is assigned to a query object, it is assumed that this particular object requires object-level access control, and therefore should behave like a business document, in that only a user with both class-level and object-level rights should be granted access. A Report object represents each report in SAP Sourcing. This mechanism allows specific reports to be restricted to a subset of users, even if those users are able to see other reports. The model simplifies administration, since it is only necessary to define collaborators for the limited set of reports that need highly controlled access.

For Master Data objects, all users are typically given View access to all Master Data classes, and the smaller subset of the user population that is responsible for managing the Master Data is assigned to a Group and given Create and Edit access to those classes. Similarly, all users have class-level View access to reports and lists (see Query Definitions and Query Groups), and the subset responsible for creating and maintaining reports is assigned to a group and given Create and Edit rights for those classes. For more restricted reports and lists, the Access tab is used and collaborators are assigned to limit the visibility of the reports as required.

Object-level access rights are also grouped into Security Profiles.

The following objects are also used to configure and administer the assignment of access rights:

Object	Usage
Security Profiles	Group and organize individual access right settings.
Buy-side User Accounts	Provide first-level assignment of class-level access rights for a user.
Groups	Extend the set of rights that are granted to users. Users can belong to one or more groups.
Collaborator Role Definitions	Define the object-level rights granted to collaborators acting in specific roles.
Document Security Templates	Provide a mechanism to define default collaborator assignments for new documents.

Each of these objects can be imported and maintained from the Setup page.