Just getting started here, and my concern is the visibility of my app and the data connection.
Started an app, and I established a SQL server connection, and then saved the app to "The Cloud" (in my organization). I was able to close ("Leave") the app. I was able to find the app again under "My Apps" (along with a whole bunch of apps that are not mine, and I've never seen before), and reopen ("Edit") it again. When it reopens, at the top I now have this message: "You are using one or more implicitly shared connections." This concerns me.
I wouldn't mind anyone opening the app, but I'm concerned about someone editing my app with it's "Data" (SQL connection). How do I limit the visibility of my app for editing, and how do I protect my connection from re-use, etc.?
Is there an article on this that someone could share?
Maybe using SQL Server is a bad idea for Power Apps, and it's best to just stick with spreadsheets in SharePoint.
Hi @joglidden2 ,
This is a great question as many app makers understand very little about how the platform works - which is fair, because with a 'no-code / low-code' byline we expect the majority of makers to be non-developers, oblivious to security or application architecture concerns. But it does help for those who manage these platforms to understand what can and should be done to foster and protect innovation at the no-code/low-code level, while also protecting against unintentional risks. Helping makers understand a little more doesn't hurt either - so apologies up front for using your post to dump a whole lot of information 🙂
Firstly, platform features and capabilities as well as connectors change often and are constantly updated, so this may be relevant for a specific connection type today, and become irrelevant tomorrow - so focus on the principles here, not the specifics.
For the SQL connector specifically there are some updates that address some of the issues I mention below - but I must stress that this may not apply in your instance and even if it could apply, you should seriously consider ALL aspects of security and governance when looking at these things.
Secondly, security and governance in the platform is a very deep and wide topic - so this post is LONG but doesn't touch even 1% of the consideration. You clearly have a good understanding of the impersonation risks, so this could have been a much shorter answer, but I wanted to highlight considerations many miss while still linking it to your question, so others can also read and hopefully understand this a little better. There are probably some shorter blog posts out there you can read, but hopefully this helps someone 😁
Lastly, different organisations have different approaches to innovation and governance - some industries are more regulated than others - but regardless of this, everyone should have a view of what their stance is. The Power Platform out the box supports open innovation - that means some default configurations that may not be desirable for many organisations.
The short version:
So if you just created a Canvas app and published it - nobody else will see it. The apps you can see are either your own, Canvas apps that have been shared with everyone, Canvas apps that have been shared with you explicitly, or model-driven apps.
That said, there are a number of things to consider when it comes to security, governance and compliance on the power platform, and to make this useful for everyone, these require some background explanation - hence the long version;
Publishing vs Sharing:
Publishing your app is not sharing your app. It's just making the current "edit" version the "live" version which is the version you see when you "play" your app. If you've published your app but haven't shared your app with anyone, nobody will be able to access it or the connections you use in it.
Sharing your app is an explicit action - you need to decide who you're going to share it with, and what their role will be. They can be a normal user who can run your app - or you can designate them as an 'owner', in which case they can edit your app. This is however completely within your control.
They also need access to the data your app uses - Sharing your app does not automatically share the data your app connects to with people - but it's here you need to be cognisant of implicitly shared connections vs explicit connections (discussed below). Sharing data is not the same as sharing access.
But first, it helps to understand the environment context within which connections operate.
When it comes to environments, what is not necessarily appreciated about them is how they relate to connectors, connections and how the Default environment in a tenant is created and configured up front.
An environment is an isolated 'box' that contains Apps, Flows and Connections (and possibly a Dataverse database).
Apps, Flows and connections are specific to the environment they are created in. You can't create an App in one environment that uses a Flow from another. You cannot use a connection in one environment that was created in another.
When a tenant is created, a Default environment is also created - the default configuration is quite open by design, as it's meant to be a sort of 'play pen' for the organisation to explore and play with apps and flows - however if you leave it as it comes out the box without introducing some governance, it can become difficult to manage.
The characteristics of the "Default" environment in a tenant are varied, but in this case these particular characteristic should be noted;
Organisations can (and should) create additional environments that give you more control over who can build apps in them and what connectors they can use in them - but your Default environment will always allow everyone with a license to build apps in it - so for control options in the "Default" environment, you can only manage what connectors are usable in this environment. You can also control who has a license at a global tenant level, but this should probably be a last resort as the license applies equally to users and makers - so if you remove someone's license they can't make or use an app in any environment.
ConnectORS vs ConnectIONS:
So, browsing your Connectors you will see hundreds of predefined connectors available - from O365 services, to Google services, Social platforms, Azure services and yes, SQL and others. These "templates" are added to constantly.
Browsing your Connections - you might see none - that is until you use a connector to create your own instance of a connection. You might have done this just by running someone else's Power Apps in which case you might have lots already.
Once you have a Connection to a service in an environment, you can use that specific Connection in your apps and flows in the same environment - or you can create more. Having multiple connections to the same source with the same credential is possible - it's just a little redundant in my opinion. You can have multiple connections to the same source with different credentials as well.
Implicitly Shared vs Explicit Privilege:
Most M365 and related power platform connectors support AAD authentication which is a user-context based authentication of a sort - this just means that the connection will always be made in the context of the user using it. These explicit role-based privileges and related authorisation tokens are granted based on the user creating the connection (such as security roles for Dataverse, OneDrive for Business, SharePoint Online and so forth).
Connection context you create with these connectors are not implicitly shared when you share your app - your users would have to create and authenticate their own connection to use it. This is why you can't just share an app that uses SharePoint Online lists as a data source with users and expect the app to work - you also have to make sure their user accounts have access to the SharePoint Online list the app uses, because they will connect to it in their own user context.
This is why you see a connection permissions request pop up the first time they run it - you'll notice they have to give approval for the app to use their connection context if they already have one for the services the app uses, or they have to create it and then provide approval for the app to use it.
Some connectors or data sources however might not support this and so instead allow you to 'bake' the connection credentials into the connection when you create it and share the connection itself.
As you're no doubt aware, this means that the connection will always use the credential you gave it when you create it - you've shared the connection and it's credential context itself. They won't see the password or anything, but they can still use it.
With an implicitly shared connection, when you share your app with another user they create a connection to the service using the same connection you created - not their own.
A user using your app with this connector will effectively be impersonating the credential configured in the connector.
That might already sound like a problem, but actually, having users use a shared connection and impersonate the connection credential is an intentional outcome of implicitly shared connections - that is by design. So it's not necessarily a problem as long as they can't reuse that connector and use it in ways you didn't necessarily intend them to.
In the normal course of events, a normal user can only use your app the way you build it and can't manipulate what your app does with the connections it uses.
If you make them an 'Owner' of your app, then they can pretty much do what they want with it. That too, is not actually the problem, because it requires you to make them an owner, which is an intentional action.
HOWEVER - what is often not intended is this - if you share that app with a user (as a normal user, not an 'owner') and that user is also a Maker in that same environment, that user can go and create another app of their own and reuse your connection in their app (because you've implicitly shared the connection with them).
Because they're making their own app, they can now use whatever queries they want with that connection and credential, potentially accessing stuff you didn't really intend for them to access when you were building your original app.
I create an app with a SQL connector and use admin-level credentials on the connector. My app only shows the user data from a specific table and doesn't allow them to write anything, only read info. They can't mess with the app code, so their perceived "privilege level" when using my app is 'read-only based on whatever the app displays to them' - even though they would effectively be impersonating my admin credential which has much higher privileges.
I share the app with "Bob" who also happens to be a Maker in the same environment. The SQL connection I created is also implicitly shared when I share the app. Bob runs my app and then decides to build his own app in the same environment.
When Bob adds a SQL connector to his app, he sees he already has my SQL connection which he can reuse.
Bob adds the connection to his app and can now run pretty much any query he wants on any table admin has access to, inside his app.
This is definitely not what we want! Bad Bob! Well, not really, Bob's just doing what I've allowed him to do.
Coming back to our Default environment - everyone is a Maker by default in the Default environment. Now you can see the problem. If my admin-SQL-connected app is shared with anyone in the Default environment, they can do what Bob just did.
The way to deal with this is to consider the governance aspects across People, Process, Technology and Culture.
This involves having dedicated people who manage the platform, a framework within which they can operate and tools to support them, all of which support the innovation culture of the organisation. Nurture, not strangle. Guard, not block.
First and foremost - your organisation should have a governance and compliance framework to manage these things. Your admins can use the CoE Toolkit for guidance and tools, as well as the Platform administration configuration - but these are just guides and technology levers - your organisation should have a governance stance that dictates how these levers should be configured and managed to support a framework that allows for business innovation while at the same time protecting against unintended risks.
Now, I have no clue what level of maturity your organisation is at with regards to platform governance, so while we can assume 'low' for what follows, that doesn't mean it is or that they aren't or haven't already dealt with these issues...
Consider a number of controls;
For example, while you (and by "you", I mean "your admins") can't control who is a Maker in your Default environment, you can control what those Makers can do in that environment.
They can also decide who can create environments - By default, anyone can create an environment, but your admins may already have turned this ability off.
Your admins can (and should) implement an environment strategy that determines who can create environments, what environments can be created by whom, and who can create what inside those environments.
Your tenant "Default" environment should be considered as a playpen, or 'personal productivity' space for non-business critical or non-integrated productivity solutions.
You can for example stop users from creating apps and flows with implicitly shared connections in the Default environment, or any connectors that fall outside the context of 'personal productivity' - and only allow them in controlled environments.
Let's say we stop people from using SQL connectors in the Default environment, but create another environment where I'm a Maker but "Bob" isn't, and SQL connections are allowed. I can still share my App and its implicit SQL connection with Bob, but as it's an environment where he is not a Maker, he cannot reuse my connection in his own apps and flows because he can't create apps and flows in this environment. He also can't reuse the connection in any other environment where he might be a Maker because connections are environment specific.
Use Role Based Access Control with the correct privilege level at source. My SQL connection credential should be privileged in SQL according to the function of my app - instead of using an admin (or even my own credential), I should rather create and assign a role with the minimum requisite privileges it needs only for my app to work - and nothing else.
In my opinion, impersonation is always going to be a security thorn, regardless of whether it's warranted or not - so if you can avoid it by using a source that supports AAD authentication, do that instead. Otherwise if you're stuck with it for whatever reason, then try to use a very narrow scope of privilege for your impersonation account.
In this instance, I can't use AAD SQL, so I should possibly create a role that only has read access to views or tables I specifically want to surface in my app. I could then create a 'myPowerAppUsers' account in SQL or on AD and assign it to the role. I should also possibly consider whether I can implement row or even field-level security for my data source and assign those privileges to the role as well.
Like I said, LONG post, but hardly scratches the surface. Here's a list of takeaways that might help;
Apologies for the long response, but I hope it helps to raise awareness of this to more people and kudos to you for asking a great question.
@RusselThomas Thank you for the detailed response. I'm still in the process of digesting all of these considerations, and I'll come back here to update my understanding, and respond with more questions.
BTW, I'm in the process of working through the LinkedIN learning series by Phil Gold "Power Apps: Building Data-Driven Apps", and he is using Excel in OneDrive/SharePoint as his data source, while I'm trying to follow along using a SQL Server data source, which how my question was originally inspired.
@PhilGold (this might be the author of that course)
@RusselThomas Thank you! This is exactly what I've been looking for. I've been scouring the documentation fruitlessly to get more understanding of user context for connections and the risks around them being reused/repurposed and this really helps.
Are you aware of any documentation that goes into this kind of depth?
Hi @DynAB ,
Nothing particularly official or technically detailed unfortunately.
I did a quick search and there is some confirmation on implicitly shared connections behaviour here -Share resources used in your canvas app - Power Apps | Microsoft Docs but that's about the most detail I've found.
If you do find something please do share 🙂
Thank you Russel, I'll add that to the resource list.
I'll happily share if I find something but I don't hold out much hope! I was so pleased to find your very detailed post - it answers all the questions we were puzzling about in a head-scratching session this morning. This definitely feels like a gap in the documentation - who should I lobby?
To be honest I'm not sure - you can perhaps try and use the Feedback link on that page?
I've also submitted a feedback request asking for more detailed documentation on the Connector framework in the meantime.
That said, it's usually very difficult to get much of an 'under the hood' view of SAAS-services from an integration and architecture perspective - we can extrapolate from observation and unwrapping custom connectors what the basic premises are, but I agree - some officially documented confirmation would be nice 😊
This training provides practical hands-on experience in creating Power Apps solutions in a full-day of instructor-led App creation workshop.
Learn from the top Power BI, Power Apps, Power Automate & Power Virtual Agents experts!