Skip to Content
Product Information

Cloud Integration – Access Policies: Defining Roles on Artifact Level

SAP Cloud Platform 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.

Personas and Roles

The role concept in Cloud Platform 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 SAP Cloud Platform Cockpit) and contains references to integration artifacts.

The activation of access policies is done in 3 steps:

  1. Define a custom role using SAP Cloud Platform Cockpit.
  2. Define an access policy using the Web UI (Monitor section).
  3. 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:

  1. Level: Does the user have the required role to perform that task? (if not, access is revoked)
  2. 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:

  1. Is the artifact referenced by any access policy (if not, access is granted)
  2. 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 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.

  1. Open the Web UI and go to the Monitor
  2. Under Manage Security, select the Access Policies

  3. To create a new access policy, click the + icon (Create new Access Policy).
  4. As Role Name enter the name of the created custom role
  5. You can enter a description.
  6. Click Create.
  7. On the details screen for the newly created access policy, click the + icon to add an artifact reference.
  8. On the next screen, enter the attributes of the artifact reference:
  9. Select Name and Matches (as you like to enter a regular expression to indicate integration flows with a Name that follows a certain pattern).
  10. As Value, enter a valid Java regular expression
  11. 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 feature is available only on Neo environments.

Supported artifact types are integration flows, protected data are trace messages and message processing log attachments.

I hope, you 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.

8 Comments
You must be Logged on to comment or reply to a post.
  • Hi Ines Ahrens

    thanks for the helpful blog. I tried to set up some rules and it worked quite well.

    Two questions came into my mind when reading your article:

    • You linked tutorial for setting up custom rules on NEO and CF, but wrote at the same time, that the feature is only available on NEO for now. Do you know when the feature will be available for CF tenants?
    • You wrote it’s necessary to setup custom roles in Cloud Platform Cockpit. I guessed the roles have to be set on the tenant management node (tmn) application on not on the (iflmap) application and it worked. Maybe you can point this out in the blog post?

    Best regards,
    Raffael

    • Hi Raffael,

      thanks a lot for your comments.

      • On CF the feature will be available with the next release to customers.
      • For Neo the documentation mentions the need to setup custom roles on the tmn application before pointing to the respective chapter of the SAP Cloud Platform documentation. But I agree it could have been more prominently placed.

      I will publish a blog post on how to setup the custom roles to be used in conjunction with access policies on both Neo and CF once the feature is released on CF as well.

      Best regards, Ines

  • Hi Ines Ahrens

    We are worried about another issue related to this authorization concept on Iflow level in Enterprise tenant. once we give download access to any user on iflow level, then he/she can also download the payload of any JMS queue. which is not good for security purpose.

    So could you please check this and provide us any solutions?

     

     

     

    Thanks,

    Prabhat Kumar Ranjan

    /
    • Hi Prabhat Kumar Ranjan,

      as mentioned in the post, currently only access to log attachments and trace data is restricted by access policies. Other business data in message store, data stores and queues is in scope for next increments of the feature.

      Best regards, Ines