In the first part of the blog series, you have learned about the meaning of permissions, authorizations, and the IdP configuration. But let's check all the prerequisites for using groups in the workflow service with the help of an example:
There is a workflow for onboarding new hires. It contains some service tasks, for example, to construct the payload of the new employee, or to determine his or her equipment. But it also contains two user tasks. One user task called 'Change or confirm equipment' for checking that the assigned equipment is correct, and a second one to approve of the equipment called ‘Approve equipment’.
At runtime, the user tasks are to be executed by different persons, that is end users. The project lead of the new hire will execute the task of checking the equipment. Michael is one of the project leads and an end user. The approval task is to be executed by the line manager of the new hire; Rebecca is one of the end users who are line managers and will execute this task.
Let's first see how groups can become user task recipients in workflows.
Setting up groups as task recipients in the workflow editor
When you model workflows in the workflow editor, you need to add recipients to each user task that you model. These recipients are the ones that later work on the respective tasks. Their tasks show up in their personal list of tasks in My Inbox.
The workflow editor allows you to define users, groups or a combination of both as user task recipients. You can use any string value as group or user - but to get it properly resolved while executing the workflow, the string needs to be exactly the same as the name of the group or user that you use in your identity provider.
In the example described above, we use two groups: ‘Project Leads’ and ‘Line Managers’. The task ‘Change or Confirm equipment’ is assigned to the group ‘Project Leads’. The task ‘Approve Equipment’ is assigned to the group ‘Line Managers’.
Alternatively, you can use expressions to dynamically determine the task recipients based on the workflow context. You can have expressions for both - groups and users. For more information, see Expressions.
The recipient groups are then dynamically determined based on the value of a context attribute. When executing the workflow, the context attribute has to contain a comma-separated list of one or several group names. Our example lists “Project Leads” for the task ‘Change or Confirm Equipment'. The group name(s) must correspond to actual groups that contain the users who should receive the tasks. The list of groups is assigned to the context attribute either as part of previous workflow tasks or as input when starting the workflow.
Defining groups so that they can be used in the workflow service
Right now, we have defined a workflow that contains two tasks that should be executed by users belonging to the ‘Project Leads’ or ‘Line Managers’ group. When the workflow is deployed to a subaccount, these two groups must exist or must be accessible by the subaccount. This is necessary for the workflow service to resolve the groups properly to assigned users.
We have previously seen several ways to define and use groups on the subaccount – let's now relate this to our example:
The two groups that we have used in the workflow editor need to be available in the subaccount. To create the groups, open the SAP Cloud Platform cockpit and choose 'Security -> Authorizations'. Switch to the ‘Groups’ tab. Here you see an overview of the groups in your subaccount.
To define a new group, choose the ‘New Group’ button in the Group area. Give the group a proper name and save it. The list of groups then displays your new group . As shown here, we can directly create two groups – one called ‘Line Managers’ and one called ‘Project Leads’.
You can assign users to groups in the middle right-hand side on the same screen in the ‘Individual Users’ section. The users are provided by the IdP. Therefore, the name of the users must match the names as defined by the IdP.
You might have users grouped already in your corporate IdP and would like to re-use these groupings. The users are then provided by your IdP and have (at least) one attribute that states all the groups the user belongs to:
You see that the attribute ‘GroupAssignments’ contains the names of the groups that a user belongs to. Exactly this attribute needs to be exposed from the corporate identity provider to the local service provider. This attribute (also known as assertion-based attribute as it is sent by the IdP in the SAML assertion) needs to be mapped to a principal attribute called ‘groups’, so that it can be consumed by the workflow service. To set this up, open the SAP Cloud Platform cockpit. Choose 'Security -> Trust', and select the corporate identity provider that you have configured. On the pop-up that comes up configure the corporate identity provider’s settings. Open the 'Attributes’ tab to do the mapping.
As you can see in the screenshot, the attribute ‘groupAssignments’ is mapped to the principal attribute ‘groups’. Now the workflow service treats whatever information is contained in the attribute ‘groupAssignments’ as the groups a user belongs to – and thus the workflow service can base the group-to-user resolution on this information.
You can also combine group assignments from a corporate Identity provider with groups that are provided locally in an account. However, this is a typical use case for granting permissions to users using groups – which will be explained in the next section.
The workflow service offers several authorizations that can be granted to users. Depending on the users tasks in the context of the workflow service, you need to provide them with the respective permissions. For more information about the different authorizations, see Authorization Configuration.
In our example, users belonging to the ‘Project Leads’ and ‘Line Managers’ groups need the ‘WorkflowParticipant’ permission to interact with the workflow service.
The workflow service exposes its authorizations as roles in the subaccount that can be assigned to groups defined in SAP Cloud Platform. You can create one or more groups locally as needed and assign the necessary role(s).
In our example, there is one local group in the subaccount that is called ‘WorkflowParticipant’. You can choose any name. But for better readability, use the name of the workflow service permissions, too. The local group has the role ‘WorkflowParticipant’ assigned. To assign roles to a group, switch to the configuration of the workflow service ('Services -> Workflow -> Configure Service'). Select the role ‘WorkflowParticipant’ and choose ‘Assign’ in the ‘Groups’ section. In the drop-down, select the new group ‘WorkflowParticipant’. Now, the group is assigned:
What is still missing is the connection between the local group ‘WorkflowParticpant’ and the users / group information from the corporate IdP. To establish this connection, map the groups accordingly in the SAP Cloud Platform cloud cockpit. Navigate to 'Security -> Trust' and select the corporate identity provider that you have configured. On the next screen, configure the corporate identity provider’s settings; navigate to the 'Groups’ tab to define how groups are mapped. To add a new group mapping, press ‘Add Assertion-based Group’. Then map a group from the IdP to a group defined in SAP Cloud Platform (or the other way round).
The groups available in the drop-down on the left side are the local ones from your account. For our example, we choose the group ‘WorkflowParticipant’. As a mapping rule, we need to enter ‘GroupAssignments’ (that’s the attribute in your corporate IdP for group identification) in the first field, ‘equals’ in the second – and in the last field the name of the group on the identity provider we want to map the group to – in our example, we map to the group called ‘Project Leads’. We also map the group ‘WorkflowParticipant’ to the group ‘Line Managers’.
Finally, navigate back to the Authorizations and check the ‘WorkflowParticipant’ group that we have created. The mapping to the group in the corporate identity provider is shown in the lower section:
Alternatively, you can create all workflow service roles, for example, ‘Workflow Participants’ as groups on your corporate IdP and then do a 1:1 mapping with the groups created in the service provider. The users are directly assigned to the groups on the corporate IdP - this is how it would look like:
So far, you have modelled a workflow containing groups as task recipients, created or assigned groups so that groups can be resolved to users at runtime by the workflow service, and granted the permissions so that end users may interact with the workflow service.
You might now also introduce permissions on the user interfaces that allow access to the workflow service.
The workflow service offers the following SAP Fiori launchpad content to access our applications:
These applications are available in the 'Workflow' catalog of SAP Fiori launchpad.
As previously explained, the workflow service uses the respective API to protect the access to its data and functionalities with roles, for example, 'WorkflowParticipant'. The applications listed above leverage this API and are additionally also protected by own roles.
Coming back to our example: Michael, the project lead, wants to work on a task in My Inbox. He is already assigned the 'WorkflowParticipant' role. Therefore, he is allowed to access the workflow service's data and functionality using the API. However, he cannot yet see the My Inbox application itself. You still have to assign this permission to him.
When setting up the portal site for your subaccount, you can of course assign the above listed applications to a generic role, for example, 'Everyone'. This would not do any harm because without the corresponding API permissions, users cannot do anything on the applications' UIs.
However, you can also use groups to explicitly set permissions on the applications themselves by introducing a new global portal role:
To add the new global portal role, navigate to 'Services -> Portal -> Configure Portal'. Then switch to the 'Roles' tab. To create a new role, press the ‘New Role’ button. The new role is of type ‘Custom’. In the lower right section, assign a group to this newly created role.
In our example, you have added a new role called ‘MyInboxAccess’:
The newly created role is automatically available in your portal sites. You can now use this role to add catalogs and groups of apps to it.
For more information about the SAP Cloud Platform Portal and its concepts, please see the Portal documentation.
You have seen different options on how to connect and configure an IdP and how to use groups in such a setup. You have learned how to use groups when defining user task recipients. You have learned how to configure permissions for accessing the workflow service functionalities and applications leveraging groups.
There is a workflow for onboarding new hires. It contains some service tasks, for example, to construct the payload of the new employee, or to determine his or her equipment. But it also contains two user tasks. One user task called 'Change or confirm equipment' for checking that the assigned equipment is correct, and a second one to approve of the equipment called ‘Approve equipment’.
At runtime, the user tasks are to be executed by different persons, that is end users. The project lead of the new hire will execute the task of checking the equipment. Michael is one of the project leads and an end user. The approval task is to be executed by the line manager of the new hire; Rebecca is one of the end users who are line managers and will execute this task.
Groups as Task Recipients
Let's first see how groups can become user task recipients in workflows.
Setting up groups as task recipients in the workflow editor
When you model workflows in the workflow editor, you need to add recipients to each user task that you model. These recipients are the ones that later work on the respective tasks. Their tasks show up in their personal list of tasks in My Inbox.
The workflow editor allows you to define users, groups or a combination of both as user task recipients. You can use any string value as group or user - but to get it properly resolved while executing the workflow, the string needs to be exactly the same as the name of the group or user that you use in your identity provider.
In the example described above, we use two groups: ‘Project Leads’ and ‘Line Managers’. The task ‘Change or Confirm equipment’ is assigned to the group ‘Project Leads’. The task ‘Approve Equipment’ is assigned to the group ‘Line Managers’.
Alternatively, you can use expressions to dynamically determine the task recipients based on the workflow context. You can have expressions for both - groups and users. For more information, see Expressions.
The recipient groups are then dynamically determined based on the value of a context attribute. When executing the workflow, the context attribute has to contain a comma-separated list of one or several group names. Our example lists “Project Leads” for the task ‘Change or Confirm Equipment'. The group name(s) must correspond to actual groups that contain the users who should receive the tasks. The list of groups is assigned to the context attribute either as part of previous workflow tasks or as input when starting the workflow.
Defining groups so that they can be used in the workflow service
Right now, we have defined a workflow that contains two tasks that should be executed by users belonging to the ‘Project Leads’ or ‘Line Managers’ group. When the workflow is deployed to a subaccount, these two groups must exist or must be accessible by the subaccount. This is necessary for the workflow service to resolve the groups properly to assigned users.
We have previously seen several ways to define and use groups on the subaccount – let's now relate this to our example:
1.Creating Groups in SAP Cloud Platform:
The two groups that we have used in the workflow editor need to be available in the subaccount. To create the groups, open the SAP Cloud Platform cockpit and choose 'Security -> Authorizations'. Switch to the ‘Groups’ tab. Here you see an overview of the groups in your subaccount.
To define a new group, choose the ‘New Group’ button in the Group area. Give the group a proper name and save it. The list of groups then displays your new group . As shown here, we can directly create two groups – one called ‘Line Managers’ and one called ‘Project Leads’.
You can assign users to groups in the middle right-hand side on the same screen in the ‘Individual Users’ section. The users are provided by the IdP. Therefore, the name of the users must match the names as defined by the IdP.
2.Using Groups Provided by an IdP:
You might have users grouped already in your corporate IdP and would like to re-use these groupings. The users are then provided by your IdP and have (at least) one attribute that states all the groups the user belongs to:
You see that the attribute ‘GroupAssignments’ contains the names of the groups that a user belongs to. Exactly this attribute needs to be exposed from the corporate identity provider to the local service provider. This attribute (also known as assertion-based attribute as it is sent by the IdP in the SAML assertion) needs to be mapped to a principal attribute called ‘groups’, so that it can be consumed by the workflow service. To set this up, open the SAP Cloud Platform cockpit. Choose 'Security -> Trust', and select the corporate identity provider that you have configured. On the pop-up that comes up configure the corporate identity provider’s settings. Open the 'Attributes’ tab to do the mapping.
As you can see in the screenshot, the attribute ‘groupAssignments’ is mapped to the principal attribute ‘groups’. Now the workflow service treats whatever information is contained in the attribute ‘groupAssignments’ as the groups a user belongs to – and thus the workflow service can base the group-to-user resolution on this information.
3.Combining Groups from a Corporate Identity Provider:
You can also combine group assignments from a corporate Identity provider with groups that are provided locally in an account. However, this is a typical use case for granting permissions to users using groups – which will be explained in the next section.
Granting Permissions to users with groups
The workflow service offers several authorizations that can be granted to users. Depending on the users tasks in the context of the workflow service, you need to provide them with the respective permissions. For more information about the different authorizations, see Authorization Configuration.
In our example, users belonging to the ‘Project Leads’ and ‘Line Managers’ groups need the ‘WorkflowParticipant’ permission to interact with the workflow service.
The workflow service exposes its authorizations as roles in the subaccount that can be assigned to groups defined in SAP Cloud Platform. You can create one or more groups locally as needed and assign the necessary role(s).
In our example, there is one local group in the subaccount that is called ‘WorkflowParticipant’. You can choose any name. But for better readability, use the name of the workflow service permissions, too. The local group has the role ‘WorkflowParticipant’ assigned. To assign roles to a group, switch to the configuration of the workflow service ('Services -> Workflow -> Configure Service'). Select the role ‘WorkflowParticipant’ and choose ‘Assign’ in the ‘Groups’ section. In the drop-down, select the new group ‘WorkflowParticipant’. Now, the group is assigned:
What is still missing is the connection between the local group ‘WorkflowParticpant’ and the users / group information from the corporate IdP. To establish this connection, map the groups accordingly in the SAP Cloud Platform cloud cockpit. Navigate to 'Security -> Trust' and select the corporate identity provider that you have configured. On the next screen, configure the corporate identity provider’s settings; navigate to the 'Groups’ tab to define how groups are mapped. To add a new group mapping, press ‘Add Assertion-based Group’. Then map a group from the IdP to a group defined in SAP Cloud Platform (or the other way round).
The groups available in the drop-down on the left side are the local ones from your account. For our example, we choose the group ‘WorkflowParticipant’. As a mapping rule, we need to enter ‘GroupAssignments’ (that’s the attribute in your corporate IdP for group identification) in the first field, ‘equals’ in the second – and in the last field the name of the group on the identity provider we want to map the group to – in our example, we map to the group called ‘Project Leads’. We also map the group ‘WorkflowParticipant’ to the group ‘Line Managers’.
Finally, navigate back to the Authorizations and check the ‘WorkflowParticipant’ group that we have created. The mapping to the group in the corporate identity provider is shown in the lower section:
Alternatively, you can create all workflow service roles, for example, ‘Workflow Participants’ as groups on your corporate IdP and then do a 1:1 mapping with the groups created in the service provider. The users are directly assigned to the groups on the corporate IdP - this is how it would look like:
Permissions for Applications SAP Cloud Platform Portal
So far, you have modelled a workflow containing groups as task recipients, created or assigned groups so that groups can be resolved to users at runtime by the workflow service, and granted the permissions so that end users may interact with the workflow service.
You might now also introduce permissions on the user interfaces that allow access to the workflow service.
The workflow service offers the following SAP Fiori launchpad content to access our applications:
- My Inbox enabling workflow participant to process user tasks
- Monitor Workflows - Workflow Definitions enabling workflow administrators to manage workflow definitions
- Monitor Workflows - Workflow Instances enabling workflow administrators to manage workflow instances
These applications are available in the 'Workflow' catalog of SAP Fiori launchpad.
As previously explained, the workflow service uses the respective API to protect the access to its data and functionalities with roles, for example, 'WorkflowParticipant'. The applications listed above leverage this API and are additionally also protected by own roles.
Coming back to our example: Michael, the project lead, wants to work on a task in My Inbox. He is already assigned the 'WorkflowParticipant' role. Therefore, he is allowed to access the workflow service's data and functionality using the API. However, he cannot yet see the My Inbox application itself. You still have to assign this permission to him.
When setting up the portal site for your subaccount, you can of course assign the above listed applications to a generic role, for example, 'Everyone'. This would not do any harm because without the corresponding API permissions, users cannot do anything on the applications' UIs.
However, you can also use groups to explicitly set permissions on the applications themselves by introducing a new global portal role:
- This role is automatically available for all portal sites. It controls which users may see which apps or catalogs on a certain site.
- On the other hand, you can also map this new global portal role to existing groups in SAP Cloud Platform – and thus build a bridge between specific portal sites and the SAP Cloud Platform groups.
To add the new global portal role, navigate to 'Services -> Portal -> Configure Portal'. Then switch to the 'Roles' tab. To create a new role, press the ‘New Role’ button. The new role is of type ‘Custom’. In the lower right section, assign a group to this newly created role.
In our example, you have added a new role called ‘MyInboxAccess’:
The newly created role is automatically available in your portal sites. You can now use this role to add catalogs and groups of apps to it.
For more information about the SAP Cloud Platform Portal and its concepts, please see the Portal documentation.
Conclusion
You have seen different options on how to connect and configure an IdP and how to use groups in such a setup. You have learned how to use groups when defining user task recipients. You have learned how to configure permissions for accessing the workflow service functionalities and applications leveraging groups.
- SAP Managed Tags:
1 Comment
