cancel
Showing results for 
Search instead for 
Did you mean: 

Grant users read-only access to the context of a sap build process automation workflow

lukasmetzger
Participant
0 Kudos
238

Hi everyone,

I am currently facing the issue, that I want to grant read-only access to the context of a sap process automation (SBPA) workflow to my end users, via a REST call. Hereby, I find myself in the following scenario. I created a custom UI5-Application that uses the instance-id of a workflow to display the context. Of course, I want to design the authorization in such a way that the user is not able to manipulate the call to the SBPA API by,  for example, sending a post request via Postman.

To implement this, I have evaluated the following options, which have not led to a satisfactory result:

  • Create a destination with client id and client secret of the SBPA service intance
    • By doing this, I enable the user to access the context but also to take the called URL and send a post request, even though the actual credentials are concealed in the destination. 
  • Use API Key's within SBPA
    • I was not able to get them to grant access at all. In addition, I am unsettled by the following statement in this documentation on API keys: "You only need to use API keys for triggers that run automations."

Maybe I am missing something or one of you has another idea and can guide me into the right direction.

Thanks in advance,
Lukas

View Entire Topic
Dan_Wroblewski
Developer Advocate
Developer Advocate

Only someone with ProcessAutomationAdmin role is allowed to update the context.

And if you use a User Token Exchange authentication in the destination than the call will know the user.

At least it should work 😺

lukasmetzger
Participant
0 Kudos

Hi Dan,

that is correct. But the GET operation also requires the same Role:

lukasmetzger_0-1728393772555.png
So how do I differentiate between the two, if I only want to allow the READ?


Best regards,
Lukas

Dan_Wroblewski
Developer Advocate
Developer Advocate
0 Kudos
Silly me. I think if the API itself doesn't let you distinguish those 2 use cases, and the destination mechanism in the cockpit doesn't let you control access at the HTTP method level, then you are left with middleware (e.g., API Management or a CAP service). The only other way I can think of is if the original API had different URL paths between the GET and the POST but that is not the case. I had also thought of using the CSRF mechanism to block POST requests but I could not figure out how to get the flow to NOT handle CSRF but there may be a way.
lukasmetzger
Participant

Hi Dan,

thanks again for your reply! 
I evaluated the options and came to the same conclusion that a middleware is necessary. In my case, I am using the API Management with a custom API that is restricted to READ operations.

Thank you very much for your input and have a nice day 🙂