Unanswered

Input Security and Formatting when connecting to external services

(0) Share

Report

Posted on by 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!

Categories:

Power Apps Pro Dev & ISV

I have the same question (0)

All responses (7)

Answers (0)

cchannon 4,702 Moderator on at

Like (0)

Report

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.

Was this reply helpful? Yes No
filkin 8 on at

Like (0)

Report

@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.

Was this reply helpful? Yes No
cchannon 4,702 Moderator on at

Like (0)

Report

What library are you talking about?

Was this reply helpful? Yes No
filkin 8 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
filkin 8 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
cchannon 4,702 Moderator on at

Like (0)

Report

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

Was this reply helpful? Yes No
filkin 8 on at

Like (0)

Report

@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.

Was this reply helpful? Yes No