role assignment service principal

Azure Service Principals In Depth

An application’s service principal holding permission keys to the power of Azure.

What is a Service Principal?

From the official documentation :

An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level. For security reasons, it’s always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.

In my own words, a service principal is an identity that represents an application for either (1) authentication and authorization with Azure resources or (2) authentication with other services that integrate with Azure AD.

Service principals are a specific type of security principal , which are entities that can be authenticated with Azure.

It is an identity

A service principal is essentially an identity which represents a non-human users, analogous to email for human users.

It is for applications, hosted services, and automated tools

A service principal is meant for use by non-human users (applications, microservices, functions, scripts, etc.). It should not be used by human users to authenticate and represent themselves.

It only has access to Azure roles assigned to it

A service principal can be assigned suitable Azure roles at different hierarchical levels, e.g. subscription, management group, resource. This allows service principals to abide by the principle of least privilege.

Pedantically, there are actually a few types of service principals :

• Application
• Managed identity

This rest of the blog post only concerns with the Application service principal type. Generally, when the “service principal” term is used, it usually refers to the Application service principal type.

Create a Service Principal

Just as we need to authenticate ourselves with an SMTP server to access our email, service principals need to authenticate with Azure to gain authorization to specific roles and permissions in Azure.

There are two ways to do this:

Password-based authentication

Using this mode, a random password is created by Azure for you. Optionally, you may specify a resource name for the service principal. You can set the role assignment at time of creation, or do it later.

The service principal password is only shown to you at this time. Store it somewhere safe. If you lose it, you can reset its credentials like follows:

Certificate-based authentication

Using this mode, you will authenticate with Azure using a private key certificate.

The simplest way to get started is to get Azure to generate a self-signed certificate for you:

You can also generate your own private key certificate (PEM, CER, or DER) and provide it to Azure to create the service principal. The invoker of this service principal will also need the private key as proof of authentication to Azure.

Or with a path to the certificate:

You can also upload or generate a certificate in Azure Key Vault and provide it to the service principal via the --cert and --keyvault parameter:

An example console output for service principal creation is as follows:

Here is a concrete example output when creating a password-based service principal:

Do note on the APP_ID value, which we will need for role assignment next. This value is also commonly known as the CLIENT_ID , with the corresponding password known as the CLIENT_SECRET .

Manage Service Principal Roles

Creating a service principal by itself doesn’t give you any authorization to do anything in Azure. You need to first assign it some roles.

Assign a role:

Delete a role:

To view the currently assigned roles:

Signing in with a Service Principal

Essentially, you will need either a password or a private key to authenticate with a service principal.

You may log in using the service principal to try it out:

To log in using a certificate (private key):

Subsequently you (or the CLI script you are running) are then able to create and manage resources as this service principal.

Usually though, instead of using the CLI, you will want to authenticate the service principal using the Azure SDK for your application’s programming language.

For example, using the Azure SDK for Java, you can do the same thing as above in Java code:

Or if your secret is stored in Azure Key Vault:

But maybe YAGNI? (You Ain’t Gonna Need It)

If your application is hosted within say, an Azure VM, you should actually not use a service principal (application type) but instead try to use the following secretless methods (out of scope of this blog post):

• Default Azure credential
• Managed Identity credential

Using the above two methods, the application does not need to manage and secure the password or certificate, which is definitely a boost for security. So first consider if you can do away with service principals altogether.

For applications hosted in Azure Kubernetes Service (AKS), then you’ll probably need a service principal to represent the pods or containers, because there is no Azure identity representation at the pod or container level.

That’s it for this blog post. Happy to hear your thoughts via [email protected] .

Check out some of my books and courses!

Creating a Service Principal with the Azure CLI

So far in my tutorial series on the Azure CLI , I’ve been assuming that you are logging in directly with the az login command. This will direct you to visit a webpage, enter a code and log in to Azure yourself. Now that’s fine if you’re running commands or scripts directly from a command prompt yourself, but what if you want to automate a task? Say you want to set up a scheduled task to shut down a Virtual Machine at midnight, or want to automate a resource management task from an Azure Function.

What you need is a service principal . A service principal is an identity your application can use to log in and access Azure resources. In this post I’ll show you how we can create a service principal from the CLI which can be used not only to run CLI commands from an automated process, but to use the Azure SDK for your programming language of choice (e.g. C#, Python, Java, Ruby, Node.js etc).

Create an Azure Active Directory application

Before you create a service principal, you need to create an “application” in Azure Active Directory. You can think of this as an identity for the application that needs access to your Azure resources.

You can create an AD Application with the Azure CLI, but do make sure you’ve selected the right subscription with az account set first, so that the application ends up in the correct Active Directory.

Here we select the subscription, and then use az ad app create to create an application. The only parameter that really matters is --display-name , but we are required to provide a --homepage and --identifier-uris parameter, so we just make up suitable values for them (they don’t have to be reachable URIs).

Now we need the app id from the output of az ad app create . You can get it again by searching for the AD app with the display name you chose like this:

Create the Service Principal

Now that we have an AD application, we can create our service principal with az ad sp create-for-rbac (RBAC stands for role based access control).

We need to supply an application id and password, so we could create it like this:

This would create a service principal that has contributor access to the currently selected subscription.

However, its a good idea to restrict permission to only allow access to the minimal set of resources that the target application needs to use. So you can set the --role to reader instead of contributor if you only need read access. Or you can use the --scope argument to limit the scope to only allow management of a single resource group.

So here’s how we could create a service principal that has contributor level access to just a single resource group (the resource group should already exist).

Get the Service Principal App Id

Once you've created your service principal, you will need to get its app id (not to be confused with the app id of the AD application). You can get this from the output of the az ad sp create-for-rbac command, or you can get hold of it again by searching for service principals whose display name is the app id of the AD application like this:

Configuring Access

If you need to do anything more complex with the roles and scopes for your service principal, then the az role assignment group of commands will help you do this. If you created your service principal without specifying a role and scope, here’s how to delete the existing one, and add a new one:

Testing it Out

So we’ve created a service principal, but does it work? Well, before we can test it out, we need one more bit of information: we need the tenant id associated with our account. We can get that like this:

And now let’s log out with az logout , and then log back in using our service principal, by using az login --service-principal and passing in the app id of the service principal, the password we chose, and the tenant id:

The proof that this all worked is in what we can do. If I ask to list all resource groups, I should just see the one I’m allowed access to:

And if I try to create a new resource group, that will fail because I don’t have permission

However, if I want to create a new VM inside the one resource group I have been granted contributor access to, that will be allowed:

Using the Service Principal from C#

The service principal can be used for more than just logging into the Azure CLI. It can be used alongside the Azure SDK for .NET (or indeed with the SDK for your favourite language).

For example, here’s the code for a simple Azure Function that runs on a schedule at midnight every night. It uses the service principal login details (read from app settings), then attempts to find a Virtual Machine with a specific name in a specific resource group (obviously this should be the resource group we granted contributor access to). And then if the machine is not in a stopped deallocated state, it attempts to put it into that state in order to save money.

Learning More

Hopefully that’s enough to get you started creating and using your own service principals. For more details on different ways to create a service principal, check out this tutorial on the official docs site.

For previous entries in my Azure CLI tutorial series:

• Deploying ARM Templates with the Azure CLI
• Backup and Restore a SQL Database with the Azure CLI
• Connect a Web App to a SQL Database with the Azure CLI
• Manage Storage Queues with the Azure CLI
• Manage Blob Storage with the Azure CLI
• Create and Configure a VM with the Azure CLI
• Automate away your Azure Portal usage with the Azure CLI
• Using Queries with the Azure CLI
• Introducing the Azure CLI

Great article. Well done.

Excellent article .. thx for sharing

Manage Azure Role Assignments Like a Pro with PowerShell

Today’s blog post is a little bit different. I have a couple of examples of how you can use PowerShell snippets and simple commandlets to get or set role assignmnets in your Azure Subscriptions.

PowerShell examples for managing Azure Role assignments

List all role assignments in a subscription, get all role assignments for a specific resource group, get all role assignments for a specific user, add a role assignment to a user, remove a role assignment for a user, remove all role assignments for a specific user, list all built-in roles, list all custom roles, create a custom role, update a custom role, delete a custom role, list all users or groups assigned to a specific role, list all permissions granted by a specific role, list all resource groups that a user has access to, create a role assignment for a service principal, powershell script to manage azure role assignments.

And now there is a script that combines some of these examples into one usable function:

I hope this was useful. Let me know if you liked the format of this blog and if you want me to include more of these examples.

Vukasin Terzic

Recent Update

• Writing your first Azure Terraform Configuration
• Transition from ARM Templates to Terraform with AI
• Getting started with Terraform for Azure
• Terraform Configuration Essentials: File Types, State Management, and Provider Selection
• Dynamically Managing Azure NSG Rules with PowerShell

Trending Tags

Retrieve azure resource group cost with powershell api.

The Future Of Azure Governance: Trends and Predictions

Further Reading

In my previous blog posts, I wrote about how simple PowerShell scripts can help speed up daily tasks for Azure administrators, and how you can convert them to your own API. One of these tasks is...

Azure Cost Optimization: 30 Ways to Save Money and Increase Efficiency

As organizations continue to migrate their applications and workloads to the cloud, managing and controlling cloud costs has become an increasingly critical issue. While Azure provides a robust s...

Custom PowerShell API for Azure Naming Policy

To continue our PowerShell API series, we have another example of a highly useful API that you can integrate into your environment. Choosing names for Azure resources can be a challenging task. ...

All about Microsoft 365

More on service principal permissions in Exchange Online

Few days back I briefly covered the advancements in Exchange Online’s support for service principal objects. In the context of said article, we only talked about Full access permissions, but since service principals are now supported objects in Exchange Online, the question remains which other functionalities support them. So let’s take a deeper look.

First, let’s briefly talk again about creating and managing service principal objects in Exchange Online. Since no process exists to synchronize Azure AD service principal objects to ExODS, you’ll need to create a matching representation of the SP object yourself. In order to do that, you can use the New-ServicePrincipal cmdlet, which by default is available to users assigned the Role Management role. You will need to specify the client ID (application ID) value, via the – AppId parameter, as well as the object ID, via the – ServiceId parameter. Here’s an example:

If you do not know the values for said parameters, you can obtain them from either the Azure AD blade > App registrations > Overview page, or via PowerShell ( Get-MsolServicePrincipal , Get-AzureADServicePrincipal or Get-MgServicePrincipal cmdlet, depending on which module you prefer). Do note that the New-ServicePrincipal does NOT validate the values, so make sure you double- and triple-check them.

To list the current set of service principal objects recognized by ExODS, use the Get-ServicePrincipal cmdlet. Interestingly enough, the RecipientType value for such objects is User , whereas the RecipientTypeDetails is ServicePrinciple (note the spelling!). You cannot however use the Get-User cmdlet to list them, and Get-Recipient with the corresponding filter doesn’t work either. The Set-ServicePrincipal cmdlet can be used to update an existing object, although the only property you can change is the DisplayName . Lastly, to delete an existing service principal object, use the Remove-ServicePrincipal cmdlet.

Now that we covered the basics of managing service principals in Exchange Online, let’s turn into delegating permissions. We already covered the Full access permission in the previous article, but as a refresher you can grant permission via the Add-MailboxPermission cmdlet, by specifying the service principal identifier (display name, appId and serviceId will all work) as value for the -User parameter:

You can list, update and remove Full access permissions via the standard cmdlets. The EAC UI will display existing permission entries for service principal objects, but not allow you do add new ones. Interestingly, the new EAC will show you the GUID of the service principal, whereas the classic one returns its Display name. Another interesting thing is that the REST-based cmdlets cannot seem to resolve service principal objects by their DisplayName values, so you have to specify GUIDs instead:

As with Full access permissions, the EAC UI will show you any existing entries, but does not allow you to grant the permissions, so you have to stick to PowerShell. Even PowerShell however does not support granting Send on Behalf of or folder-level permissions, at least currently. So it seems currently only Full Access/Send As permissions are supported. Granting permissions aside, just how one would leverage them is not clear either, the only example of using Full access permissions granted to service principal can be found in this EHLO blog and the script linked therein.

We still have one last set of permissions to cover though, namely granting administrative permissions to the service principal object by assigning RBAC roles, or adding it as a member of a Role Group. Both operations seem to be possible (via PowerShell), but there are some very important caveats to consider. In a nutshell, only specific roles are supported, as we will see below.

For now, let’s see what happens if we try to create a direct role assignment to a service principal object. We can select a random role, such as say “Federated Sharing”, and try to assign it to the SP via the New-ManagementRoleAssignment cmdlet. Doing so will result in the following error message:

So while the process fails, the error message itself gives us a clue. Apparently, few months back Microsoft introduced a new type of role, a Service principal role, and a corresponding parameter was added to all existing roles, namely IsServicePrincipalRole . This is illustrated by the following cmdlet

I’ve truncated the output above, but since all the SP roles (the ones with IsServicePrincipalRole = True) have names starting with “Application”, we now have the full list of such roles. Interestingly, most of the roles seem to correspond to specific Graph permissions, such as Mail.Read. Another interesting observation is that a new Type property has been introduced for management role entries, with the corresponding parameter for the Get-ManagementRoleEntry cmdlet. In other words, you can also list all “ApplicationPermission” management role entries via the Get-ManagementRoleEntry cmdlet, as follows:

But I digress. Back to assigning admin permissions to service principal objects now. As we established above, direct role assignment is only possible for specific roles, such as the “Application Mail.ReadBasic” one:

For all non-SP roles, direct assignment will result in an error, as we already saw above. Turns out however that you can assign service principal objects as a member of a role group that contains non-SP roles. While the end result is disappointing, it’s still interesting to know that this is possible. Here’s how to assign a role group to a service principal object (as usual we have to use PowerShell):

where “test” is the identity of an already existing custom Role Group in my tenant. Usually, one can use the – GetEffectiveUsers switch of the Get-ManagementRoleAssignment cmdlet to “expand” role group based assignments and get a list of the corresponding user objects. This however does not seem to work with service principal objects, so you have to employ workarounds. Here are some examples:

Unfortunately, while the above examples show that it is indeed possible to add service principal objects as members of Role Groups, the permissions corresponding to any of the roles contained within said assignments are not available for use with the service principal login. One would hope that this method would finally allow us to use Role Groups for CBA scenarios for ExO PowerShell. However, this will result in an error as shown below:

The role assigned to application xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx isn’t supported in this scenario. Please check online documentation for assigning correct Directory Roles to Azure AD Application for EXO App-Only Authentication.

So in summary, Exchange Online now supports service principal objects. Those are objects of RecipientType User , with RecipientTypeDetails value set to ServicePrinciple . A new set of cmdlets has been introduced to manage them, namely *-ServicePrincipal . Service principal objects can be used to delegate Full Access and Send As permissions in app-only authentication scenarios, such as OAuth authentication via POP/IMAP. Folder level, delegate and send on behalf of permissions are not supported.

When it comes to admin permissions, service principal objects can of course be granted Azure AD admin roles. Within ExODS however, only a subset of the management roles are available for direct assignment – those designated with IsServicePrincipalRole value of True . And while you can add service principal objects as members of a group, including Role Groups, do not expect the corresponding cmdlets and functions to become available to the service principal. Well, perhaps any of the “Application *” ones would work 🙂

Before closing, it’s worth mentioning that you can use yet another “hack” to look at the full properties of the service principal object. Whereas the Get-ServicePrincipal cmdlet exposes only a handful of properties via the Deserialized.Microsoft.Exchange.Data.Directory.Management.ServicePrincipal object, you can get a lot more by fetching the Deserialized.Microsoft.Exchange.Data.Directory.Management.ReducedRecipient object as follows.

Few things to note here. The ExternalDirectoryObjectId value will match the clientID/appID of the parent application. No email addresses will be present and no Alias either, so while HiddenFromAddressListsEnabled is set to False, don’t expect to see service principal objects in the GAL. Interestingly, IsValidSecurityPrincipal is set to False, which is strange for an object that can be used for delegating permissions. But hey, it’s still in the early days I suppose.

I’ll circle back to this article at a later point to update it with new information as it becomes available. In any case, some more details on granting permissions to service principal objects and the corresponding use cases can be found in the official documentation .

13 thoughts on “ More on service principal permissions in Exchange Online ”

• Pingback: ExO RBAC improvements #1: Limiting application access | Blog

Adding Service Pricipals to (custom) RBAC roles should work, as documented in the Exchange Blog post. https://techcommunity.microsoft.com/t5/exchange-team-blog/notes-from-the-field-using-app-only-authentication-with/ba-p/3690083

However, when following the steps, I also receive the error you got: The role assigned to application xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx isn’t supported in this scenario. Please check online documentation for assigning correct Directory Roles to Azure AD Application for EXO App-Only Authentication.

Did you manage to resolve that?

Seems to work fine here now, I can connect with just a Role Group assigned to the SP object, and the set of cmdlets I’m able to run is quite restricted. I’ll do a proper writeup in the coming days.

Which EXO module version are you using for this?

The New-ServicePrincipal cmdlet doesn’t appear to exist in version 3.0.1-Preview1 or 3.0.0.

Check your permissions 🙂

Your article helped me a lot, but some questions confused me. When I try to assign roles(actually the role is Application EWS.AccessAsApp) to the application(I use New-ManagementRoleAssignment mentioned in the article), I use this application through EWS to get mail. However, the returned result is 403 server forbidden. It seems that the application does not have permission. What can I do to use these permissions?

You don’t have to use these cmdlets for anything EWS related. Instead, make sure your Azure AD app registration has the necessary permissions, be it delegate or application ones, and that consent is granted. Here’s an article with more details: https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth

Thanks for your reply! I have tried the method you mentioned before. What really confuses me is what use are these roles(like Application Mail.ReadBasic) that can only be assigned to applications in Exchange? Or is it still unavailable?

Those roles are specific to Graph API operations.

After I use New-ManagementRoleAssignment to assign roles(Application Mail.ReadBasic) for the Azure AD application, the application still cannot use the graph api. Do you mean that these roles are internal and used in the graph api to access exchange, but cannot be used by ordinary users?

You cannot do this purely on Exchange side, the AAD application still needs to have the corresponding permission added and consented to.

Amazing article! thank you so much for taking the time to write this up, I’m sure it helps a lot of people.

While reading this I had an idea and I’m wondering if you tried it. One of the application permissions in Exchange Online is the “ApplicationImpersonation” one. Do you think this can be used to grant a user the necessary permissions and then grant the SP impersonation rights to that user? while looking at this I could only find documentation for impersonation in c# ( https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-add-appointments-by-using-exchange-impersonation ). But doing this in Powershell might be amazing.

What do you think?

Sure, EWS impersonation can be restricted to specific mailboxes only. Depending on the type of permissions you are using, you can either:

1) Application permissions model: Configure an Application access policy: https://practical365.com/new-application-access-policies-extend-support-for-more-scenarios/ 2) Delegate permissions model: Assign the user under whose identity your app is running to the ApplicationImpersonation role, with a custom management scope restricted to just the mailboxes you want him to be able to access

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Azure Resource Graph

Find service principals with privileged roles.

• by: Seif Bassem
• May 01, 2023

As more and more organizations adopt cloud computing, the use of Azure Active Directory (Azure AD) and service principals has become increasingly prevalent. Service principals are Azure AD identities that are used to authenticate and authorize applications and services to access Azure resources. While service principals can be a powerful tool for managing access to Azure resources, they also come with significant risks, particularly when they are granted privileged roles and are not properly tracked. In this article, we will explore how to use Azure Resource Graph to find those service principals, and discuss best practices for managing these identities to minimize the risk of security breaches.

Azure Resource Graph is a powerful tool for managing complex Azure environments. With Resource Graph, you can easily query and inventory your Azure resources using a simple and intuitive syntax. Whether you’re managing a small deployment or a large-scale enterprise environment, Resource Graph can help you gain better visibility into your resources and streamline your management tasks.

What we want to do is look for service principals that have privileged roles so we can review their access and take an action based on that. We would like to list all the role assignments on a specific scope, get the role definitions on those assignments and look at their permissions.

Getting all service principals with assigned builtin roles

Azure Resource Graph has a preview table that we can query for role assignments and definitions called authorizationresources

If we query this table and filter for roleassignments , we can see we have the following interesting fields:

• principalType where we can filter by service principal or user
• principalId which is the Id of the service principal
• roleDefinitionId which is the unique Id of the role
• createdBy which can be used to filter out the builtin service principals

We can now create a query to list all role assignments for service principals that are not builtin

We will have to do a join to get the builtin role definitions on the assignments from the previous step to list all service principals with builtin roles

Getting all service principals with assigned builtin roles and write permissions

To take this up a notch, we can also use this query to look for assignments that have specific permissions. Say you want to look for service principals that can do some damage having role assignments with write and delete permissions only.

If we look closely to the roledefinition properties, we can see an array containing the permissions assigned to this role which we can leverage in our query

We will use the query we built in step one and add an mv-expand operator which expands an array so we can filter out its content to only show permissions with write and delete

Best practices managing service principals

Managing service principals effectively requires a combination of proactive monitoring, regular auditing, and careful role assignment. Here are some best practices for tracking and managing service principals on Azure:

• Limit the number of service principals: The more service principals you have, the harder it is to track and manage them. Limiting the number of service principals and ensuring that each one has a clear business justification can help reduce the risk of untracked identities.
• Assign roles carefully: Only grant service principals the minimum privileges they need to perform their intended function. Avoid assigning overly broad or generic roles, such as “Owner” or “Contributor,” to service principals unless absolutely necessary.
• Use Azure AD Privileged Identity Management (PIM): PIM provides a way to manage and monitor access to Azure resources by requiring users to request elevated permissions for a limited time. By using PIM, you can ensure that service principals with privileged roles are only active when they are needed and reduce the risk of unauthorized access.
• Regularly audit service principals: Regularly review service principals to ensure that they are still necessary and that their assigned roles are appropriate. Remove any service principals that are no longer needed or have overly broad permissions.
• Monitor service principal activity: Use Azure AD audit logs to monitor service principal activity and detect any unusual or suspicious behavior. By tracking service principal activity, you can quickly identify and respond to security threats.
• Implement Conditional Access for workload identities: Implement Conditional Access policies for controlling access to Azure resources by service principals.

Seif Bassem

Azure policy gradual rollout with resource selectors.

Azure Naming Tool

Am I being attacked?!

• Azure unboxing 6
• Book reviews 3
• Contributions 12
• App services
• Azure advisor
• Azure app services
• Azure chaos studio
• Azure developer CLI
• Azure functions
• Azure migrate
• Azure monitor
• Azure policy
• Azure resource graph
• Azure static webapps
• Azure virtual desktop
• Azure workbooks
• Book review
• Chaos studio
• Cloud adoption framework
• Cost management
• Cost optimization
• Defender for cloud
• Deploymentscripts
• Endpoint analytics
• Infrastructure as code
• Microsoft 365
• Microsoft defender for cloud
• Microsoft endpoint manager
• Microsoft sentinel
• Productivity
• Reliability
• Troubleshooting

You May Also Like

• Azure Policy

Remember in the old days when using group policy on-premises, you had …

• Feb 04, 2023
• Cloud Adoption Framework

While working with lots of customers helping them to increase the …

• Aug 06, 2022
• Microsoft Sentinel

Recently there has been some new tools introduced in Microsoft …

• Jul 27, 2022

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Grant an appRoleAssignment for a service principal

• 10 contributors

Namespace: microsoft.graph

Assign an app role for a resource service principal, to a user, group, or client service principal.

App roles that are assigned to service principals are also known as application permissions . Application permissions can be granted directly with app role assignments, or through a consent experience .

To grant an app role assignment, you need three identifiers:

• principalId : The id of the user , group or client servicePrincipal to which you are assigning the app role.
• resourceId : The id of the resource servicePrincipal which has defined the app role.
• appRoleId : The id of the appRole (defined on the resource service principal) to assign to a user, group, or service principal.

This API is available in the following national cloud deployments .

Permissions

One of the following permissions is required to call this API. To learn more, including how to choose permissions, see Permissions .

For delegated scenarios, the calling user needs at least one of the following Microsoft Entra roles .

• Directory Synchronization Accounts
• Directory Writer
• Hybrid Identity Administrator
• Identity Governance Administrator
• Privileged Role Administrator
• User Administrator
• Application Administrator
• Cloud Application Administrator

HTTP request

You can address the service principal using either its id or appId . id and appId are referred to as the Object ID and Application (Client) ID , respectively, in app registrations in the Microsoft Entra admin center.

Request headers

Request body.

In the request body, supply a JSON representation of an appRoleAssignment object.

If successful, this method returns a 201 Created response code and an appRoleAssignment object in the response body.

The following example shows a request.

For details about how to add the SDK to your project and create an authProvider instance, see the SDK documentation .

In this example, {id} and {resourceId-value} would both be the id of the resource service principal, and {principalId} would be the id of the assigned user, group, or client service principal.

The following example shows the response.

Note: The response object shown here might be shortened for readability.

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources