Input Security and Formatting when connecting to external services

[filkin]

Hi!
I am quite new to PowerApps, but I am currently working on a PCF control that allows to connect to external service (Azure Storage), and I have few security concerns regarding the solution.

The idea behind the control is to place it on the form, so it must be able to be “context specific” (get account name to identify the container etc.), but also due to the restrictions posed by the Azure library, a Shared-Access-Signature must also be able to be retrieved.

As of now, I provide some connection information as input parameters to the control, which then connects to the desired service. Of course, this is a pretty bad solution as I can stop anytime in debugger, and change the value of the string and connect to the container that I should have no access to. 

1) Is there a way to somehow encrypt these input parameters? If so, could you possibly provide me with a step-by-step guide, as I am quite new to CRM and PA.
2) How would you provide parameters that match the current context? Let's say the directory name “{prefix}-{accountName}". Can you provide that as a single input variable (usage="input") or do I need to split it into two values: prefix and contextId, which would be concatenated by me within the PCF control?
3) Is there a way to sanitize the input prior to passing to the control? Ideally, I would like to lower the value. Is this possible?

Thanks!

[cchannon]

If you want to prevent users from hitting blobs they shouldn't see, you should control access to those blobs with Role Based Access Controls (RBAC) then in your PCF use MSAL to retrieve a token for the current user scoped to your blob and use that token. It will mean an auth prompt in the middle of your power app because the token you can acquire silently probably won't have the right scopes, but it is ironclad secure.

[filkin]

@cchannon 

Unfortunately, it seems that the current library does not support it, so I think I might be limited to SAS, or at least that is what I managed to find.

[cchannon]

What library are you talking about?

[filkin]

The idea that I also have is to create a container per CRM Account (to allow for simple deletion). This means that I would also need to grant access based on container.

For my solution, ideally, I would like to limit the scope to that particular user on the form, so that there is no way that can change the container, yet in current scenario I am passing the name of the container as the input parameter.

[filkin]

https://docs.microsoft.com/en-us/azure/storage/blobs/quickstart-blobs-javascript-browser

Here is the link. In addition, this would be the browser version that I would be looking into.

[cchannon]

OK, I see now. Yeah, I agree it isn't clear from that documentation how you would use proper claims-based authentication: I only see SAS.

However, you don't really need this library to work with azure storage accounts. You can interact with them directly using REST api calls, and this will make it much clearer how to use proper claims-based authentication. I suggest you check out the below:

Azure Storage REST API Reference | Microsoft Docs

Authorize with Azure Active Directory (REST API) - Azure Storage | Microsoft Docs

[filkin]

@cchannon 

I really appreciate all the responses. So I have checked the API also prior to the post, and there are just a few things that can potentially be an issue here:

Firstly, As each form should connect to a different container, there might be a scenario where a container may not exist (New Account form). This means that upon loading, the control would have to create a new container, and assign new policy to the users. The behavior is quite vague in terms of which users should have access to containers.
Secondly, assuming we give a single user access to all containers (as a consequence of the point above), this theoretically still does not prevent misbehavior in a form of forcing upload to another container.