Unanswered

How to correctly setup Service Principal permissions in AAD AND CDS for Azure DevOps PowerPlatform Build Tools?

(0) Share

Report

Posted on by Community Power Pla...

I have not been able to find clean documentation on how to setup a Service Principal to use with AzureDevops and PowerPlatform Build Tools.

This post does a nice job of showing how to setup ADO, but no info on the pre-req's of setting up the Service Principal.

Lets see if we can pull together all the steps in this post.

Here's what I have so far:

1. Create a new AppID in Azure Active Directory

- ISSUE HERE: Does this AppID need an email address?

2. Per this PowerShell script, add the following permissions:

"Microsoft Graph" "User.Read"

"PowerApps-Advisor" "Analysis.All"

"Common Data Service" "user_impersonation"

- ISSUE HERE TOO:

- "PowerApps-Advisor" "Analysis.All" does not appear to be a permission you can grant in Azure Portal to an AppID

- "Common Data Service" "user_impersonation" does not appear to be a permission you can grant in Azure Portal to an AppID

- The only one available says "DO NOT USE: DEPRECATED"

This is where I'm stuck when trying to setup an AppID. Any insights would be helpful!

Categories:

Power Apps Pro Dev & ISV

I have the same question (0)

All responses (8)

Answers (0)

cchannon 4,702 Moderator on at

Like (1)

Report

1. No, your app registration does not need an email address, but in order to impersonate a user (if that's what you're trying to do), that user does need an email address.

2. There are sometimes issues with setting up app registration permissions; MSFT has been quietly deprecating endpoints as they roll a lot of different services into Graph API and that can be a real thorn in your side, but I believe the ones you are speaking to are still there, exactly as referenced in the walkthrough you found.

From your app registration, select API Permissions and go to the "APIs My Organization Uses" tab. search from there for these permissions. If you don't see them there, you need to talk to your azure administrator about enabling them.

Worst case scenario, you create a new app registration in a trial azure account and add the permissions you are looking for (where you will have no environment constraints). Once added, you can select Manifest from the left nav of the Azure blade to see the app registration setup as a JSON document. In that document, you will find a section for API permissions, within which will be a section you can literally cut and paste into any app reg manifest anywhere. NOTE: you will not see the permission names you are expecting; everything in this JSON document is represented as GUIDs, but these GUIDs are Microsoft-global (they even work in GCC and GCC High) so you can use them in any subscription, anywhere.

For your reference, PowerApps Advisor is identified as c9299480-c13a-49db-a7ae-cdfe54fe0313 and Common Data Service is 82f77645-8a66-4745-bcdf-9706824f9ad0

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

Like (0)

Report

Also, I should point out that app registrations get "versioned" somehow when they are created, so if you create a brand new app registration and look at the possible API permissions, you might see different options than an app registration you created, say, 2 years ago.

BUT--and this is the really weird part--any app registration, regardless of the 'versioned' options that get presented to you, can still use any of the available permissions, even if you can't see them. So, the copy/paste manifest trick WILL WORK, even if for some reason you don't see the permission when you search. I have no idea why it works this way, and it can be a real nuisance, so you should be aware of this.

Was this reply helpful? Yes No
Community Power Pla... on at

Like (0)

Report

Thank you for the details, I will work at implementing these and report back.

One follow-on question: How do I know if I need "user impersonation" or not?

As far as I know, I'm trying to use a Service Principal as its own entity, not impersonate another user. Some details here would really help.

Thanks again.

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

Like (1)

Report

Well, you need user impersonation if you want to hit Dataverse with permissions specific to a given user. That is, if the app you are building lets users... say... update a Contact from a mobile app... then you will probably want user impersonation because it will let your app execute that update with the permission level of the user, not the app. This is important because Delegate permissions (like this one) take a least privileged approach. So, your app might have permission to delete Contacts, but if it is using Delegate authority and the user cannot delete contacts, then it cannot delete contacts. This takes a huge load off your authentication worries.

Was this reply helpful? Yes No
Community Power Pla... on at

Like (0)

Report

Hm. For this use case (using AzureDevOps and PowerPlatform Build Tools to move Solutions from Env to Github and From Github to Env), the Service Principal is not interacting with an application. There is no updating records, etc (unless Build Tools does something with CDS in the name of the Solution).

We are a canvas app-only shop so the only reason I need CDS permissions for the Service Principal is because when PowerApps packages canvas apps into Solutions it somehow ties them to CDS.

ADO can't access the Solution without proper CDS perms.

Ideally, I would not be touching CDS at all when placing canvas apps under Github version control using Azure DevOps, but thats perhaps another discussion altogether.

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

Like (1)

Report

OK, then it sounds like you can probably get by without impersonate. You can add an app identity directly to Dataverse as a special user type. To do this, go to users, then change the view to Application users, then hit add new. You'll get a special form here that will let you add your app reg as a "user" of type Application User. This will let your app hit CDS directly as itself, and without needing to use a (human) user's credentials.

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

Like (1)

Report

Also, a Canvas App shop that doesn't do dataverse? That's just wild. This platform has come so far, and I would love to pick your brain about that some day. I can't even imagine using the app platform without the data platform. Wild!

Was this reply helpful? Yes No
Community Power Pla... on at

Like (1)

Report

CDS/Dataverse is now unavoidable for Microsoft "background tasks", but no, we don't connect any applications directly to it.
- We've had users mistakenly click "Model-driven" instead of "Canvas" which auto-provisioned CDS
- We've had users select "Flow with approvals" which auto-provisioned CDS
- And we've private previewed some features that require it (GeoSpatial, AI Builder, etc.)
But otherwise, no direct usage. Prefer Sharepoint lists or on-prem db's/Azure SQL if we're going to go premium with anything.

Was this reply helpful? Yes No