Introduction
When setting up the environment for using the SAP Cloud Platform Workflow service, one of the main questions is how to deal with users:
- Who is receiving user tasks to execute them?
- Who may monitor the workflow execution?
- Who may start the workflow?
The first question describes a participation in the workflow, while the second and third describe permissions. To interact with the workflow service, you need to do both:
- Grant permissions to users so they can interact with the workflow service itself and
- Set users as recipients of user tasks that are modelled and executed in the workflow service.
For both, permissions and user task recipients, you can use
groups instead of individual users to make your setup more flexible. This blog post series describes how to achieve this. The first blog post - this one - describes the theory behind using groups in SAP Cloud Platform - and SAP Cloud Platform Workflow in particular. The second blog post has a lot of examples that show you in detail what you need to do concretely to use groups in SAP Cloud Platform Workflow. Furthermore, you will see how you could even use groups to organize permissions in SAP Cloud Platform Portal.
Identity Provisioning and Federation in SAP Cloud Platform
The workflow service relies on the identity provider (IdP) that is configured in the subaccount.
The identity provider supplies the user base for all applications available for that subaccount (either using subscriptions or directly). SAP Cloud Platform does not supply a user database of its own.
By default, the subaccount is connected to the SAP ID Service. The SAP ID service is the place where you register to get initial access to SAP Cloud Platform. The user base of the SAP ID service is thus limited and usually used for testing and exploring purposes only.
You will therefore want to use your corporate IdP ‘s user base for your subaccount if you already have one. Alternatively, you can register a tenant for the SAP Cloud Platform Identity Authentication service as an identity provider for your subaccount and provide your user base there. For more information, see
Identity Authentication Tenant as an Application Identity Provider.
In any case, you need to configure your subaccount. For more information, see
Configure SAP Cloud Platform as Local Service Provider. Once configured, the subaccount acts as a SAML consumer, also called local service provider. It interacts with the chosen identity provider (= the SAML authority) for getting information about principals, usually the users. The service provider (SAP Cloud Platform) offers services and respective permissions, that is, roles to access these services. The identity provider however offers information about principals, that is users.
When your cloud account is connected to a corporate identity provider, and this provider exposes user attributes, the work is not done yet. The applications on the SAP Cloud Platform – in our case namely the workflow service - also must be able to
understand these attributes. Therefore, you need to define how the user attributes sent by the corporate identity provider (so-called assertion attributes) are mapped to the user attributes consumed by applications on SAP Cloud Platform (principal attributes).
Defining and Using Groups
Your subaccount – and thus also the workflow service – can now access the user base of the chosen identity provider. However, the user base is so far provided without any grouping concept. So, you would have to work with individual users – this can be a tedious and error-prone activity. Furthermore, using groups improves the flexibility of your workflows: Users can easily be added to groups dynamically and can instantly interact with the workflow service.
Groups are provided by the service providers, but also by the identity providers. Connecting the service and identity providers offers different options to use these groups:
Creating Groups in SAP Cloud Platform
You can manually create groups in your subaccount. However, these groups are then only available in this specific subaccount and not globally in all your subaccounts. This is useful though if you want to restrict a group to a specific subaccount.
Using Groups Provided by an IdP
If the chosen IdP already contains information about the group assignments of the users on the IdP, this information can be exposed and mapped properly. Make sure that you
at least have one attribute for group identification: The workflow service expects an attribute called ‘groups’ to resolve groups and assign users at runtime. Therefore, you need to map the respective group identification attribute of your corporate IdP (‘assertion attribute’) to the principal attribute ‘groups’.
For more information about mapping assertion to principal attributes, see
Configure Trust to the SAML Identity Provider. Please refer also to the example in the second part of the blog.
When using this approach, you are NOT creating new groups. The workflow service then simply accepts the user’s attribute groups that come from the IdP.
Combining Groups from a Corporate Identity provider
You can use a combination of local groups on your account and groups from a corporate identity provider. This is, for example, useful in the following cases:
- To merge groups from the corporate identity provider into one group of task recipients.
- To avoid changes to the corporate identity provider and give the group a more meaningful name in the workflow context.
- To use an already existing workflow model with pre-defined groups as task recipients plus use a corporate identity provider where the groups have different names.
To go for this option, you need to explicitly map the groups on the corporate identity provider and the local groups. Please refer to the example in the second part of the blog and see
Configure Trust to the SAML Identity Provider.
Continue reading with the
second part of this blog.
