I'm able to invite a user into a tenant. After the user confirms the invitation and is assigned a role in a subscription, he/she can view this subscription together with subscriptions from other tenants.
I can list user's subscription from all different tenants using az account list
Is it possible to do the same for an Azure application? Somehow invite it and grant it access to a subscription in different tenant? Or, in general, how an application can access resources in different tenant (without using Lighthouse)?
The security principal for an app is the ServicePrincipal object (much like the security principal for a user is the User object). If an app is configured to be a multi-tenant application, a service principal for that app can be created in any other tenant. Once that service principal has been created, it can be granted a role assignment.
Example using Azure CLI:
Log in to tenant A.
$ az login --tenant "{tenant-A-id-or-domain}"
In tenant A, configure the app registration (the Application object) to be multi-tenant. (Here we're creating a new one, but you can also update an existing one with az ad app update.)
$ az ad app create --display-name "App in Tenant A" \
--available-to-other-tenants true \
--query "appId"
"74dde9de-56e2-4750-a7cc-5da5f021b897"
Log in to tenant B.
$ az login --tenant "{tenant-B-id-or-domain}"
Create a service principal for the app (which was registered in tenant A) in tenant B. Note the value used for id is the appId of the app registration created in step 2.
$ az ad sp create --id "74dde9de-56e2-4750-a7cc-5da5f021b897" \
--query "{appId:appId,displayName:displayName}"
{
"appId": "4c3e3be1-b735-41b1-a842-f095b9a45849",
"displayName": "App in Tenant A"
}
At this point, you can grant the service principal access to something. For example, you can give it a role assignment to a resource in your Azure subscriptions.
You can now use the credentials configured on the app registration (i.e. the certificate or client secret), when authenticating into Tenant B, as the app.
Manually creating the service principal object as we've done here is just one approach. Another approach, particularly useful when the app has some sort of user-facing interface (e.g. a web app), is for a user in tenant B to sign in to the app and consent to it. After at least one user has consented to the app, the app's service principal object will be present in Tenant B and it can be granted a role assignment.
Related
What's a good way to set up an Azure app service, function, etc. with an identity that can access a Key Vault in another AAD tenant?
The only solution I can think of is via service principal, which would require a secret in a Key Vault in our own subscription, something like:
App in tenant A connects to Key Vault in tenant A via managed identity, gets secret
App in tenant A authenticates to AAD in tenant B via service principal / app registration (client ID + secret obtained above)
App in tenant A uses access token from tenant B to access resources in tenant B
What I was hoping for is there's something like AWS ability to assume roles across accounts -- where you can attach an identity in one tenant to be assigned to resources in another tenant.
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.
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.
We have Azure AD app configured to access to multiple organization resources (hidden with mask) (custom resources, like Contoso Service).
We would like to add one more resource to be part of this setup.
Can anyone please guide me or share link to documentation: how this custom permission should be configured to appear in the list in Azure AD configuration dashboard?
When you go through the experience to add a new required permission, the portal is looking at all the ServicePrincipal objects in your Azure AD tenant. For each ServicePrincipal object, it then looks at the AppRoles and OAuth2Permissions attributes, to see if the application represented by that ServicePrincipal object is publishing any application permissions or delegated permissions, respectively.
So, in order to see a resource in the list of available resources (i.e. APIs), you first need to ensure there exists a ServicePrincipal object for that resource, in your Azure AD tenant (i.e. in the Azure AD tenant where you are creating the client app's app registration).
A ServicePrincipal object for an app will usually be created in your Azure AD tenant when you (or someone else in your tenant) signs in to and consents to the permissions being requested by the app. If the ServicePrincipal object doesn't exist in your tenant, you can create it manually by referencing the resource app's AppId.
With Azure AD PowerShell:
New-AzureADServicePrincipal -AppId "{app-id}"
With Azure CLI:
az ad sp create --id "{app-id}"
Directly with Azure AD Graph (e.g. with Azure AD Graph Explorer):
POST https://graph.windows.net/myorganization/servicePrincipals
{ "appId": "{app-id}" }
Directly with Microsoft Graph (beta) (e.g. with Microsoft Graph Explorer):
POST https://graph.microsoft.com/beta/servicePrincipals
{ "appId": "{app-id}" }
Once the ServicePrincipal object has been created in your tenant, if it publishes AppRoles or OAuth2Permissions, you should see it listed in the app registration experience, when choosing which permission your app requires.
Note 1: Some of the behavior described differs for ServicePrincipal objects referrencing Microsoft apps and service.
Note 2: Once a ServicePrincipal object exists in your Azure AD tenant, it is possible for whoever owns the backing app registration to authenticate (as the app) in your tenant and obtain an access token. This in itself does not grant the app access to anything (at least not for Microsoft services), but it is easier at this point for a user to accidentally (or intentionally) grant that app access to your organization's resources (e.g. in Azure, for example, the app will show up in the list of users, groups or apps which can be granted access to a subscription's resources).
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.