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.
Related
I have a vendor application, possibly a SAAS application that want to access my key Vault in my Azure tenant, which is behind a firewall. Can anyone the suggest the best way to give the vendor access to my key vault? please drop a comment if you have done this before.
There are 2 ways, from which you can give the External vendor application access to your Azure key vault.
You can create a new service principal/app registration in your Azure AD tenant which will model the vendor application and provide that service principal access to key vault secrets and certificates, Via adding that service principal to the access policy with RBAC role. And then giving your vendor the Application client ID, Application secret, Tenant ID to use this app in their SAAS vendor app code for authentication to Key vault in your tenant. If the SAAS Vendor application already resides in your tenant, This method will work too.
I created a key vault resource on Azure :-
I created one single Tenant App to use for this tenant and then added that app to the access policy of Azure key vault.
Select your key vault from Azure Portal> Left pane> Access Policies> Add> Select the secret, key and certificate permissions as required > In Principal select your Single Tenant App> Next> Create
Singletenantapp is added to access policies with below permissions on Key vault:-
Now, You can provide this singletenantkeyvault application’s > tenant Id, application client ID, secret to the SAAS vendor application code as this Singletenantkeyvault application will model your real world SAAS vendor application.
Example-
{
"DNSNameKeyVault": "https://siliconkeyvault123.vault.azure.net/",
"AADAppRegistrationAppId": "7dad56d0-29d7-4d14-8dbe-4b9787895942",
"AADAppRegistrationAppSecret": "<app-secret>",
"SomeSecret": "DEV_VALUE"
}
Similar settings should be added to your SAAS vendor’s application’s appsettings.json folder depending on the framework that the SAAS vendor’s app runs on.
Note- Access policies can only be added to the Users and Applications in your directory only, you cannot add access policies to the external application that resides in other tenant/directory. You can either create a new application in your tenant or enable Multi-tenant application.
You can create a multi-tenant app shared between your External SAAS vendor’s tenant and your tenant, And assign the Key vault access policy to that Multi-tenant App. In this way you can use the existing SAAS vendor app in their tenant with your tenant to only give least privileged access to control Key vault.
I created a multi-tenant asp.net core app in my Default Directory tenant: -
MultiTenantAuth App is created successfully in our Azure AD Default Directory tenant
You can also create a multi-tenant app within Azure AD portal like below:-
Now, either you can authenticate with your SAS vendor application with your tenant and access key vault via running the code from VS studio or you can call this endpoint and replace the SAS vendor’s tenant ID with yours to get the SAAS vendor application from their tenant to your tenant and then provide the required access:-
In this example- Your MultiTenantDemo or MultiTenantAuth app is your SAAS vendor’s tenant Application which will be added in your or other tenant by either running the code or by calling the below endpoint.
In this example- I created MultiTenantDemo, MultiTenantAuth applications in my Default Directory and now I am adding them in my other directory SiliconSid.
https://login.microsoftonline.com/tenantid/adminconsent?client_id=clientid&state=12345&redirect_uri=http://localhost/myapp/permissions
I logged in with my another tenant’s admin user and accepted the consent for the app from my default directory to the new directory
After I called this endpoint, the Application is added in my another directory SILICONSID:-
Now, I’ll add this application in the Access policy of my key vault :-
Is inviting the user from your SAAS vendor’s tenant to your tenant and giving the user access to your key vault access policy if your saas vendor real world application uses username and password as authentication and not Service principal.
You can invite your SAAS vendor’s user like below:-
Invite the user and only provide the user access to your key vault:-
You can invite the SAAS vendor user via Email
An invitation link will be sent to the user’s email once the user accepts the invitation, He is redirected to your Azure Portal and is added in your Azure AD.
The SAAS vendor user can log in to Azure Portal and select your directory> and access the Key vault given you added that user to your access policy like below:-
You can again apply the policy of least privileged here and provide user only the access to the key vault and nothing else. You also need to provide the invited user access to your Subscription’s Key vault resource group with key vault role to only read key vault. This can be used if your SAAS vendor real world application uses Username and password as authentication in their Code and not service principal application.
The best way here is to either create a new application in your tenant or to create a multi-tenant application. Point 3) is not recommended and is not a best security practice.
Reference:
Azure Key Vault considerations for multitenancy - Azure Architecture Center | Microsoft Learn
Here's my components:
Tenant A:
Azure_WebApp_A
AAD multi tenant App registration
Keyvault_A
Tenant B:
Keyvault_B
Background: I'm able to access the secrets of Keyvault_A from Azure_WebApp_A using MSI authentication.
But when I try to add my multi tenant app registration(from Tenant A) to Keyvault_B's access policies, I don't even see the appId being detected there.
Question: How do I access secrets in the Keyvault_B from Azure_WebApp_A?
It is possible to add multi tenant app(from tenant A) to keyvault_B's access policy, if B tenant user has consent to use multi tenant app(tenant A), this app will exist under enterprise applications in tenant B.
How to grant consent to application?
When the user from A tenant sign in the application from tenant B, the application will then be registered under A tenant in enterprise applications.
Requesting individual user consent.
Requesting consent for an entire tenant
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.
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.