Today while working with App Registration in Azure Active Directory I realized that, I need to simplify this points to get it understood by other team members. So sharing this article with you all with simple examples.
Since past few years I am working on Azure Automation using ARM Template and PowerShell Runbook. One important part of automation is Authentication. I will not explain in detail of Authentication and Authorization here but about permissions. Azure provides SPN (Service Principle Name) to perform some actions on Azure resources. Here you can find out more details about how to create new SPN / Azure App Registration. You may have already used Service principle somewhere. Today I will explain you more about Permissions of Service Principles and what are the difference in between it . Once you created any new App Registration in Azure important part is its Certificate and Secrets. You can use this App Registration to access azure resources from your any external application / code. But to prove identity of application you need to pass either Certificate or Client Secret, its same like Public Key or Application password. In below screen shot you can see that details.
Once you prove identity of Application and Logged In, next important part is Permissions. This configuration decides what all permission your App registration requires or has. This is good part to Limit every app registration for specific actions / scope. For example – You are creating new App Registration for reporting application which will only read Azure Resources details like Total VM in every Subscriptions / Tenants, Total Running VM’s, Total Disconnected (Shutdown) VM’s. This App Registration only require Read permission. But if you have other report Like creating list of Azure AD Users , Total Disabled Users, Enabled Users, Guest Users. In this case You App Registration will require Specific permission of Users.Read from active Directory permission as shown below.
Now important point is Type of Permission. In above screenshot you can see ‘Type’ column. There are two different types of permissions.
Delegated type permission actually require where Application have Logged In Users. In this type of permission Application can have list of Delegated permission in Portal (Configuration). For some permissions Administrator consent is required, it means though you Add new permission in list but it will not get activated / work till Administrator approve it. In some permission Administrator consent is not require.
Application type permission require where Application have without any Logged in Users. For example you have PowerShell script which run in background to do some activity.
Now important question is – What is the Difference in between Delegated and Application permission?
In Above paragraph we already discussed what is Delegated permission and what is Application permission. But still many time team members get confused with it. So I am trying to explain it in simple language.
- For ‘Delegated’ permission means Your App will have two types of privileges ,1st is Privileges granted to Application level while registering this app. 2nd type of privileges will be from Logged In User. So now in some cases Application can have higher permission than Logged in User. So what will happen in this case ?, if your Application have Delegated type of Permission then Your App can never have more privileges than Logged In User. There are different way to determine privileges of users.
For example, assume your app has been granted the User.ReadWrite.All delegated permission. This permission nominally grants your app permission to read and update the profile of every user in an organization. If the signed-in user is a global administrator, your app will be able to update the profile of every user in the organization. However, if the signed-in user isn’t in an administrator role, your app will be able to update only the profile of the signed-in user. It will not be able to update the profiles of other users in the organization because the user that it has permission to act on behalf of does not have those privileges.
- For ‘Application’ type permission , Your App’s permission will be higher permission for you. For example, an app that has the User.ReadWrite.All application permission can update the profile of every user in the organization.
I have tried to put this scenario in picture as below. Yellow color shows actual scope of App Registration in both cases.