Community
Integration Blog Posts
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

Enforcing Package-Level Segregation in a Shared SAP Cloud Integration Tenant

felipe_correa
Explorer
4 weeks ago
791

The Problem Nobody Talks About

Shared SAP Integration Suite tenants are more common than SAP's documentation assumes. Whether the reason is cost optimization, organizational structure, or a multi-subsidiary model, many teams end up with developers and operators from different organizations working on the same Cloud Integration tenant.

At some point, someone asks the question:

How do we make sure our developers cannot accidentally touch another organization's integration flows?

You open the SAP Help Portal and review the standard role collections: PI_Integration_Developer, PI_Administrator, PI_Business_Expert, PI_Read_Only. They are well designed and aligned with common personas — but they are tenant-wide by default. Assigning one of them gives the user access across the entire tenant, not just to a specific organization's packages.

That gap is what this article addresses.

Why Standard Role Collections Are Not Enough

SAP's standard role collections answer one question well:

What can this user do?

In a shared tenant, there is a second question that matters just as much:

On which packages can they do it?

Without an answer to the second question, you expose yourself to real risks:

  • A developer from Organization A can edit or redeploy integration flows belonging to Organization B.
  • An operator from Organization A can configure and deploy Organization B artifacts.
  • A tracing user from Organization A can inspect message payloads from Organization B processes, potentially exposing sensitive business data.

The solution is not to replace SAP's authorization model. It is to extend it correctly.

The Architecture: Two Layers of Control

The model combines two mechanisms that work independently but must be used together.

Layer 1 — Role Collections: what the user can do

Custom role collections in SAP BTP define the functional permissions: configure parameters, deploy artifacts, monitor logs, edit integration flows, manage security materials, view payloads. This is standard BTP role management, and it answers the first question.

Layer 2 — Access Policies: which packages those actions apply to

Access Policies in SAP Cloud Integration restrict the scope of the functional permissions to a specific set of integration packages. A user may have permission to configure and deploy — but only for the packages explicitly listed in the corresponding Access Policy.

The link between the two layers is a custom role created from CustomRoleTemplate in BTP. This custom role carries a static attribute (custom_role) whose value must match the Access Policy role name in Cloud Integration exactly. That value is the binding key between both layers.

Both layers are required:

  • Role collections without Access Policies remain tenant-wide.
  • Access Policies without the matching custom role are not enforced.
  • A mismatch in the attribute value — including case differences — breaks the binding silently.

Diagram 1 — Two-Layer ArchitectureDiagram 1 — Two-Layer Architecture

How the Authorization Check Works

Understanding the enforcement mechanism helps you design and troubleshoot the model correctly.

When a user attempts to act on an integration package — configure, deploy, edit, trace — Cloud Integration performs a two-level check:

Level 1 — Task check Does the user's role collection include the role template required for this action? The functional scopes are evaluated from the user's XSUAA token. If WorkspacePackagesConfigure is absent, access is denied regardless of anything else.

Level 2 — Scope check Does the user have a custom role whose custom_role attribute matches an Access Policy that references this package? The runtime resolves the attribute at call time and compares it against the registered Access Policy role names. If no matching policy covers the target package, access is denied even if the user has the functional role template.

Both checks must pass independently. The practical consequence:

  • Functional role without a matching Access Policy custom role → blocked on every protected package.
  • Custom role without the functional role template → blocked on every action regardless of package.
  • Custom role present, but the target package not listed in the Access Policy → blocked on that specific package.

This is genuine platform-level enforcement, not just UI restrictions.

What You Need to Know Before You Start

These are the behaviors that are easy to miss and hard to diagnose when you get them wrong.

Role collections are scoped per subaccount. A role collection created in DEV does not exist in PRD. Each subaccount where the shared tenant is consumed requires its own set of role collections and custom roles. Access Policies, by contrast, live inside the Cloud Integration tenant and are shared across subaccounts.

Create the role collection before the custom role. The BTP wizard for creating a custom role requires you to assign it to an existing role collection. If the target collection does not exist yet, you cannot complete the wizard. The recommended order is: role collection first, then custom role, then Access Policy.

The attribute value must be confirmed as a tag. When configuring the custom_role attribute in the custom role wizard, typing the value is not enough. You must press Enter to confirm it as a tag. The Next button will not activate until this is done. This is easy to overlook and produces no error message.

PI_Business_Expert is a role collection, not a role template. If you need tracing and payload visibility in a custom role collection, you cannot nest PI_Business_Expert inside it — SAP BTP does not support nesting role collections. The capability you need is the underlying role template AuthGroup_BusinessExpert (it!bXX). And critically: without combining it with your organization's custom role, payload visibility applies across the entire tenant.

Package references are not dynamic. Access Policies do not auto-discover packages. Each integration package must be added explicitly as an artifact reference (Type: Integration Package, Condition: Equals, Value: exact package name). A naming convention helps with governance, but it does not automatically protect new packages — that requires an operational process.

Diagram 2 — Creation OrderDiagram 2 — Creation Order

Implementing the Pattern

The implementation follows three steps. The SAP Help Portal documents the role templates and Access Policy configuration in detail; the focus here is on the design decisions and sequencing that matter in a shared tenant context.

Step 1 — Define your profiles and their functional scope

Before touching BTP, decide what each organizational profile needs to do. A typical setup for a production environment includes at least:

  • An operator profile — configure parameters, deploy artifacts, monitor logs. No iFlow edit access.
  • A tracing profile — payload visibility and trace activation, kept separate from the operator profile so it can be assigned temporarily during incident investigation and revoked afterward.
  • An administrator profile — full design-time access including iFlow edit, transport, and Access Policy management.

For non-production environments, a developer profile with full design-time capabilities is added in the DEV subaccount only.

Each profile becomes a custom role collection. The functional role templates for each profile are documented in SAP Help — Tasks and Permissions.

Step 2 — Create the custom role from CustomRoleTemplate

In BTP Cockpit, navigate to Security → Roles and search for CustomRoleTemplate under the Cloud Integration runtime application (identifier it!bXX — the exact value is tenant-specific, verify it in your subaccount).

Create a custom role with:

  • A descriptive name (e.g., ORGA_PI_PackageAccess)
  • Attribute: custom_role, Source: Static, Value: same as the role name
  • Assigned to the first role collection you created

Then add this custom role to every additional role collection that must be scoped to the same organization's packages. Any role collection missing the custom role operates without scope restriction.

Step 3 — Create the Access Policy in Cloud Integration

In Integration Suite, navigate to Monitor → Integrations and APIs → Manage Security → Access Policies.

Create a policy with a Role Name that matches the custom role attribute value exactly. Then add one artifact reference per integration package owned by the organization:

  • Type: Integration Package
  • Attribute: Name
  • Condition: Equals
  • Value: exact package name as shown in Cloud Integration

No wildcard or regex matching is available for this combination — each package must be listed individually.

Diagram 3 — Shared Tenant ModelDiagram 3 — Shared Tenant Model

Keeping the Model Consistent Over Time

The initial setup is the easy part. The harder part is operational discipline around new packages.

Every time a new integration package is created, it must be explicitly added to the corresponding Access Policy. Until it is, the package is unprotected — any user with the right functional role templates can act on it, regardless of which organization owns it.

A practical governance process:

  1. Enforce a naming convention (e.g., ORGA_*) so package ownership is unambiguous.
  2. Add the package to the Access Policy as part of the package creation checklist — before any iFlow is deployed into it.
  3. No changes to custom roles or role collections are required for new packages.

The naming convention does not enforce protection automatically. It makes the governance process auditable.

Conclusion

The combination of custom role collections and Access Policies gives you genuine package-level segregation in a shared SAP Cloud Integration tenant — enforced at the platform level, not just through UI restrictions.

The model has a deliberate boundary: it covers Cloud Integration (CPI) design-time and runtime access. API Management — API proxies, API products, Developer Hub permissions — has a different authorization model and requires a separate governance approach.

The two things that determine whether this model holds up in practice are not technical: they are the operational process for new packages, and the governance over who holds role collections that include AccessPoliciesEdit. The platform enforces the rules you define. Defining them consistently is your responsibility.

AI disclosure: AI tools were used for language tuning and structure. The technical content, implementation decisions, and validation were performed by the author on a live SAP Integration Suite tenant running Integration Suite 4.7.0 and Cloud Integration Runtime 8.40.25.

References

 

1 Comment