Hi,
There is some explanation of this in the Help text which I am posting here. Finally I will try and give an example which might clear out things further.
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:
1. 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.
2. 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.
3. 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.
4. Rights must be granted at both the class level and the object level for the security framework to authorize the action.
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.
Now coming to an example, at the Class level there is a function called Analytics which really is not an area in SAP Sourcing that you want to use ir keep in scope. So what can be done is that all the sub profiles that fall under Analytics can be given a value = Not Set. This includes Accounts Payable Type, Customer Master Data 1 and so on.
Whereas in the Workbench, you want certain roles to have permissions to edit and certain roles to not have the permissions. Hence you would want to use Deny value for those roles as opposed to Not Set.
Not sure if this helps
Vikram
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.