Say I have an App1 in Tenant1. This App1 has contributor access to a subscription SUB_1 in the same Tenant1. There is a App1_ClientId and App1_ClientSecret associated with the App1.
Now, I can use this id and secret to login to that tenant and do stuff with the SUB_1 using the URL:
https://login.microsoftonline.com/Tenant1_ID/oauth2/token
Now how does it make a difference if this App is single tenant App or Multi Tenant App? Using this Id/Secret, I can access login to this app from any service anywhere.
Also, What does it mean by "Adding users to this App" ? Say if i add a user to this app, does it mean that that user will have access to the subscription in Tenant1 as well?
Now how does it make a difference if this App is single tenant App or
Multi Tenant App? Using this Id/Secret, I can access login to this app
from any service anywhere.
The difference would come if you want this application to be available in other tenants.
With single tenant, the Service Principal will be created only in your tenant. If you make this application multi-tenant, once a user in a different tenant consents to the application a Service Principal will be created in that tenant. That Service Principal must be granted appropriate Azure RBAC permissions in Azure Subscriptions associated with that other tenant. Only then your application will be able to perform operations on an Azure Subscription using client id/secret.
Also, What does it mean by "Adding users to this App" ?
When you create an application, you can define some roles specific to that application. When you add users to the application, you can assign users in one or more of those roles and then whenever your users access the application, they will be able to do operations allowed by those roles.
To elaborate, let's say your application is a Web API that has 2 controllers actions - Get and Post. What you can do is restrict the access to these controller actions based on the application roles. A user in appropriate role will be able to access those controller action.
Say if i add a user to this app, does it mean that that user will have
access to the subscription in Tenant1 as well?
Not necessarily true. If you're invoking Azure management APIs on behalf of the signed-in user, then they must be assigned proper Azure RBAC role to perform operations. However if you're invoking Azure Management APIs on behalf of the application, then you can configure your application so that these APIs are called in appropriate portions in your code which are protected by the application roles. For example, you would want to implement read operation in your Get controller action and a create operation in your Post controller action.
In your example, if App1 was a single tenant app, it will only have access to the resources granted to it in Tenant1. While you can use that app_id and secret in a code that runs anywhere: in that tenant, in another tenant or even in another cloud, the code can only access the relevant resources in Tenant1.
If you want your app to be able to access resources across multiple tenants, it needs to be added to each of those tenants by an administrator in the respective tenants. This can only be achieved when you have configured App1 as a multi-tenant application.
Adding a user to an application allows the user to access the application itself. The user does not automatically get/inherit any permissions that are granted to the application (such as a role in a subscription in your case)
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 currently building an headleass application (without front end). This app has to be run as deamon and need to update calander entries of user in different tenant.
We have our seperate Azure subscription where we have created a VM and hosting app. we have different Azure AD tenant thatn the target tenant. I was thinking of registrating the app in our tenant as multi-tenant app. But then I am not sure how it will authorise to change resurces in another tenant.
Or it is must for app to be registered in target tenant?
One of the most important thing is we dont want interactive admin consent flow, as we want everything to be an automatic process. None of the document explains the significance of tenant ID in authentication flow. Anybody knows anything ?
First, you need to create a multi-tenant application in the original tenant, and then grant the application the Calendars.ReadWrite application permission.
Next, run admin consent url in the browser, and then you need to log in with another tenant's administrator account and consent. The multi-tenant application will then be added to the target tenant as an enterprise application. https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={client-id}.
At the same time, the application will have the Calendars.ReadWrite application permission in the target tenant. Finally, you only need to use the client credential flow to obtain the token and then call the Update calendar api to change the calendar entry of another tenant.
We currently have a simple AspNet Core website that is logged into by a "Manager". It gives them access to data about company branches they manage and the customers that use those branches.
The managers have an account in our Azure AD organisation. Currently we some appRoles defined in the website's App Registration. We have an appRole for each branch called "BRANCHNAME_Managers" this feels more like a Group. From memory I think we had problems accessing the groups a user was in from within the website so used the appRoles as they appear in the ClaimsPrincipal.Claims.
We want to create an api that is called from that website. That api needs to know what branches a manager manages. That api would have a seperate app registration in Azure AD and it seems that appRoles configured in the Web Site App registration would not be passed through to the web api. Therefore I think we need to move away from appRoles defined in the WebSite App Registration. Is this correct?
Bearing in mind what we are are trying to control access to, the branches a manager manages and the customers that are related to those branches should we be using User Groups membership or something we roll ourselves with simple database relationships?
The App roles defined in the website app registration (client app) cannot be recognized by the API. The app roles only exist in the id token in this case. But we need to verify the access token to access the API.
As I answered in your previous post, you can define the same app roles in the API app registration (service app) and assign those roles to the same managers.
Then you can verify the app roles included in the access token for your API.
General Overview of what I am trying to achieve
I am trying to build an Azure AD Multitenant Web application which allows me to manage resources in customer subscriptions/tenants using the Azure Resource Manager (ARM) APIs. I am pretty new to Azure AD Multitenancy.
The Ideal control flow
1. A customer browses the Applications (ideal an admin of the customer tenant)
2. Will be granted with Azure AD authorize flow
3. Accepts everything and grants admin consent for the AD App in their tenant
4. Unclear: The AD App will be granted contributer access on a subscription or resource
5. My Web App will be able to use the AD App credentials to manage the customer resources using the ARM APIs
Problem
Steps 1-3, 5: Are clear and I know how to build that.
Step 4: I am not sure how to build that so that step happens automatically.
Solutions I have considered
The worst case would be the customer AD Admin must manually grant the AD App access to a subscription or resource using the Azure Portal.
One idea that came to my mind is that you require the user_impersonation permission on Azure Service Management API.
After the user logs in, you could list out the subscriptions available, allowing the user to select one.
Then list out the resource groups if needed.
Once the user confirms a selection, your app could add itself as a Contributor on the targeted resource through the Management API, on behalf of the currently signed-in user.
To do this, you will need the object id of the service principal for your app created in the target tenant.
You can get it by acquiring an app-only token for e.g. the Azure Management API from that tenant's token endpoint after the user has logged in.
The token will contain an oid claim, which is the object id for the service principal.
Of course the user who signs in would have to have the ability to modify access to the target resource.
I would say the downside of this approach is that the organization must trust your app to only do the thing it claims to do.
The approach where they grant the access manually allows them to be in control fully.
I have a client application which runs as daemon mode [no interfaces].
This daemon will speak to app created in Azure (single-tenant currently) to fetch users using O365 Graph API.
Authentication mechanism used is Auth2 certificate/thumbprint.
Permission to app is given directly by admin while creating app in azure itself.
Now i need to make this daemon (client) and app in azure as multi tenant.
Things i followed after reading some articles
Mark app as multi-tenant in azure
Point to /common in token url in client (which runs as daemon) https://login.microsoftonline.com/common/oauth2/token.
Questions:
After this i was able to get access token , but for any query i make i am getting error "The identity of the calling application could not be established".
Since there is no user intervention here , how do i give permission for tenant B app to access tenant A's data like users in my case ? Anything i can do in manifest file
If tenant B's app is accessing tenant's A data , should both app in azure be mutlitenant ?
Lot of articles explains how is the flow based on user login (user consent). But my client application runs as daemon. How do i give permission directly/mechanism in azure app for accessing other tenant's data ?
[Assume i am admin of both tenants and i have complete access to both tenant]
It isn't possible to use the common endpoint when using the client_credentials flow to log into the \OAuth2\token endpoint. This is because common is designed to identify the user's "home" directory and when they log in interactively they are redirected to sign into their home directory unless overwritten.
2 & 3. Tenant B doesn't get a registered application it only get an Enterprise Application. The linked Registered App would be the one is Tenant A, communication here isn't bi-directional. A has an Enterprise Application in A and an Enterprise Application in B. You set the permissions for all the Enterprise Applications using the Registered Application in A but an Admin/User -dependant on the permission type- will have to grant permissions in their respective tenant (A & B). When you log in as a user you utilise the Application Registration. In order to access B you will have to call the token endpoint containing B's tenant id.
To enable one application to be able to access multiple tenants you need to:
make the Application Multi-Tenanted. Make a note of the application's ApplicationId.
Using PowerShell log into the tenant you want to give the Application access to.
Use the Cmdlet New-AzureRmServicePrincipal -ApplicationId <ApplicationId> where is the one you noted earlier.
This will create a service principal in tenant B based on the application in Tenant A. The application in A when then be able to use the token endpoint for Tenant B to log in an access.