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?
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.
Related
From the page about Azure CLI Sign-in:
Service principals are accounts not tied to any particular user, which can have permissions on them assigned through pre-defined roles. Authenticating with a service principal is the best way to write secure scripts or programs, allowing you to apply both permissions restrictions and locally stored static credential information
It seems that a service principal is kind of a service account, a sort of identity which isn't tied to any specific person.
On the other hand, from here it seems that a service principal is an instantiation of the Application object in the domain of App registrations. This has something to do with registering an application so it can be authorized using OAuth 2.0 etc. etc.
So I can't understand the relation between these two concepts. Can someone help?
Service principal is sort of a service account.
It is the thing that permissions are assigned to.
For example, if you consent to an application reading your user profile on your behalf, that adds an OAuth 2 permission grant to the service principal.
Application permissions add an app role assignment to the service principal when granted.
When you make an app registration, a service principal is also created in that same Azure AD tenant.
Even though you add required permissions and consent to them through the app registration forms, the permissions are actually assigned to the service principal.
The app registration is only really a template.
Where this gets interesting is if you have a multi-tenant app (other Azure AD tenants' users can use your app).
In this case a service principal representing your app is also created in other Azure AD tenants when a user consents to the permissions your app requires.
Essentially you get an automatically generated service account in each tenant using your app.
This allows admins to decide which permissions to grant your app, which users can access the app etc.
We are having an Azure AD Protect API which is hosted on prem. We have a requirement to call this API from Logic App. We have currently created or registered a new client App in App Registration for this logic App and have provided the necessary permissions and have called API passing the Bearer Token.
My question, is there a way we can leverage Managed Identity for Logic App (either User Assigned or System Assigned) for calling the API?
Yes there is.
I wrote an article on the topic (though it is not specific to Logic Apps): https://joonasw.net/view/calling-your-apis-with-aad-msi-using-app-permissions.
You will need to create an appRoleAssignment that gives an application permission to your managed identity service principal.
To do this, we must use PowerShell or Microsoft Graph API.
With Azure AD PowerShell, we can do this:
Connect-AzureAD
New-AzureADServiceAppRoleAssignment -ObjectId $miSpId -Id $appRoleId -PrincipalId $miSpId -ResourceId $targetApiSpId
There we have 3 arguments you need to find:
miSpId: The objectId of the Managed Identity (easy, we can find this from the Identity blade in the Logic App)
appRoleId: The id of the appRole defined on your API's manifest (this should be easy to find as well, it's in your API's manifest)
If you haven't defined an appRole (app permission) on your API, you will need to do that first (https://joonasw.net/view/defining-permissions-and-roles-in-aad)
targetApiSpId: The objectId of the target API service principal (this one you can get by going to Enterprise Applications and finding your API there)
Azure Active Directory has applications and service principals.
https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
Both objects seem to have credentials.
New-AzureADApplicationPasswordCredential
New-AzureADServicePrincipalPasswordCredential
If both a service principal and an application object have credential(for example password), which one is used for authentication? If service principal's credential is used, what's the purpose of application object's credential? Is it for fallback when a service princial doesn't have credential?
I read this question, but I cannot understand the difference between application's password and service principal's one.
Authentication difference between using AAD app key and Service Principal Password
Both of the two passwords can be used to authenticate, but the password of the service principal just can be used to authenticate in the tenant which it located in, the password of the application can be used to authenticate in all the tenants where its service principal instances located.
The service principal is just a instance of the application in a specific tenant, when a tenant consent an application, azure will install it as an Enterprise Application(i.e. serivice principal) in the tenant. There can be several service principals in different tenants, but the application is the only.
I want to understand the difference between the SPN & UPN in Azure AD Context. My understanding is there are three way to establish identity in Azure AD
Users Key in their username and Password to establish Identity
An application using ClientId and Secret Key to establish Identity
An application using ClientId and Certificate to establish Identity
Is User/Password is called UPN & rest two are called SPN? Also is there any other way to establish identity?
In Azure AD, UPN is the User Principal Name. It is always in the format which looks like an email address. Essentially it has three parts. User account name, the separator (i.e. # symbol) and UPN suffix or domain name. Its primary purpose is to use during the authentication and represents user identity.
SPN is the Service Principal Name. The service principal object defines the policy and permissions for an application, providing the basis for a security principal to represent the application when accessing resources at run-time. App identity (service principal) is preferable to running the app under your own credentials (user identity) because:
You can assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.
You do not have to change the app's credentials if your responsibilities change.
You can use a certificate to automate authentication when executing an unattended script.
You could create service principal with password or certificate as you shown.
Please click here for more about application and service principal objects in Azure Active Directory, and click here for how to use portal to create an Azure Active Directory application and service principal that can access resources. You could choose other ways (e.g. PowerShell/CLI) on the left navigation panel.
Is it possible to assign an application (as an Application or Service Principal) to a group programatically, via the graph client or API? (Including the app user credentials needed to allow access of the members of the group to the app)
I searched everywhere and couldn't find documentation for it.
Thanks
No, 'Applications' in Azure AD are used to segment authorization and settings within Azure AD. It creates a trust between Azure AD and your application. The Application is not a User.
Users are Azure AD entities that have identity and can be authorized to access resources (like an Application). Users can be added to groups. See the below link for the Azure AD graph API documentation:
https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/groups-operations#AddGroupMembers
And the documentation on what a user entity looks like:
https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/entity-and-complex-type-reference#UserEntity
Thanks for the answer emseetea, but we do have a little more than that.
Back to the original question - can you programmatically "assign a group to an application". The answer is yes, using appRoleAssignments on the service principal. The service principal represents an application instance, that typically gets provisioned as part of a consent grant. On this tenant specific app instance (service principal) you can attach tenant specific permissions and policy. Permissions get created as part of consent, but you can also programmatically assign an application role (defined by the application) to a user or group. If no application role is assigned, then you can make a "default" assignment. You can find a little more on this topic here http://blogs.msdn.com/b/aadgraphteam/archive/2014/12/12/announcing-the-new-version-of-graph-api-api-version-1-5.aspx which describes a little about this with some sample REST API calls.
This same operation is also possible through the client library. You can take a look at https://github.com/Azure-Samples/active-directory-dotnet-graphapi-console. Look at the section titled "#region Assign Direct Permission". This shows how to assign an app role to a user. You can do the same thing on a group too. If your app doesn't specify any app roles, set the appRoleAssignment.Id to a zero GUID.
Hope this helps,