Access Policy for securing design artifacts in the SAP Cloud Integration designer

[kamlesh_zanje]

Introduction

With the 5.22.x/6.14.x release, SAP Cloud Integration provides Access policies in the designer for integration flow to apply more granular access control in addition to the existing role-based access control.

In SAP Cloud Integration, user permissions are granted in a way that all tasks can be performed on all artifacts and data. Access policies provide a way to restrict access to selected artifacts and their data.

To know access policies, steps to create and activate access policies, how it works and other information, please refer the blog post 

In this blog, we will primarily focus on the extension of access policies that has been consumed in integration flow design time to provide controlled access and safeguard the operations at artifact and package level from unauthorized users.

This feature is described in the SAP Help Portal ( see Access policies in the designer for integration flow).

Let us understand how the Access policies in the designer will prominently help and resolve some of the crucial scenarios.

New with SAP Cloud Integration September 2021 release (5.26.x/6.18.x)

With this release, we have consumed access policy in the Script collection artifact and its corresponding design time operations are safeguarded.

In addition to this, we have consumed access policies to safeguard runtime operations such as

1. Deploy of artifact


2. Undeploy of artifact


3. Restart of artifact


4. Download of runtime artifact.

New with SAP Cloud Integration Aug 2021 release (5.25.x/6.17.x)

With this release, we have consumed access policy in the message mapping and value mapping artifact and its corresponding design time operations are safeguarded.

New with SAP Cloud Integration July 2021 release (5.24.x/6.16.x)

With this release, we have consumed access policy in the OData API artifact and its corresponding design time operations are safeguarded.

New with SAP Cloud Integration June 2021 release (5.23.x/6.15.x)

With this release, we have consumed access policy in the API-Based Integration Artifacts such as

1. REST API


2. SOAP API

Please consume access policy for the above mentioned artifacts and share your experience and feedback in the comment section.

Scenario

Assume two different departments from the same company access the common SAP Cloud Integration tenant for addressing their business use cases. Let the department be:

1. HR (Human Resource)


2. IT (Information Technology)

The most prominent issue which is faced by the tenant administrator is the grievance from the department where they complain that users from the other department are editing and deleting their integration flows.

 

 

In order to address this issue and make the life of a tenant administrator easy, fine granular access has been introduced in the form of access policies to provide controlled access at the artifact level and ensure the protection from an unauthorized user.

 

What are access policies in the designer for integration flow?

• Safeguards selected integration flows from access by Unauthorized users.


• Access Policies only allows users to view restricted integration flows, and all other actions being restricted, with an Error message.

 

Let us assume that a custom role is created/activated in the SAP BTP account cockpit for HR department and the users of the HR department are assigned to the custom role, Access policy is created, and the integration flows of the HR department are referenced to the custom role.

 

Now, if a user who doesn’t belong to HR department try to perform any operations on the HR integration flows, then they will be restricted and shall see an error message.

 

Restricted Artifact Actions

Actions that are restricted at the artifact level are edit, copy, download, delete, configure, mass delete, mass download, mass configure and simulation of integration flow.

 

A user from IT department try to configure the integration flowImage1: A user from IT department try to configure the integration flow.

 

On click of configure action, an error will appear for a user from IT department.Image2: Error notification/message to a user from IT department.

A user from IT team is not allowed to delete the access restricted integration flow

Image3: Error message on deletion of integration flow

 

On edit of the integration flow from the iflow editor, error message seen by a user from IT department.Image4: A user from IT team is not allowed to edit the access restricted integration flow

 

A user from IT department is not allowed to perform mass delete operation at the artifact level.Image5: Mass delete of integration flow is protected from an unauthorized user

Restricted Integration Package Actions

Integration package level actions are safeguarded if access to one or more integration flows is restricted and the actions are export, copy, transport, publish and delete.

 

A user from IT department is not allowed to export the package if one or more integration flows are restricted through access policies.Image6: Export action is protected from a IT team user

Note: All the above-mentioned operations at artifact and package level will be safeguarded via OData Remote APIs as well.

 

Conclusion

Hope this feature will enable you to protect a selected artifact from an unauthorized user in a designer.

In case of questions or feedback, please feel free to comment on this blog.

[manoj_khavatkopp]

Hi Kamlesh,

Thanks for the detailed blog.

If an access policy is created and say we assign a flow to that, note the user won't be able to edit neither see the payload during runtime. Is there a possibility just to restrict the user to edit that particualr iflow but he/she can still see the runtime payload?

Thanks,

Manoj

[kamlesh_zanje]

Hello Manoj,

No that is not possible, once the access policy is created and referenced to the integration flow, user can neither edit the flow in designer nor see the payload during runtime.

Regards,

Kamlesh.

[former_member751036]

Hi Kamlesh,

This functionality is not available yet package level. Any plans for that.

[kamlesh_zanje]

Hello Shameer,

Yes, enabling access policy at the package level is there in our roadmap.

There is no need to create 'n' number of access policies for your mentioned scenario. You can create one access policy and can reference the 'n' number of iflows in that access policy.

Regards,

Kamlesh.

[former_member751036]

Thanks kamlesh. Got it.

[siddhesh_pathak4]

If I have administrator or developer, I will still be able to access the IFLOWs? Which role will have priority?

[kamlesh_zanje]

Hello Siddhesh,

No, you will unable to access the iflows without access policy. Even if at all you have tenant admin or iNT.Developer role, you need access policy which you would have referenced to the iflows.

Please note, the application roles such as IntegrationDeveloper and  Administrator are at the tenant level.

Access policy provides a granular control to restrict access to selected artifacts and their data. This is a capability on top of application roles.

Let me know if it answers your question or you have a follow up queries.

Regards,

Kamlesh.

[siddhesh_pathak4]

Thanks for the quick reply Kamlesh!!

No further questions.. I set it up for ODATA API and it did not work..I again read your blog 🙂

Next steps:

In the successive increments, we have plans to consume access policies in the designer for other artifacts

1. REST API


2. SOAP API


3. ODATA API


4. Value Mapping


5. Integration Adapter

[kamlesh_zanje]

Access policy for REST API, SOAP API artifacts is available with 5.23.x/6.15.x release.

Access policy consumption in the designer for OData API artifact would be available probably with 5.24.x/6.16.release to factory. We will nevertheless update blog and product documentation for better transparency.

[ymAllen]

Great feature. Thanks!

[kamlesh_zanje]

Thanks for the feedback Allen.

[gkiranatos]

Hi Kamlesh,

Thanks for the detailed blog!

.Can we restrict the deploy authorization using access policies,if any user is having diploy authorization for all artifacts

Thanks in advance!

Best regards,

Kiran Gadde

[kamlesh_zanje]

Hello Kiran,

Thanks for sharing the feedback. As of today, you cannot safeguard deploy action via Access policy. But its there in our radar. We will update the blog and documentation once the deploy operation is protected via Access policy.  Hope it answers your question.

 

Regards,

Kamlesh.

[laxmangaddam]

Hello Kamlesh,

Thanks for this blog.

Do we have this restriction using Access policies even for API Management(API portal)?

Thanks & Regards,

Laxman

[kamlesh_zanje]

Hello Laxmam

Thanks for the feedback.

I can provide comment on the access policies from SAP Cloud Integration standpoint.

However not sure whether APIM had enabled restriction using access policies. I can check and get back to you.

 

Thanks & Regards,

Kamlesh.

[former_member250735]

Hello Kamlesh,

 

Actions that are restricted at the artifact level are edit, copy, download, delete, configure, mass delete, mass download, mass configure and simulation of integration flow.

 

Is there a way to also restrict the view of the iflow?

 

Thank

[kamlesh_zanje]

Hello Rami,

Thanks for posting the query.  Access policies feature in the designer restrict the edit level operations at artifact level such as copy, download, delete, configure etc which you have rightly pointed.

As of now, there is no way to restrict the display of the artifact(i.e. iflow) from an unauthorized user who doesn't have an access policies.

Regards,

Kamlesh.

[kamlesh_zanje]

Hello all,

Access policies at the package level is released and available for the consumption. 

Refer the blog post SAP Integration Suite – Access Policies for Integr... - SAP Community

Regards,

Kamlesh.

[Umid]

Hi Kamlesh,

I'm currently working with both Access Policy types. However, I've encountered an issue related to how access is managed for our packages. We have two categories of packages: those intended solely for internal use (Internal_Package_01, Internal_Package_02) and those designed for external use (External_Package_01, External_Package_02). My goal is for internal users to access both internal and external packages while restricting external users to only the external packages.

My current solution involves creating Package-level Access Policies for the external packages and Artifact-level Access Policies for all artifacts, assigning these policies accordingly. However, this approach has led to a complication: internal users, upon accessing an external package, cannot save any artifacts. They encounter an error message stating, "You are not authorized to save the package due to package-level access policies. Contact your tenant administrator for access."

Could you suggest alternative strategies or improvements to address this situation more effectively?

Thank you