This is the fourth post in a six-part series written by SAP Concur Technical Consultants about using Concur’s Identity and User Provisioning Services. I’ll be taking over the reins from Rick Foster for this installment. I’ve been a Technical Consultant at SAP Concur for over 13 years, working with a wide range of SAP Concur customers, of different sizes, from different industries, from medium to large national businesses, to international corporations, implementing the full range of SAP Concur products.
The first three installments in this series, provide a basis for understanding what can be done with these services and how they work together to provision and maintain user profile data in Concur Travel & Expense.
In this post we’ll look at how UPS can be used to grant users access to the different functions of the system, and provide them with additional permissions within those areas, by assigning Entitlements and Roles.
A couple definitions to help understand how Concur manages user access:
Entitlements
Entitlements are assigned as part of the core attributes of a user and part of the ‘urn:ietf:params:scim:schemas:core:2.0:User’ schema. The assignment of entitlements can be made or removed using the UPS or Identity services at any time. Below is an example of how the entitlements can be set in the Users Request.
Spend Roles codes give users additional access to Expense, Request, Invoice and Reporting beyond the basic level of access, and are part of the Spend Role extension ("urn:ietf:params:scim:schemas:extension:spend:2.0:Role"), which is part of the User Provisioning Service API. Users can be assigned to one or more additional roles, using an array of role codes and role groups. Role codes identify the specific permission the user will be granted. A list of all of the Spend Role Codes can be found at the links below.
To assign Spend related roles to a user, associated entitlement must also be granted to allow users access to that part of the system. Since we know that many of our customers will want to be able to provision users from their IDP platform, we want to remind you that the User Provisioning Service can route the necessary updates to Identity as well as to Spend and Travel, providing you with a single service that’s capable of handling the complete user provisioning request, rather than calling separate services. We know that many customers’ first inclination might be to use their IDP platform to send user provisioning requests to the Identity service independently, but using the User Provisioning Service as a gateway actually provides you with the most flexibility and may eliminate having to make additional calls to separate services later, to complete the provisioning request to fully enable the user.
For roles that are “group-aware” role groups are used to control which data in the system the users have access to, or control over, which is defined by feature hierarchies, configured as part of the setup of the system. The hierarchy node the role is associated with is expressed as a concatenated string of the codes for each level of the list that defines the hierarchy, with hyphens between them. If no node is specified, the user will be granted the role at the Global level. Roles that are group-aware are identified in the Shared: User Administration User Guide.
For example, if a feature hierarchy were defined as Country > Company > Business Unit > Department, a user could be granted a group-aware role at any level of the hierarchy. Assigning a user a role for the “US-ACME-MANUFACTURING” role group would give the user access to the role for all of the departments under the Manufacturing business unit of Acme company in the US, but not other countries, companies, or business units.
Spend roles can also be assigned manually through the UI if needed, and still be managed using the API.
Travel Roles
Role assignment for Travel related roles using the API are handled a bit differently from the Spend roles. Instead of assigning individual roles to specific users, the Travel related roles are assigned to Groups or Travel Rule Classes through the UI, as part of the site configuration, and the users are then assigned to the appropriate rule class and groups, and inherit the roles from them. For example, if a group of users should be assigned the Travel Arranger role, a group would be created (e.g. “Arrangers”) the role would be assigned to it, and users would then be assigned to the “Arrangers” group. Users can belong to more than one group, but only one Travel Rule Class.
If a user needs to be granted a particular Travel role directly, as an exception to the group assignment, this can also be done manually through the UI by an administrator, but individually assigned Travel roles would not be able to be managed using the API, so a best practice recommendation would be to create groups as needed, with one or more roles assigned to them, then assign the users to the appropriate groups.
Here is an example of a UPS API call granting both entitlements and an additional spend user role to a user.
That wraps up this post in the Concur User Provisioning Service series. Thank you for continuing to read along! There are only two posts left, which are listed below, so please watch for them!
In case you missed our previous posts, please see the links below to access those.
The first three installments in this series, provide a basis for understanding what can be done with these services and how they work together to provision and maintain user profile data in Concur Travel & Expense.
In this post we’ll look at how UPS can be used to grant users access to the different functions of the system, and provide them with additional permissions within those areas, by assigning Entitlements and Roles.
A couple definitions to help understand how Concur manages user access:
- Entitlements are used to define which parts of the system the user should be able to use: Travel, Expense, Invoice or Request. When an entitlement is assigned to a user they’re assigned the base role which gives the user access to the basic functionality for that part of the system, such as the ability to create and submit an expense report or book a trip.
- Roles are used to give users access to additional functionality, like the ability to act as an administrator, approve expense reports or travel requests, or use reporting tools.
Entitlements
Entitlements are assigned as part of the core attributes of a user and part of the ‘urn:ietf:params:scim:schemas:core:2.0:User’ schema. The assignment of entitlements can be made or removed using the UPS or Identity services at any time. Below is an example of how the entitlements can be set in the Users Request.
Spend Roles codes give users additional access to Expense, Request, Invoice and Reporting beyond the basic level of access, and are part of the Spend Role extension ("urn:ietf:params:scim:schemas:extension:spend:2.0:Role"), which is part of the User Provisioning Service API. Users can be assigned to one or more additional roles, using an array of role codes and role groups. Role codes identify the specific permission the user will be granted. A list of all of the Spend Role Codes can be found at the links below.
To assign Spend related roles to a user, associated entitlement must also be granted to allow users access to that part of the system. Since we know that many of our customers will want to be able to provision users from their IDP platform, we want to remind you that the User Provisioning Service can route the necessary updates to Identity as well as to Spend and Travel, providing you with a single service that’s capable of handling the complete user provisioning request, rather than calling separate services. We know that many customers’ first inclination might be to use their IDP platform to send user provisioning requests to the Identity service independently, but using the User Provisioning Service as a gateway actually provides you with the most flexibility and may eliminate having to make additional calls to separate services later, to complete the provisioning request to fully enable the user.
For roles that are “group-aware” role groups are used to control which data in the system the users have access to, or control over, which is defined by feature hierarchies, configured as part of the setup of the system. The hierarchy node the role is associated with is expressed as a concatenated string of the codes for each level of the list that defines the hierarchy, with hyphens between them. If no node is specified, the user will be granted the role at the Global level. Roles that are group-aware are identified in the Shared: User Administration User Guide.
For example, if a feature hierarchy were defined as Country > Company > Business Unit > Department, a user could be granted a group-aware role at any level of the hierarchy. Assigning a user a role for the “US-ACME-MANUFACTURING” role group would give the user access to the role for all of the departments under the Manufacturing business unit of Acme company in the US, but not other countries, companies, or business units.
Spend roles can also be assigned manually through the UI if needed, and still be managed using the API.
Travel Roles
Role assignment for Travel related roles using the API are handled a bit differently from the Spend roles. Instead of assigning individual roles to specific users, the Travel related roles are assigned to Groups or Travel Rule Classes through the UI, as part of the site configuration, and the users are then assigned to the appropriate rule class and groups, and inherit the roles from them. For example, if a group of users should be assigned the Travel Arranger role, a group would be created (e.g. “Arrangers”) the role would be assigned to it, and users would then be assigned to the “Arrangers” group. Users can belong to more than one group, but only one Travel Rule Class.
If a user needs to be granted a particular Travel role directly, as an exception to the group assignment, this can also be done manually through the UI by an administrator, but individually assigned Travel roles would not be able to be managed using the API, so a best practice recommendation would be to create groups as needed, with one or more roles assigned to them, then assign the users to the appropriate groups.
Here is an example of a UPS API call granting both entitlements and an additional spend user role to a user.
That wraps up this post in the Concur User Provisioning Service series. Thank you for continuing to read along! There are only two posts left, which are listed below, so please watch for them!
- Part 5: V1, Bulk V3 retirement and transition to V4 API
- Part 6: Best Practice and Debugging tips for using UPS
In case you missed our previous posts, please see the links below to access those.
- Introducing SAP Concur’ s Identity and User Provisioning Webservices | SAP Blogs
- Concur User Provisioning Service: Understanding the differences between Identity, Spend and Travel ...
- Concur User Provisioning Service: Synchronous vs Asynchronous calls with UPS and how they work toget...
- SAP Managed Tags:
1 Comment
