Show TOC

Function documentationSecurity Profiles Locate this document in the navigation structure

 

A security profile is a set of rights and restrictions that can be associated with a user or group of users. The security profile determines the actions (such as viewing, creating, and editing) that a user can perform on various resources, such as sourcing documents and master data.

A security profile can be designated for buy-side users only, sell-side users only, primary contacts only, or all users. You assign security profiles to groups of buy-side users and to individual sell-side users. Security profiles are also assigned through Collaborator Role Definitions.

SAP Sourcing provides a set of default security profiles. You can edit these profiles and create new ones.

Security Profile Overview

A security profile is a collection of settings for access rights. Each security profile can be either a class-level profile or an object-level profile. Class-level profiles define settings for all class-level rights, and object-level profiles define settings for all role-based rights. For more information about class-level and object-level access rights, see Accounts and Security.

Each right in a security profile has a configurable setting of Allow, Deny or Not Set. The following review of access rights explains how to use these settings:

  • The system first validates class-level rights, and then validates object-level rights. Class-level rights come from the Security Profiles assigned to the user, and from all of the Groups in which the user is a member.

  • The software merges these rights. If any one of these Security Profiles includes an Allow setting for the right being tested, the user is granted access at the class level, and validation proceeds to the next step. The presence of at least one Allow, regardless of whether Deny settings are also present, is sufficient to pass the access test.

  • If access is granted at the class level, authorization proceeds to the object-level rights. Again, the software merges all of the relevant Security Profiles. In the case of object-level security, these profiles come from all collaborator roles assigned for this object either directly to the User or to a Group in which the user is a member. If one or more Allow settings are found at the object level, the system grants access. Again, the test is for the presence of one Allow setting; it does not matter if Deny settings are also present.

  • Rights must be granted at both the class level and the object level for the security framework to authorize the action.

A common example is the inclusion of read-only collaborators on RFPs who may be active collaborators on other RFPs. These users are defined with class-level rights for both View and Edit on RFPs, which may be assigned either to them as a user or to a group where they are a member. If the role used when they are assigned as a collaborator to a specific RFP includes only View access, they will be read-only collaborators. If the role includes both View and Edit rights, they will be able to both view and edit that RFP.

Security Profiles can have an Internal Type. The possible types are:

  • Default Buy Side User

  • Default Sell Side User

  • Primary Contact

  • All Users

These settings facilitate the defaulting of profiles to a population of users. Buy-side users have Default Buy Side User and All Users profiles by default; it is possible to add other profiles and to remove any of the default profiles (except All Users profiles) through the User object. Similarly, Sell-side users get the Default Sell Side User and All Users profiles. Any Sell-side primary contact automatically gets the Primary Contact profiles.

A number of class-level Security Profiles are installed by default with the system. The following profiles apply to buy-side users:

  • Application User

  • Clause Administrator

  • Contract Manager

  • Contract Reviewer

  • Contract Template Manager

  • Duet Manager

  • Duet User

  • MAViewer

  • ProjectCreator

  • Projects Manager

  • RFQuick User

  • Supplier Administrator

  • System Administrator

  • UDOOperator

  • UDOViewer

  • XPress Manager

  • XPress User

For a complete description of these security profiles, navigate to   Setup   System Administration   Security Profiles   and chooseOK.

The following profiles apply to sell-side users:

  • Supplier

  • Supplier Manager

  • Application User (applies to both buy-side and sell-side users)

Object-Level Rights

The link between a collaborator role and a Security Profile is made through Collaborator Role Definitions. Each collaborator role is associated with one and only one Security Profile. Each collaborator assignment on a sourcing document is given a role, and these roles correspond to Object Level Security Profiles as defined in Security Profiles. Examples include Document Owner, Document Reviewer, and Document Sponsor.

The basic use of View and Edit at the object level is generally analogous to the use of these rights at the class level, with the exception that an individual user's privileges will vary from document to document based on their collaborator association with the document. The object level, however, introduces a number of additional rights that are used in specific ways by the application.

Right

Usage

Change Owner

There is a special attribute in sourcing documents for the document owner, connected to the collaborator assignment with Document Owner role. Changing the owner of a document requires the specific Change Owner right.

Change State

Change State is used to control the Change Phase operation for a sourcing document, except for an RFx, which uses both Change State and Publish rights to restrict Change Phase operations.

Change Schedule

Required to change scheduled planned dates.

Approve

The RFx includes a Waiting For Approval phase, with the ability to designate which collaborators need to approve the document before publication. A user needs the Approve right in order to approve the document.

Publish

In order to Publish an RFx to suppliers, the user needs the Publish right. Since this is done in conjunction with changing the phase to Open for Response or Open for Review (if this phase is configured), this operation requires both the Change State and Publish rights.

Since each of the actions described above changes the associated sourcing document, the user must have the Edit right at the object level in addition to the specific right.

Access Rule Exceptions

There are several exceptions in the system where access is controlled through different mechanisms. In some cases, this is a temporary behavior in which the control is based on an existing role or right to avoid schema impacts between releases.

In most other cases, the exception is related to controlling access to features on the sell side, where object-level rather than class-level granularity is required. Exceptions exist here because there is no concept like collaborators for the sell side, and therefore no mechanism to assign the appropriate object-level rights. The table below outlines the current exception cases, and what controls access in each case.

User

Task

Control Method

Buy

Accept Request for invitation to upcoming events

User must have Document Owner role.

Change Proposal state to Preliminary or Firm

User needs Supplier Manager role, which is given automatically to the Supplier Primary Contact user only.

Buy

Accepting supplier registration and data modification requests

User needs Supplier Administrator role.
Denying Access

Since the presence of a single Allow setting at both the class and object level is sufficient to grant access, ensuring that actions are explicitly denied requires careful setup. Typically, the best approach to controlling a specific right (for example, editing Cluster configuration objects or approving an RFP) is the following:

  1. Determine whether this right should be controlled at the class level (that is, whether it should have the same settings for all documents of the class, or different settings based on the document) to determine whether to control the Class or Object Security Profiles.

  2. Select the Not Set value for this right in all generally used Security Profiles.

  3. Create two new Security Profiles, which include Not Set for all other values, to avoid side effects. In one Security Profile, specify Allow for the right in question; in the other, specify Deny for the right.

  4. Do one of the following:

    • For a class-level right, consider assigning each of these two settings to a distinct Group, and put the users that you want to be denied in the one with the Profile that specifies Deny for the right, and the users you want to allow in the other.

    • For an object-level right, follow the same pattern with two collaborator roles.

      This will ensure that approval and denial are tightly controlled and easily managed.

For more information about access, see Accounts and Security.

Features

Field Help for Security Profile Page

Function

Description

Inactive

Check this box to indicate that the security profile is inactive and unavailable for use.

Internal Name

Type an internal name for the profile.

Display Name

Type a display name for the profile.

Object Level

Check this box to indicate that the security profile applies to a single business object.

Restrict Access

Check this box to indicate that the security profile should have restricted access. Only a user whose Assign Restricted access right is set to Allow on the Access Rights page can assign other users to a Restricted Access profile.

Category

Select a category for the security profile. Options include System, Buy-side, Sell-side and None.

Internal Type

Select an internal type. Options include Default Buy-Side User, Default Sell-Side User, Primary Contact, and All Users.

Description

Type a description for the system profile.

Activities

Creating a Security Profile

To create a security profile:

  1. Choose Setup in the toolbar at the top of the page.

  2. Choose the System Administration tab, under theAccounts and Security section, select Security Profiles.

  3. On the Security Profile List page, choose Create.

  4. On the Security Profile page, fill in the fields with basic security profile information.

  5. Choose the Access Rights tab. This page determines the permissions to various types of resources, which are sorted into access groups.

    Note Note

    Access rights and access groups are system data and cannot be customized.

    End of the note.

  6. From the Show Only dropdown list, select the access group for which to set access rights.

  7. In the Access Rights table, use the radio buttons to select access rights. For each right in the profile, you can configure a setting of Not Set, Deny, or Allow.

  8. Choose Save in the toolbar.

Changing a Security Profile

  1. Choose Setup in the toolbar at the top of the page.

  2. Choose the System Administration tab, under theAccounts and Security section, select Security Profiles.

  3. On the Security Profile List page, select All Security Profiles, All Class Level Security Profiles, All Object Level Security Profiles, or All Inactive Security Profiles from the dropdown list and choose the profile to edit.

  4. On the Security Profile page, choose Edit in the toolbar.

  5. Edit any fields.

  6. Choose the Access Rights tab. This page determines the permissions to various types of resources, which are sorted into access groups.

  7. From the Show Only dropdown list, select the access group for which to edit access rights.

  8. In the Access Rights table, use the radio buttons to select access rights.

  9. Choose Save in the toolbar.