As of increment 2401 of SAP Integration Suite, you can define access policies for integration packages. This extension makes the lives of tenant administrators easier who need to manage large numbers of integration packages and selectively restrict access to integration content for different user groups.
Short reminder of what Access Policies are: With an access policy, you can protect groups of integration artifacts against undesired access. You define access policies as described in SAP Help Portal under Managing Access Policies | SAP Help Portal. For example, you can define an access policy for all integration flows that fulfil the condition: name contains the string ‘Read’. As consequence, all integration flows that meet this condition are protected against unauthorized access. Protection against unauthorized access covers:
To enable dedicated users to access these protected artifacts, a role needs to be defined in SAP Business Technology Platform (SAP BTP) cockpit that is associated with the access policy (for more information, see the online documentation). Access policies can be defined for all available integration artifact types such like integration flows, value mappings, and so forth. |
Back to the new feature introduced with increment 2401.
When you open the access policy screen in the Monitor > Integrations and APIs section of SAP Integration Suite (Access Policies tile), you now notice that you can also select Integration Package as Type:
Using this new option, you only need to specify one single artifact reference to protect all artifacts of an integration package. In the example above, an artifact reference for the integration package with the name My First Integration Package is defined.
You now also understand to what extent the extension makes the life of the tenant administrator easier, whom we talked about earlier:
If you like to protect all artifacts in a dedicated integration package, you can now define an access policy with one single artifact reference. Before this enhancement, you needed to create an individual artifact references for each integration artifact type separately.
Use Cases
You may be wondering in which cases it makes sense to define access policies for integration packages. Let me point out the following rule of thumb:
| Option | Use Case |
| Define access policy for an integration package … | If you like to protect all the artifacts of an integration package (including artifacts of all types). |
| Define access policy for individual artifact types (for example, integration flows and value mappings) … | If you like to protect only few, but not all artifacts of the integration package. |
Compatibility with Access Policies for Specific Artifact Types
As said, an access policy for an integration package affects the access to all artifact types contained in the package. However, you can still define access policies for individual artifact types. Now the following can happen: you may want to define an access policy for a specific integration package that contains artifacts for which other, artifact type-specific access policies exist already. What happens in such a case? The message at the top of the dialog provides a clue: for compatibility reasons, existing access policies for individual artifact types will remain intact when you define an access policy for an integration package. Access policies for dedicated artifact types co-exist with access policies on integration package level. Or, phrased differently: When you define an access policy for an integration package that contains artifacts that are also protected by another access policy (for example, by an access policy for a specific group of integration flows), the latter remain valid as well. The message prompts you to check if access policies have already been defined for specific artifacts in your package that you want to protect as a whole.
Let's see how the co-existence of access policies on integration package and on artifact level affects things in a specific example.
Let’s assume that an integration package is protected by one access policy. Furthermore, this integration package contains an integration flow that is protected by another access policy.
To walk you through the example step-by-step, the following two access policies are defined:
| Access Policy Name | Protects |
| PackageAccess | Artifacts contained in the integration package with the name My First Integration Package |
| FlowAccess | Integration flows (across all integration packages) with a name that starts with the word Read (matches regular expression ^Read.*) |
The tenant has two integration packages with the names My First Integration Package and My Second Integration Package. Both packages contain also integration flows protected by the artifact-related access policy (integration flows with a naming starting with Read).
As a result of this setup, the artifacts are now protected as shown in the following figure:
As we said that access policies protect the specified artifacts – unless a user has a role assigned that is associated with the access policy – we can do the combinatorics with 4 fictitious users with different role assignments:
| User | Assigned role | Role associated with access policy* | Can access |
| User1 | Role1 Role2 | PackageAccess FlowAccess | All artifacts in all shown integration packages |
| User2 | Role1 | PackageAccess |
|
| User3 | Role2 | FlowAccess |
|
| User4 | (No role assigned) | n.a. | Because this user does not have either of the roles, they are subject to the access restrictions defined by both access policies. As a result, the only artifact they can access is the artifact that is covered by none of the access policies (the non-protected integration flow in the non-protected integration package). |
*To be more precise: Role associated with an access policy means: For the Values attribute of the role a string is specified that matches the name of the access policy. For more information on this, check out the online documentation in SAP Help Portal under Creating Custom Roles for Access Policies | SAP Help Portal.
- SAP Managed Tags:
13 Comments
