Required (to) high permissions makes using Graph provider infeasible for application teams

[henrybeen]

Scenario: I'm currently working a lot in what I call application teams. Teams that work on a few workloads within the organization, often C#.NET applications - hosted in Azure. App Services, Functions, a SQL DB, some Service Bus, and the like. They write their code in C#, their infrastructure in Bicep and their pipelines in YAML. Life was pretty good, except for having to manually request/provision resources in Entra ID, required by the application.

We were excited about support for MS Graph / Entra ID in Bicep as this would help us overcome this pain by allowing us to manage the following Entra ID resources we frequently require:

• Creating (and updating owned) app registrations, with app roles / api scopes
• Creating (and updating owned) groups, with members and owners
• Assigning App Roles to users, groups and/or enterprise applications

(I'd love to manage access packages to, but those are less urgent.)

All of these are now supported, both using a developer account from the local machine (great for dev) and the pipeline (Service Connection / Service Principal / App Registration.) The issue with the latter seems to be not really workable in larger organizations as it currently stands. No way that application teams will get their service principals scopes assigned like Group.ReadWrite.All and AppRoleAssignment.ReadWrite.All.

Am I overlooking something? Or is there any chance we will see permissions like Group.ReadWrite.OwnedBy, AppRoleAssignment.ReadWrite.OwnedBy, etc. (so similar to Application.ReadWrite.OwnedBy) in the (near) future?

[eringreenlee]

Hi Henry!

I'm a PM in the app platform team for Entra.

You're not overlooking anything, and you're right that those permissions are high privilege and give access to broad scopes. We are looking at splitting up permissions like Application.ReadWrite.All and although I cannot comment on timelines I believe we will definitely address some of your concerns here.

I have a couple of questions, specifically around app-role assignments:
When you think of AppRoleAssignment.ReadWrite.OwnedBy, who is owning what? Do they have to be an owner of the resource app (where the app role is defined) and the client app? If only the client app, should they need any other authorization to create app-role assignments?

[henrybeen]

Hey Erin! Great to hear that this is being looked into, I'm really curious what kind of solutions you are considering / looking into. I'm always open to looking at things together or doing a focus session.

W.r.t. your question:
In my understanding, AppRoleAssignment.ReadWrite.OwnedBy would give the holder the right to grant AppRoles on any App Registration they own, to any identity The reasoning is that you can give permissions out iff you own something. But you do not need to have any permission or access on the identity you grant those permissions to.

IMHO this makes sense if we look at teams and their applications as client/supplier relationships. If my team "supplies" access to an app or api to another team, I have no permissions on their identities, yet I should be able to give them access to my stuff.

And yes, this would imply the other person sharing their object id with me for providing access. If I need to be able to search an object id myself, I would require read permissions for the correct type of object.

HTH

[eringreenlee]

Our simple model for the split is splitting up actions (create, update, delete, add credentials, etc.) and splitting them across object (app registration, service principal). In some cases like update, we're looking to split updating even further by updating specific properties to mitigate risk (i.e. someone could update the display name, but maybe not the reply URIs). And to anyone reading this -- this is the plan, but don't take a dependency on my statement :-) things can still change.

Definitely interesting to hear your take on ARA.RW.OwnedBy. I see other customers that want the OwnedBy to apply to the client apps they own (i.e. only be able to grant permissions to those client apps). It sounds like there might be benefit in offering both ways. All that being said, we don't have any plans at the moment to offer granular app-role assignment permissions at this time.

[henrybeen]

@eringreenlee - it's been a while, is there any update on this?