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.
Related
I've been poking around MS Graph OAuth2 consent and access token for the enterprise Azure app that had been created along the way. Basically, I'm confused why when I delete the app, I'm still able to obtain the access token ?
When I decrypt and check the claims, it is referencing the name and object id of the deleted app, but it has no roles, and can't be used to access any resources, which makes sense. But still, I'm confused why is being issued for the app that doesn't exist any more ? For example, if I open the app and select to disable login for users, access token is no longer issued - but deleting the whole app does not behave in the same way.
While working with applications in Azure AD, you should be aware of few things like:
App Registrations is where you register an application and configure the details like API permissions, client secrets, client certificates, token claims, app roles etc....
Enterprise Applications are list of service principals that are associated with applications in App Registrations which defines who and what resources the application can access.
When an app is registered in Azure AD, it's corresponding service principal will be created with same name and same App ID in Enterprise Applications blade automatically.
Please note that, whatever changes you do to service principal will directly affect the registered application and vice versa.
I tried to reproduce the same in my environment and got the below results:
I have registered an application in Azure AD and granted permissions like this:
Go to Azure Active Directory -> App Registrations -> Your App -> API Permissions
I generated an access token using client credentials flow, and I can see the roles claim in decoded token like below:
Now, I deleted the Enterprise Application of same name and App ID like below:
Go to Azure Active Directory -> Enterprise Applications -> Your Application -> Properties -> Delete
After deleting that Enterprise App, I'm still able to generate the access token and can't find roles claim now like below:
As the service principal of the application is deleted, you cannot access the other resources which removes permissions from token.
Please note that,
If you delete the application in App Registration first instead of Enterprise App, it will automatically delete the associated service principal (Enterprise App) too along with it.
Then you cannot even generate the access token as it gives Unauthorized client - Application not found error. Unable to generate access tokens is similar to disabling login for users.
Reference:
Apps & service principals in Azure AD | Microsoft Docs
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)
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.
I am developing a web application that allow users from any azure organization to give my application reading rights on their OneDrive using windows Graph-Api (scope: File.Read.All)
I registered a multi-tenants application in the azure portal and i configured the application like it is explained in the documentation
I need to Allow a user from other azure organisations to make a consentment for my application to read files content, but in my case i get a "Need admin aproval" after sending Authentication Code URL (tested with a user from another azure organization)
AuthenticationCode:https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=XXX&response_type=code&redirect_uri=YYY&scope=user.read files.read.all offline_access&state=ZZZ
What a user get after authetification to his Office-365 account
I know that there is other applications who do not have this issue, for exemple the application app.diagrams.net need only user consentment and not admin consentment even if it ask for read write scopes
diagrams.net AuthenticationCode:https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=b5ff67d6-3155-4fca-965a-59a3655c4476&response_type=code&redirect_uri=https%3A%2F%2Fapp.diagrams.net%2Fmicrosoft&scope=user.read files.readwrite.all offline_access&state=cId%3Db5ff67d6-3155-4fca-965a-59a3655c4476
What a user get with diagram application
This is not because of any particular scope. The answer to your question is discussed under "application provisioning" in Azure AD (AAD) terms. Put simply, an AAD application needs to be "provisioned" into an AAD tenant, and a tenant admin can choose whether users can initiate this by themselves or not. Here, it seems this is not allowed.
In more detail, when you create an AAD application, you create 2 objects: a representation of the application, and a "Service Principal" that handles access to that application. When you offer your AAD app to other tenants/organizations, they need their own service principal object to be able to access your application, and this happens through admin consent i.e. provisioning.
In general, there are 2 articles that you should take a look:
How and why applications are added to Azure AD
How to: Sign in any Azure Active Directory user using the multi-tenant application pattern
And these code samples should clarify the process:
Developing a Multi-tenant (SaaS) application with the Microsoft Identity Platform
Protect a multi-tenant SaaS web application that calls Microsoft Graph using Azure AD & OpenID Connect
EDIT: Correction: tenant admins can choose or not whether users are allowed to initiate app provisioning. Credits: #jasonJohnston.
We are building a Web App/API to publish in our Azure AD and want to provide access to the app by inviting (B2B scenario) external users into our Azure AD. This will create accounts in our Azure AD of type "Guest" which we will use to assign permissions to the app. In this scenario, do we need to configure our application to be "multi-tenant"? There are steps to take inside the code to accommodate for multi-tenant sign-ins and there is a setting on the Settings tab of the App Registration in Azure AD that is labeled "Multi-tenanted" where you select either Yes or No. On the App Registration setting, there is a pop-out bubble that says:
Designates whether users in external organizations are allowed to grant your
app access to data in their organization's directory
I am not sure how (or if) the code changes and the app registration setting are related but our app will not need access to any data outside of our directory.
No your app does not need to be multi-tenanted and you do not need to direct users to the /common endpoint. I have tested this, and you still get a kind of SSO experience.
Example paul#org1.com (homed in Org1 AAD) is a guest user in Org2 AAD (invite has been accepted). Now this same user opens a private browser and logs in to Org1 AAD.
The user then tries to hit a web app with app registration in Org2, and web app redirects user to https://login.microsoftonline.com/org2.onmicrosoft.com/oauth2/authorize.
Result, user is considered logged in by AAD and gets redirected to the redirect_url with tokens, etc.