Delegated User Administration Using Attribute-Base...

ValAtanassov · ‎07-17-2023

Why is this feature important for you?

You are an administrator at SAP Cloud Identity Services, but the standard predefined administrator roles that are offered to you, such as Manage Users or Read Users, are not flexible or fine granular enough for your user management needs and scenarios. If you are looking for a solution to that problem, then you are in the right place.

Feature overview

Tenant administrators in SAP Cloud Identity Services are offered a predefined set of roles (authorizations) that provide a full set of permissions in a particular area. The administrators can get some roles assigned, but their scope (set of permissions) can’t be modified, and very often it’s too broad.

However, you may need to define authorization models with more complex restrictions for data access, like the so-called Attribute-Based Access Control (ABAC). So, with the need for finer granular separation of the administration work, the new feature of SAP Cloud Identity Services for admin authorizations based on policies (aka delegated administration for user management) comes as a solution for that need. In other words, administrators define custom authorization policies based on user attributes and assign these policies to other administrators or users, thus delegating them granular administrator rights. In this way, one administrator can have access to a subset of the users in the tenant and further to a subset of the attributes of these users.

So, this recently released feature offers the opportunity for delegating specific responsibilities for user management to different administrators by precisely limiting the user data an administrator can access and control. This helps to reduce manual administration efforts for user management and identity provisioning and avoid work disruption by leveraging the suite quality “consistent security and identity management” for an intuitive login process within your intelligent sustainable enterprise.

This fine granular access control is based on a generic Authorization Management functionality provided by SAP Cloud Identity Services for which you can read more at Configuring Authorization Policies.

The solution

So, let’s see how the user management admin access can be restricted to a subset of the whole user base.

Using the predefined Base Policies for users (CREATE_USERS, READ_USERS, UPDATE_USERS, DELETE_USERS, MANAGE_USERS) you can define a custom one with restriction rules based on the values of some user attributes. In this way you limit the corresponding permission granted by the base policy, so it will be relevant only for the subset of users that match the specified rule.

You can restrict for which users the admin gets the corresponding access level (permission), based on the following user attributes:

User Attributes
Attributes	Value
user.userName	The Login Name attribute of the user as defined in the administration console.
user.addresses.country	The Country attribute part of the address in the personal user information. The value must match the predefined master data one. See Countries.properties. Tip Use the key from the key-value pair for the value of the user.country attribute. For example, you must use DE from the key-value pair DE=Germany.
user.costCenter	The Cost Center of the user, part of the employee information.
user.division	The Division of the user, part of the employee information.
user.department	The Department of the user, part of the employee information. The value must match the predefined master data one. See Departments.properties.
user.organization	The Company of the user, part of the company information.

You can also limit the attributes of the users that the admin can access by configuring one of the following attributes in your custom policy:

User Attributes
Attributes	Value
user.attributes	Allows you to define a subset of the user attributes (by listing them in the value field separated with commas) that the admin would be able to access. User attributes that are not part of the SCIM Core Schema must be specified with their fully qualified name that includes the corresponding schema. Note: If the user.аttributes is used with the "=" operator, it supports only one attribute. For more attributes, use the "IN" operator adding each attribute separately. *Note:* If you use the attribute ‘password’, you must also add the following two attributes: ‘active* and ‘urn:ietf:params:scim:schemas:extension:sap:2.0:User:status’*.
Deprecated user.excludedAttributes	Note: The user.excludedAttributes attribute is deprecated. If you have a policy configured with the user.excludedAttributes attribute, exchange the user.excludedAttributes with the user.attributes attribute in combination with the "NOT IN" operator. If the policy is configured with the user.аttributes attribute used with the "=" operator, it supports only one attribute. For more attributes, use the "IN" operator adding each attribute separately.

Important:

The user attributes that currently can be used for user.attributes, and user.excludedAttributes restrictions are listed in the Supported Attributes chapter.

Supported Attributes

Core Schema:

firstName
lastName
loginName
displayName
addresses.country
addresses.streetAddress
addresses.streetAddress2
phoneNumbers.value
phoneNumbers.verified
emails.value
emails.verified
password

Note:

For the attributes defined in the core schema, the Schema URI notation [urn:ietf:params:scim:schemas:core:2.0:User] is not needed, for all the other attributes, schema URI and the attribute name is required.

Еxample: user.attributes IN displayName, addresses.country, emails.value;

Enterprise Schema:

costCenter
organization
division
department

Note:

All Enterprise user resource schema attributes require the schema URI [urn:ietf:params:scim:schemas:extension:enterprise:2.0:User] and the attribute name.

Еxample: user.attributes IN urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter, urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization;

SAP Extension Schema:

globalUserId
validFrom
validTo

Note:

All SAP Extension user resource schema attributes require the schema URI [urn:ietf:params:scim:schemas:extension:sap:2.0:User] and the attribute name.

Еxample: user.attributes=urn:ietf:params:scim:schemas:extension:sap:2.0:User:globalUserId

The scenario

To illustrate how the new feature can be used to establish delegated administration, let’s have look a simple scenario with two administrators that should have different access level to the users:

Michael Adams – an administrator in the central IT team of company BestRun, that has “super admin” permissions, i.e. he can see and manage all the users in the company.

Dona Moore – works in third party company that provides 24x7 support for employees and contractors in the US office of BestRun.

Michael’s position in the company requires that he acts as a “super admin”.
Dona on the other hand, should have access only to the users that are in the USA. Further she should be able to see only a limited set of user details - the display name, username, email, company, and the address of the users in the USA. In addition, she should be able to help these users if they cannot log in, so she needs permissions to unlock user account, set initial password or send emails in case of forgotten password (again only for users in USA).

Michael’s task is to allow Dona to perform her duties in the Administration Console of SAP Cloud Identity Services.

Prerequisites

Michael must be an administrator in SAP Cloud Identity Services with a full set of administrator authorizations.

The new feature for admin authorizations based on policies must be enabled on the tenant.
Note: This is a beta feature. More information about the enablement of the feature, can be found in the official documentation of SAP Cloud Identity Services. Once the option is enabled, a new tab Authorization Policies appear for the Administration Console application.

Configuration

Michael performs the following configurations to provide the necessary access for Dona:

Access the administration console->choose Applications->choose the list item for the Administration Console application under System Applications.

I. Create a new custom policy that grants restricted read-only permissions.

Choose the Authorization Policies tab->plus + button -> Restrict to create the new custom policy.
Provide the required information in the pop-up:
1. Policy name - READ_USERS_US_RESTRICTED
2. Base policies - users.READ_USERS)
3. Select Open in edit mode
4. Choose the Confirm button. (As a result the Rules tab of the newly created policy opens.)
5. Choose the + button to add the rule:user.addresses.country = US
  user.attributes IN displayName, emails.value, userName, addresses.country, password, active, urn:ietf:params:scim:schemas:extension:sap:2.0:User:status, urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization

3. Save the policy.

II. Create a new custom policy that grants restricted update permissions.

Choose the Authorization Policies tab->plus + button -> Restrict to create the new custom policy.
Provide the required information in the pop-up:
1. Base policies - users.UPDATE_USERS
2. Choose the + button to add the rule:
3. user.addresses.country = US
user.attributes IN password,active,urn:ietf:params:scim:schemas:extension:sap:2.0:User:status
Choose the Confirm button. (As a result the Rules tab of the newly created policy opens.)
Select Open in edit modePolicy name - RESET_PASSWORD_US
Save the policy.

III. Create a new custom policy that combines the custom policies created from procedures I. and II.

Choose the Authorization Policies tab->plus + button -> Combine to create the new custom policy.
Provide the required information in the pop-up:

IV. Assign the US_SUPPORTER policy to Dona

Select the US_SUPPORTER policy
Select the Assignments tab and choose Add.
Select Dona Moore from the list and choose Add.

Because Michael is super admin, when he signs in he can see all the users in the admin console:

He can also update the personal and company information of the users:

Dona, on the other hand can see only the users in the USA, after signing in to the administration console:

She can't update their personal and company information:

But, because Dona is assigned to the RESET_PASSWORD_US policy, she can also unlock a user:

And set the initial password for the unlocked user: