Access Policy in SAP CPI

List of contents

• Introduction
• Roles and role collections
• Features
• Pre-requisites
  • Creating a role collection
  • Creating a custom role
• Creating access policy in CPI
  • Creating a role
  • Creating a reference
• Case 1: Restricting access to an integration flow
  • Editing the artifact
  • Deploying the artifact
  • Viewing the trace data
  • Deleting the artifact
  • Downloading / exporting the artifact
• Case 2: Restricting access to an integration package
  • Addition of artifact
  • Deletion of artifact
  • Exporting / downloading an artifact from package
  • Deleting the package
  • Exporting the package
• Other cases

Introduction

An Access Policy in SAP Cloud Integration is a security configuration that defines the rules and conditions governing who can access your integration flows or APIs, and how that access is granted. Essentially, it sets the controls for managing access to integration artifacts based on specified criteria.

SAP Integration Suite comes with default role collections that determine which tasks you are entitled to within a specific tenant (e.g. to administer the tenant, to develop integration artifacts, etc.).

Roles and role collections

A role in SAP BTP defines a set of permissions or scopes that grant access to specific features or actions in an application or service.

A role collection is a container or grouping of roles that can be assigned to a user. Instead of assigning roles directly to users, you assign role collections. A role collection can contain multiple roles from one or more applications.

In SAP Integration Suite, the default role collections apply at the tenant level and do not control access to individual integration artifacts such as integration flows, mappings, or script collections.

For this reason, SAP Integration Suite allows you to create and manage Access Policies that restrict access to specific integration artifacts by assigning custom role collections to the required users.

Features

With access policies you can restrict access to integration artifacts and to the data stored and processed by them.

With access policies, you can define artifact references for:

• A package – by which all artifacts of the integration package and the package actions are protected.
• A specific artifact type – for example, script collection or integration flow or any of the types shown in the screenshot below.

Pre-requisites

Access policies in the Cloud Foundry environment are associated with roles based on template CustomRoleTemplate and assigned via role collections.

Before getting started it is important that:

• You have provisioned SAP Integration Suite within a certain subaccount on SAP BTP.
• You are assigned the role collections related to SAP Integration Suite.

Let’s look at the step-by-step process involved in the creation and functioning of an access policy.

Creating a role collection

The first step is to create a role collection where we will be assigning the custom role we create in the next step.

Go to the SAP BTP Subaccount where your SAP Integration Suite tenant is deployed and then select Role Collections under the Security tab.

Click on the Create button, fill in the necessary details and select Create as shown below.

We have successfully created a role collection.

Creating a custom role

For creating a role select Roles under the Security tab. As we will be making a custom role, scroll down to the role template named CustomRoleTemplate under the application name it and click on the Create Role button.

Enter a role name and description for the custom role we are creating.

Enter the attribute (i.e. the access policy name with which we create in CPI) and press Enter. We can add any number of attributes here.

Note: It is important to remember the value of your role attributes, as this will be used as the name of your Access Policy.

In this step assign the role we are creating to the role collection we created earlier, as shown below.

Now we will assign the role to a user for whom the access policy should not be applied. This setup allows us to test and observe how the access policy functions by comparing the impact on both users.

In the image below you can see that the role collection is assigned to only one user.

Creating access policy in CPI

Now log in to the Integration Suite of the same subAccount and go to the Monitor tab → Integrations and APIs → Access Policies.

Creating a role

Now select the Create button and enter the role name.

Note: The role name we are creating here should be the same as the one we mentioned in the attribute of the role we created at the BTP level.

Creating a reference

The next step is to create a reference which defines what condition we are implementing via this access policy. Select the Create button.

Enter the reference name and description for the reference. In the condition we are asked to select the type of artifact (integration flow, integration package, script collection, etc.) for which this access policy applies.

For testing, let’s select the condition type as Integration Flow.

The next step is to choose the attribute, either ID or Name. 

Let’s select Name for our scenario.

We can see that we have two radio buttons, Equals and Matches.

• If you choose the operator “equals”, you must specify the exact name of the artifact as value.
• If you choose the operator “matches”, you have to enter a valid Java Regular Expression.

Let’s choose Equals and enter the condition value as ZTesting.

This indicates that the integration flow named ZTesting will be restricted for the user to whom the role we created is not assigned. Let’s see that in the next steps.

Case 1: Restricting access to an integration flow

Let us create a dummy integration flow with the name ZTesting. As we have created a role with a reference saying that access to integration flow ZTesting is restricted, once the artifact is deployed, the user with the role assigned can only do the following operations:

• Edit the artifact
• Deploy the artifact
• See the trace data
• Delete the artifact
• Download / export the artifact

If we try to do the above-mentioned activities with a user who doesn’t have the role assigned, the following will be shown as an error.

Editing the artifact

Deploying the artifact

Viewing the trace data

Deleting the artifact

Downloading / exporting the artifact

Case 2: Restricting access to an integration package

Now let us create a reference for restricting access to a particular package. Go to the same role which we created earlier and press the Create button.

Now, provide the reference name and description. Since we are restricting access to a specific package, select the condition type as Integration Package and give the value as ZAccess_Policy as shown below, then select Create.

Let us create a dummy integration package with the name ZAccess_Policy. Once the package is created, the user with the role assigned can only do the following operations:

• Editing the package
  1. Adding an artifact to the package
  2. Deleting an artifact from the package
  3. Exporting / downloading an artifact from the package
• Deleting the package
• Exporting the package

If we try to do the above-mentioned activities with a user who doesn’t have the role assigned, the following will be shown as an error.

Addition of artifact

Deletion of artifact

Exporting / downloading an artifact from package

Deleting the package

Exporting the package

Other cases

It is important to note that access policies are not limited to Integration Packages or Integration Flows. The same approach can be applied to other artifacts in the tenant, such as:

• OData API
• REST API
• SOAP API
• Script Collection
• Value Mapping
• Message Mapping
• Message Queue
• Global Data Store
• Global Variable
• Data Type
• Message Type

If a user does not have the required role assigned, any attempt to perform restricted actions—such as editing, deleting, or similar operations—on the above-mentioned artifacts will result in an authorization error.