Skip to Content
Product Information
Author's profile photo Ines Ahrens

Cloud Integration – Access Policies: Defining Roles on Artifact Level

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.

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

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:

  1. Define a custom role using the 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)


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.

  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.


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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Prabhat Kumar Ranjan
      Prabhat Kumar Ranjan

      Thank you Ines Ahrens for documenting. This was long awaited requirement CPI.

      Author's profile photo Syambabu Allu
      Syambabu Allu

      Must try blog.Thanks for sharing in detailed.


      Thank you,


      Author's profile photo Naresh Dasika
      Naresh Dasika

      Great feature. Thanks for the detailed blog:)

      Author's profile photo Raffael Herrmann
      Raffael Herrmann

      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,

      Author's profile photo Ines Ahrens
      Ines Ahrens
      Blog Post Author

      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

      Author's profile photo Laxmi Narasimha Prasad Konda
      Laxmi Narasimha Prasad Konda

      Hi Ines,

      ** Please Ignore this question, I have updated via reply also **

      As this question & answer is quite old, we have presumed as the feature now ready on CF ( custom role creation with access policy is enabled in CF) , however we are not able to achieve desired outcome with help of access policy + custom role for editing an iflow in CF. Could you please help us with the latest status on the feature release , also help with the steps to follow if it has been released.


      Prasad Konda

      Author's profile photo Laxmi Narasimha Prasad Konda
      Laxmi Narasimha Prasad Konda

      Hi Ines,


      Please Ignore my request, we are able to achieve it now as expected.


      Thank you.




      Author's profile photo lucy taylor
      lucy taylor

      I used Zapier software for cloud integration. It has all the quality like it is automatically moves information between all your web applications. But this blog is giving us separate details about it.

      Author's profile photo Prabhat Kumar Ranjan
      Prabhat Kumar Ranjan

      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?





      Prabhat Kumar Ranjan

      Author's profile photo Ines Ahrens
      Ines Ahrens
      Blog Post Author

      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

      Author's profile photo Siegfried Lehmann
      Siegfried Lehmann

      Hello Ines,

      are there other artifact types than IFlows where i can set/create access policies ?

      At the moment type "Integration Flow" is preset and not changeable.
      I am on Neo environment.

      Best regards

      Author's profile photo Ines Ahrens
      Ines Ahrens
      Blog Post Author

      Hi Siegfried,

      the next product increment will allow restricting the access to messages in JMS Queues.

      Support for other artifact types as well as additional restrictions on Integration Flows (like Edit, Delete, ...) are envisioned for future releases.

      Best regards, Ines

      Author's profile photo Markus Villiger
      Markus Villiger

      Hi Ines

      Great Blog!:)

      We would like to use a depoyment process for access polices.

      Is it somehow possible to download access policies from a development system and upload it to a target system?






      Author's profile photo Ines Ahrens
      Ines Ahrens
      Blog Post Author

      Hi Markus,

      there is an OData API for maintaining Access Policies, which could be used somehow for such a scenario. However, this API is not public (not documented) and would also require some scripting to transform the response from one tenant into the batch for creating the same set on another. Creating the corresponding roles /role collections would still need to be done separately.

      I am interested in understanding the requirements in more detail, so, please feel free to contact me via mail.

      Author's profile photo Silviu Andrici
      Silviu Andrici

      Hi Ines,

      Thanks for the detailed blog.

      Would be possible or is there any feature that allows to give access to a certain group of users only to some restricted artifacts?

      What I mean is that Access policies, are used to give 'superpowers' to some users, but if instead we want to give access to one artifact only, is there any way to achieve that?

      Many thanks,


      Author's profile photo Ines Ahrens
      Ines Ahrens
      Blog Post Author

      Hi Silviu,

      Sorry for the late reply, I somehow missed your comment.

      If I understand your question correctly, you would like to restrict access to all but some artifacts.

      I see two slightly different ways to achieve this. In both cases you need to create one Access Policy per artifact group you wish to grant access to and assign the corresponding roles as desired:

      • Either make sure all artifacts are referenced by at least one Access Policy.
      • Or, create one Access Policy referencing all artifacts (matches .*) and do not assign it to any user.

      Best regards,


      Author's profile photo Helmut Skolaut
      Helmut Skolaut

      Hi Ines Ahrens

      good blog - i am wondering if there is a way to allow a group of people access to see the deployment artifacts itself but not allow him/her access in monitoring to the payloads (MPL, traces, etc.)

      As far as i understood the concept, it covers design-time and runtime with the Access policy and i don't see here a way to distinguish.

      BR Helmut

      Author's profile photo Ines Ahrens
      Ines Ahrens
      Blog Post Author

      Hi Helmut,

      your understanding is correct. The tasks restricted for a group of objects defined by Access Policies are "fixed" in the product and cannot be specified.

      However, "seeing" the artifacts is anyhow given, the views/lists are not restricted.

      In case the one person shall have different privileges on different objects, you would need to create multiple user accounts for the same.

      Best regards, Ines