To run applications in Azure, I need to create an Application in Azure AD and a corresponding Service Principal. Then my application authenticates against this App/Principal pair. To authenticate, I can create an application key in the App registration, or I can create a password in the Service Principal (among other options). What's the difference from a practial standpoint?
For example, this code runs exactly the same (from the outside) whether the $key is the App's key or the Service Principal's password:
$key = ConvertTo-SecureString $authKeyOrPassword -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($appID, $key)
Add-AzureRmAccount -Credential $cred -TenantId $tenantID -ServicePrincipal
When should I authenticate against the App, and when should I use the Service Principal?
Relationship between application objects and service principals. The application object is the global representation of your application for use across all tenants, and the service principal is the local representation for use in a specific tenant.
Service principal authentication involves creating an App Registration in Azure Active Directory. First, you generate a client secret, and then you grant your service principal role access to your machine learning workspace. Then, you use the ServicePrincipalAuthentication object to manage your authentication flow.
Think of an App Registration as a way of reserving your app + URL inside of Azure Active Directory (Azure AD or AAD). An App Registration provides a way for your app to communicate with AAD: you'll be able to use reply URLs and enable AAD services on the app. Super big bonus!
First, let me explain why it has both Applications and service principals in Azure AD. Here is the explanation from Mordent Authentication with Azure AD for Web App by Vittorio Bertocci.
Azure AD defines a new entity, the Application, which is meant to describe an application as an abstract entity: a template, if you will. As a developer, you work with Applications. At deployment time a given Application object can be used as a blueprint to create a ServicePrincipal representing a concrete instance of an application in a directory. It’s that ServicePrincipal that is used to define what the app can actually do in that specific target directory, who can use it, what resources it has access to, and so on.
Bear with me just a little longer, the abstract part is almost over. The main way through which Azure AD creates a ServicePrincipal from an Application is consent. Here’s a simplified description of the flow: Say that you create an Application object in directory A, supplying all the protocol coordinates we’ve discussed so far in earlier chapters. Say that a user from tenant B navigates to the app’s pages and triggers an authentication flow. Azure AD authenticates the user from B against its home directory, B. In so doing, it sees that there is no ServicePrincipal for the app in B; hence, it prompts the user about whether he or she wants to consent for that app to have access to the directory B (you’ll see later in what capacity). If the user grants consent, Azure AD uses the Application object in A as a blueprint for creating a ServicePrincipal in B. Along with that, B records that the current user consented to the use of this application (expect lots of details on this later on). Once that’s done, the user receives a token for accessing the app.
If you want to know the difference between Azure AD App key and service principle Password, you'd better know the relationship of Application and service principal. I will copy&paste here some extracts from this page of the documentation
When you register an Azure AD application in the Azure portal, two objects are created in your Azure AD tenant: an application object, and a service principal object.
Consider the application object as the global representation of your application for use across all tenants, and the service principal as the local representation for use in a specific tenant. The application object serves as the template from which common and default properties are derived for use in creating corresponding service principal objects.
An application object therefore has a 1:1 relationship with the software application, and a 1:many relationships with its corresponding service principal object(s).A service principal must be created in each tenant where the application is used, enabling it to establish an identity for sign-in and/or access to resources being secured by the tenant.
Example diagram
Summary
Now, we can know the difference between Azure AD App key and service principle password. They belong to different objects. The password to be associated with the service principal. This is just for the application tenant to login azure. However, you can provide the App key value with the application ID to log in as the application with all tenants.
To see more details about Application and service principal objects in Azure Active Directory , you can refer to this document.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With