SAP Cloud Integration controls data access via roles and personas. Roles grant people permissions to perform certain tasks on a tenant. Using Access Policies it is possible to additionally restrict tasks to only a subset of artifacts on a tenant.
In this blog post I will explain how access policies work and provide links to additional information.
The role concept in Cloud Integration is based on personas and their tasks within integration projects. Users having the same persona and roles assigned can perform the same tasks on all artifacts and data of a tenant.
For example, the collection of roles contained in the AuthGroup.BusinessExpert authorization group grants access to the business data stored in the course of message processing. Same access could be granted to any user by assigning the single role esbmessagestorage.read.
Each user that has either the group or the single role assigned can access the business data stored during the processing of any integration flow deployed on a tenant.
Task based authorization groups and roles are documented under Persona and Tasks and Permissions.
While the task based role permissions fit well for small projects and a single team, it has some limitations especially for larger companies:
In such a setup it might be desirable that even on the same tenant only persons with dedicated authorizations get access to those integration flows that process confidential data.
This is where Access Policies come into play.
Access policies define sets of artifacts in such a way that only users with dedicated roles can access the data associated with these artifacts.
For example, access policies can reference sets of integration flows and provide protection to the business data processed by these flows.
An access policy is associated to a custom role (defined via the platform cockpit) and contains references to integration artifacts.
The activation of access policies is done in 3 steps:
For more details see the documentation on Managing Access Policies.
Let's have a look at how the two role types described above are related when it comes to authorization checks.
When a user tries to access the (data of) a certain artifact the following checks are performed:
This implies that a user cannot perform certain tasks on one set of artifacts and different tasks on other artifacts as the first check is always on task level. For such a use case a single person would require to work with multiple user accounts having different roles assigned.
The second level check is based on access policies, in detail:
Assume we have multiple users with BusinessExpert role, one of them working in the HR area. Only the latter shall be allowed to view the content of messages containing employee data.
Creating custom roles differ between the Neo and Cloud Foundry environment. I will not go into detail here, just let's assume a custom role called EmployeeData.access is available and assigned to the HR business expert.
Please refer to Managing Access Policies, Neo Environment or Managing Access Policies, Cloud Foundry Environment for more details and links to the respective documentation.
With an access policy, you add artifact (integration flow) references to a custom role.
Regular expressions used for referencing artifacts have to be supported by the Java Pattern. For testing your expressions you can use any tool supporting this class. Multiple Test tools are available online.
You can create multiple artifact references per access policy. Following example would reference a single integration flow by its ID:
The details area for an access policy lists all defined artifact references:
With the above access policy in place, users with the business expert authorization group assigned can access the data processed by all integration flows NOT referenced in this policy. But they cannot access data processed by the referenced integration flows unless they have the custom role EmployeeData.access assigned.
Access Policies can help in segregating data even on a single tenant.
At the time of writing this blog, the supported artifact types are all kinds of processes (Integration Flows, OData, SOAP and REST APIs) plus JMS Queues. The protected data is business data in monitoring (trace messages, messages in queues) and message processing log attachments. For the actual feature scope, see Access Policies In SAP Cloud Integration.
I hope, this post helps understanding where and how access policies can be useful in your organization.
Your feedback on both the feature and the content of this post is welcome.
In this blog post I will explain how access policies work and provide links to additional information.
Personas and Roles
The role concept in Cloud Integration is based on personas and their tasks within integration projects. Users having the same persona and roles assigned can perform the same tasks on all artifacts and data of a tenant.
For example, the collection of roles contained in the AuthGroup.BusinessExpert authorization group grants access to the business data stored in the course of message processing. Same access could be granted to any user by assigning the single role esbmessagestorage.read.
Each user that has either the group or the single role assigned can access the business data stored during the processing of any integration flow deployed on a tenant.
Task based authorization groups and roles are documented under Persona and Tasks and Permissions.
While the task based role permissions fit well for small projects and a single team, it has some limitations especially for larger companies:
- Different teams work on various integration projects, so that different people are responsible for only a certain subset of business processes. To securely segregate the data accessible to members of each team, companies often require multiple tenants.
- When modeling comprehensive integration scenarios, the business logic is typically distributed over multiple integration flows. You can, for example, expect that certain integration flows process confidential data, whereas others are not critical with regard to data privacy.
In such a setup it might be desirable that even on the same tenant only persons with dedicated authorizations get access to those integration flows that process confidential data.
This is where Access Policies come into play.
Access Policies
Access policies define sets of artifacts in such a way that only users with dedicated roles can access the data associated with these artifacts.
For example, access policies can reference sets of integration flows and provide protection to the business data processed by these flows.
An access policy is associated to a custom role (defined via the platform cockpit) and contains references to integration artifacts.
The activation of access policies is done in 3 steps:
- Define a custom role using the platform cockpit.
- Define an access policy using the Web UI (Monitor section).
- Assign the custom role to users of the referenced artifacts
For more details see the documentation on Managing Access Policies.
Authorization flow
Let's have a look at how the two role types described above are related when it comes to authorization checks.
When a user tries to access the (data of) a certain artifact the following checks are performed:
- Level: Does the user have the required role to perform that task? (if not, access is revoked)
- Level: Is the user allowed to access the respective artifact
This implies that a user cannot perform certain tasks on one set of artifacts and different tasks on other artifacts as the first check is always on task level. For such a use case a single person would require to work with multiple user accounts having different roles assigned.
The second level check is based on access policies, in detail:
- Is the artifact referenced by any access policy (if not, access is granted)
- Is at least one of the custom roles associated with these access policies assigned to the user (if yes, access is granted)
Example
Assume we have multiple users with BusinessExpert role, one of them working in the HR area. Only the latter shall be allowed to view the content of messages containing employee data.
Create and Assign a Custom Role
Creating custom roles differ between the Neo and Cloud Foundry environment. I will not go into detail here, just let's assume a custom role called EmployeeData.access is available and assigned to the HR business expert.
Please refer to Managing Access Policies, Neo Environment or Managing Access Policies, Cloud Foundry Environment for more details and links to the respective documentation.
Create the Access Policy
With an access policy, you add artifact (integration flow) references to a custom role.
- Open the Web UI and go to the Monitor
- Under Manage Security, select the Access Policies
- To create a new access policy, click the + icon (Create new Access Policy).
- As Role Name enter the name of the created custom role
- You can enter a description.
- Click Create.
- On the details screen for the newly created access policy, click the + icon to add an artifact reference.
- On the next screen, enter the attributes of the artifact reference:
- Select Name and Matches (as you like to enter a regular expression to indicate integration flows with a Name that follows a certain pattern).
- As Value, enter a valid Java regular expression
- Click Create.
Regular expressions used for referencing artifacts have to be supported by the Java Pattern. For testing your expressions you can use any tool supporting this class. Multiple Test tools are available online.
You can create multiple artifact references per access policy. Following example would reference a single integration flow by its ID:
The details area for an access policy lists all defined artifact references:
With the above access policy in place, users with the business expert authorization group assigned can access the data processed by all integration flows NOT referenced in this policy. But they cannot access data processed by the referenced integration flows unless they have the custom role EmployeeData.access assigned.
Conclusion
Access Policies can help in segregating data even on a single tenant.
At the time of writing this blog, the supported artifact types are all kinds of processes (Integration Flows, OData, SOAP and REST APIs) plus JMS Queues. The protected data is business data in monitoring (trace messages, messages in queues) and message processing log attachments. For the actual feature scope, see Access Policies In SAP Cloud Integration.
I hope, this post helps understanding where and how access policies can be useful in your organization.
Your feedback on both the feature and the content of this post is welcome.
- SAP Managed Tags:
18 Comments
| User | Count |
|---|---|
| 14 | |
| 11 | |
| 10 | |
| 10 | |
| 9 | |
| 8 | |
| 7 | |
| 7 | |
| 7 | |
| 7 |
