Logic App Tips: Personal Account is an issue

Highlight

Do you use your own accounts when developing your logic apps? Then stop!

This one is one of the most dangerous bad practices I’ve seen when people develop logic apps. Let’s talk about it.

Intro

When developers build solutions using Logic Apps, they often will be required to connect to external services. When the services are within Azure, in majority of cases developers will use Service Principals or Managed Identity of the logic app.

But when developers connect to services like

• Exchange / Outlook
• Gmail
• SharePoint
• OneDrive
• Box
• etc…

Instead of requesting separate account, they just click and use their own personal account.

Why is this a problem??

Honestly, this is a huuuge problem. Mainly for two reasons

1. This is a security incident
2. These connections fail when user moves or leaves the organization/team

Let’s discuss each separately

Security Incident

One personal account is saved, Azure creates an API connection resource in your resource group. This resource can be reused by anyone with a development access in that RG!

So basically, anyone with access to that RG can create a new logic app or edit existing logic app and leverage that connection.

Scenario #1 - Accessing SharePoint

So for example, let’s assume I’ve logged in to SharePoint using my personal account [email protected] to read a file from marczakio.sharepoint.com/sites/hr site.

But this account has also access to these SharePoint sites

• hr
• finance
• dev team

Now let’s assume, a month later a new developer joins our dev team. He is an external partner with email ID [email protected] and he’s got contributor access to our RG.

1. Tom creates a new logic app
2. In it creates a new SharePoint list files action, in which he
   1. Selects existing [email protected] connection
   2. Selects sites from dropdown and points to finance site
3. Creates a loop over all these files
4. Adds SharePoint download file action into his private drop box
5. Deletes the logic app

What happened? Well, now you allowed an external partner to exflitrate your finance data to his private resource. Without you even knowing. And in the logs it will looks like Adam did this. How do you even find this?!

Can you imagine the implications of this?

Now imagine scenarios like

• Sending emails or calendar invites as Adam because i’ve saved my connections
• Deleting an entire email box
• Emptying OneDrive folder
• Downloading company’s data from sharepoint
• Calling APIs on behalf of Adam, especially with Graph API
• etc. etc.

Terrible… never do it!!!!

Scenario #2 - Connection Fails

If you save connection credentials in Azure Logic App, typically this connection will wrok as long as this user is active (not left the org) and has permissions to access the source.

If user either leaves the org or looses the access, all connections will be invalidated.

But that’s good, no?

Generally speaking. Yes. It’s very good.

But what happens if a developer build 50 logic apps, rolled out to drop, and after 3 months left the company for another project. Immediately, one evening 50 production solutions will fail. That means 50 production incidents.

And the fix isn’t easy because it’s either

1. Authorize connections using different user, but that’s just doing the same issue over again
2. Create proper API connection using technical account
   1. Create a new entra account like [email protected]
   2. Add permissions to your source system to [email protected]
   3. Assign appropriate licenses
   4. Re-authorize connection with [email protected] instead of old personal account

But that obviously will take time to do for these 50 solutions, so make sure to get ahead of this before it becomes an issue.

Fix

Unfortunately there is no out of the box fix. While the fix is very easy to do, it’s based on the organization setup.

Why is it simple? Because it’s just a script which will

1. Pull all API connections from azure

   resources 
   | where type =~ 'Microsoft.Web/connections'
   

   With results like
2. Iterate over every connection and check
   1. If that user is an entra user. You should find property called authenticated user, you can use that to make graph query.
   2. If that user is an actual user, not a technical user - and this part varies, it’s why this isn’t out of the box

How to check if user is technical user or real user?

It really depends on your org. Sometimes organizations mark their users with some property to indicate that this user is a technical user, sometimes they have central list of technical users, sometimes these users are member or technical user groups, or in other way around, they are not member of all-users or all-employees groups. Either way, depending on your org, that logic will vary, and you will have to find this yourself.

Summary

As you can see, you can be in a big trouble