can someone explain the azure admin consent flow to me as either its not documented well, I cant read and comprehend or something else.
I have a web app that employs a web api in a home tenant
the web api is a permission on the web app
the web api has the web app client id as a knownclientapplication
if i login as a home tenant admin on the web app demanding scope of the web api, everything works as expected:
i am presented with an admin consent dialog INCLUDING the web api
i consent and all is hunky dory
if i login as a client tenant on the web app demanding scope of the web api - using the '/common' tenant, things arent so good:
i am presented with an admin consent dialog EXCLUDING the web api
when i consent, the enrollment ends in an AADSTS650051 stating I dont have access to a resource
this DOES make sense to me as the web api does not have a service principal in the customer tenant and therefore cannot access it, but when i read the documentation is suggests it should work this way. the terms start to blur for me as they are a bit ambiguous which is where I am not sure what I am supposed to do. source
i can make it work if i sign into the web api first as it will create the service prinicpal
then i can login into the web app where it now has access to the service prinicpal
but the documentation doesnt really explain this in the multi tier single tenant but suggests this in the multi tier multi tenant
Ive read it so many times all the words sound like noises now....
anybody ideas/confirmations/tips?
Documentation clearly states knownClientApplications is to be used for single tenant. Multi tenant setup requires 2 consent flows.
I think I found the answer - by accident and dated in 2017, so who knows, eh?
Apparently the knownclientapplications setting which enables multi tier consent only works in the same tenant.
When offering a multi tenant solution, you have to build a multi consent flow where you ask the admin to consent to the applications individually.
So my assumption was correct. Single tenant, good. Multi tenant, nope!
source
Related
I have only recently been tasked with writing some Business-type web applications, in the past many years I had mostly been working on SQL, services, and other non-client project -- so much of this is all new to me. I have had good success picking up and being productive with hosted Blazor WebAssembly. I need work through how to secure a Webassembly, so google lead me to:
https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/hosted-with-azure-active-directory?view=aspnetcore-5.0
While I was not very familiar with the Azure portal, the reference seemed quite detailed and I thought this would be straightforward. I tried walking through the steps to Register a server API app in an existing tenant:
Azure Active Directory > App Registrations, New Registrations -- check
Provide Name for the App -- check
Choose supported account types (accounts in this organizational directory) -- check
Leave Redirect URI options to web and don't specify a redirect URI -- check
Clear Permissions > Grant admin consent to openid and offline_access - NOPE, no option on this screen for this, I wonder if that setting has moved or if somehow I don't the permissions to see it.
Having no other choice to proceed, I select Register.
During a quick look, I could not find anything about openid and offline_access. Is it right under my nose, or no longer needed, is the documentation out of date, or is there an easier approach? I didn't proceed further, other than to tinker, to the client app registration as I felt the server registration was not valid. Are there any other bumps in the road on the client application registration as well?
Just for perspective, right now, I am content to just force a login verified against AAD.
Thanks for any help!
You are correct. There is no Permissions > Grant admin consent to openid and offline_access under normal AAD | App registrations.
But it indeed has this part under Azure AD B2C.
So I guess the document is not updated to synchronize with the Azure portal.
Don't worry about that. You can skip the step 5. After the Azure AD app is created successfully, you can assign and consent the openid and offline_access under Microsoft Graph permissions. Please note that don't forget to click on Grant admin consent for {your 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.
I use Azure apps to sign users in to a web app and a desktop app. I also query for user information via Microsoft Graphs /user/ endpoint.
So we have to apps registered in Azure; one is a web app / api with permissions to sign users in and read all user profiles from graph. The other is a native app with permissions to the first app, and permissions to sign users in.
In one tenant, this works fine. However in the other tenant the web api har permissions to sign users in, but Graph declines access to the /users/ endpoint due to insufficient privileges. The error is: Authorization_RequestDenied, Insufficient privileges to complete the operation.
However the exact same privileges work fine in another tenant. In the faulty tenant we get a token from graph but when we use the token on the user endpoint it throws the insufficient priv. error.
Signing in users via the desktop app (we use owin) works in one tenant but in the faulty one it sais that app tenant.onmicrosoft.com/guid does not exist in tenant.onmicrosoft.com
The app uri is correct in the settings and the app has the same privileges in both tenants.
We tried recreating the apps since this has solved similiar issues when developing things like this before. This time it doesnt seem to work however. Now I'm at my wits end here. Could there be some other issue blocking here?
The faulty tenant is part of a multi-tenant. However we only poll for users in one tenant as of now.
The apps have also been given consent by an admin via the azure portal. What am I missing here? How should i proceed with trying to fix this error?
Edit: I added a new directory in my tenant and it does not work in this new directory. Same error as with our clients tenant.
Working token for directory A:
eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFDNXVuYTBFVUZnVElGOEVsYXh0V2pUQkVOV21GUUgtZjRGS0VjYlIwU3Y1NndrdzhvSjhjbDIwX3JtZEJBc2h6eDhKT2VNZjFEbVFjNm1GUUdxZ2VSRFJZMTEzNXE3ZXJkTjlHTFZ6T3NycnlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIiwia2lkIjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83NTYzNTY2OC03OGNlLTQzNDMtODMzYy0xOWM5ODkzNTRkZWYvIiwiaWF0IjoxNTM5NjExMjk2LCJuYmYiOjE1Mzk2MTEyOTYsImV4cCI6MTUzOTYxNTE5NiwiYWlvIjoiNDJSZ1lNaWExaldMdTJqUmkvWjlQenU4bHZkUEJRQT0iLCJhcHBfZGlzcGxheW5hbWUiOiJLRVlPMzY1IiwiYXBwaWQiOiI1MmQwMTdmZi1lY2ZjLTQ2NjgtYjZkZi0zZDNlZGYwZDFjNjIiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83NTYzNTY2OC03OGNlLTQzNDMtODMzYy0xOWM5ODkzNTRkZWYvIiwib2lkIjoiMjM0ZDhmZTctNmYwZC00NmEwLWI1YmYtNzg1MWY0ZmFmNmMyIiwic3ViIjoiMjM0ZDhmZTctNmYwZC00NmEwLWI1YmYtNzg1MWY0ZmFmNmMyIiwidGlkIjoiNzU2MzU2NjgtNzhjZS00MzQzLTgzM2MtMTljOTg5MzU0ZGVmIiwidXRpIjoiUDNvc0hHdHQyMFdRTXhkLVFxcWNBQSIsInZlciI6IjEuMCIsInhtc190Y2R0IjoxNDQ3MDYyNTMyfQ.prmIaq8PzXfeovQPeIYS20xvZqpjPH-DvZNwQ3v08KOhTnfFaiCkxtw2wh1B37QQDbOveYqCWRi2CE6Uwpb6zg3-tFh1ma852HDqnJHYCKPajxeW9oIewAnCagB5FzOLQRT_EbX-lEREQVcPUHSZpRNmAWEM2MOZjDnkWun_aqohf_1op7Cy40Ol_PkRzoEgmA7pbXeI28IMPW3S4a5M_hBo_MZzRbVdxuG8YQKkVMWX0wAhpLHAYbdF1Rv5sITEpBP-KHdgJkTswLs3xvIRLyXxrXobG1aVQihr7LHFoCIU0NAcCUQLS2xkePuYGRB09k7hFQsbSNxoJSywBZWk7w
non working token for directory B:
eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFDNXVuYTBFVUZnVElGOEVsYXh0V2pUUS1NMnBUdmVjYTgzUXFuVmlBWWpJX0dLNHZrMTBMYVF2dGF5SGQ0WmZDVlRySm0wSmtOVDU2UlJSU0NuUlFPU0k0aVNHdXZZZ1cxelpaTE9KTkJTVHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIiwia2lkIjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC84MTFjNjA2OS1kZDE4LTRmN2UtOTlhMy1lNjA2YzMyYjhhMjAvIiwiaWF0IjoxNTM5NjExMjI1LCJuYmYiOjE1Mzk2MTEyMjUsImV4cCI6MTUzOTYxNTEyNSwiYWlvIjoiNDJSZ1lPZzlraUZYR3BxNCtVMko1NHAvL2N2M0FRQT0iLCJhcHBfZGlzcGxheW5hbWUiOiJGZXRjaGluZ1VzZXJzQXBwIiwiYXBwaWQiOiJiNDAyZjI5Ni05OTAxLTRjNmMtYjA2MC1hNGI1M2VjNmMzMDQiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC84MTFjNjA2OS1kZDE4LTRmN2UtOTlhMy1lNjA2YzMyYjhhMjAvIiwib2lkIjoiYzIyZWJmNmEtZDNkYS00ZGRjLWIzZTYtOWFhY2VmZWY3MmE4Iiwic3ViIjoiYzIyZWJmNmEtZDNkYS00ZGRjLWIzZTYtOWFhY2VmZWY3MmE4IiwidGlkIjoiODExYzYwNjktZGQxOC00ZjdlLTk5YTMtZTYwNmMzMmI4YTIwIiwidXRpIjoiNk4xRnBkRVZEMGFvRnM0UndVRGZBQSIsInZlciI6IjEuMCIsInhtc190Y2R0IjoxNTM5MTU0MTkxfQ.l_7qgXkco5FWR7pbX5rQzAtvnrb1e6xOr5byrvkYDcyNa85KmCu5b6ArfjxTmeDR82XTmYw51n2YAbWl2q8R58dqELOguddwnKkBBCiMwKsD_UvG2oX_M9ZMy-Lc8lERduolyST7D0BZSoYCNe9f0j85AXIOgXr_yMA5MrVz7qSVFKZ1if2BR9YvvMCphW2uQCrebEJAnchyxHiCb5refnhm2sfsDBRJqd5NWwK0-a956a6dC2zg59JbW55-3wezQOfXKYzC5ybzO7l1hV41EnJ4atBW6EvR2er7WyCAFb1Y1hSB_wgZSo7pC4LnQRRm9KXq-x2aSRKiUSg265K0RQ
You need to receive Admin Consent for an administrator of the tenant. I'm assuming that because this happens when hitting /users, you've requested either User.Read.All or User.ReadWrite.All. Both of these require Admin Consent before a normal user can authenticate and provide User Consent.
I wrote an article a while back that you might find this helpful here: User vs Admin Consent. The examples target the v2 Endpoint while it sounds like you're using v1. That said, the same consent models and workflow apply to both v1 and v2.
We have an Azure resource app whose APIs we want to expose for access by a client app on Azure. The two apps are on different tenants. The users accessing the APIs (Office 365 account holders) are on different tenants.
The whole set up works when we manually provision a service principal on the tenant that is trying to authenticate from the client app against the resource app. By that I mean they are able to log in using their Office 365 account and are shown the consent screen.
If we do not provision a service principal on the AAD tenant of the user trying to authenticate, we get this error:
AADSTS65005 - The app needs access to a service <service> that your
organization org.onmicrosoft.com has not subscribed to or enabled. Contact
your IT Admin to review the configuration of your service subscriptions.
It is not feasible for us to provision a service principal on every tenant that is accessing our app (resource app). Is there something we are missing? Are we using the right flow?
You can find help for your scenario here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent. (Scroll down to Multiple tiers in multiple tenants)
In the case of an API built by an
organization other than Microsoft, the developer of the API needs to
provide a way for their customers to consent the application into
their customers' tenants.
The recommended design is for the 3rd party
developer to build the API such that it can also function as a web
client to implement sign-up:
Follow the earlier sections to ensure
the API implements the multi-tenant application registration/code
requirements
In addition to exposing the API's scopes/roles, ensure
the registration includes the "Sign in and read user profile" Azure AD
permission (provided by default)
Implement a sign-in/sign-up page in
the web client, following the admin consent guidance discussed earlier
Once the user consents to the application, the service principal and
consent delegation links are created in their tenant, and the native
application can get tokens for the API
Basically, all of the parts that your app needs must be present as service principals in the customer's tenant. This is a requirement of AAD.
The only way for that to happen is for an admin to go through consent for the API and app separately, since they are registered in different tenants.
If they were registered in the same tenant, you could use the knownClientApplications property in the manifest to allow consenting to both at the same time.
In my case, I am exposing my own API and trying to access this API from my other Application (Client Credentials mode), I removed the default permission on both of the app(consuming app and api app) - "Azure Active Directory Graph-> User. Read" since I thought I don't need that but that caused this problem "The app needs access to a service .... that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service+subscriptions.
I got the clue from the answer of #juunas - point 2. Thx Juunas
my question is similar to question Multi-Tenant app - OneDrive Business API
but i want my application to access the one drive from tenants of other different azure subscription, is it possible? i understood that if i register my application and mark it as multi-tenant, it will allow me access the tenant in my azure subscription, but if i want to access the tenant using the same application but in different azure subscription whats the way.
What’s kind of authentication flow are you using? Normally, we use the Authorization Code Grant Flow that the user delegates access to a web application. In this scenario, to enables the users on other tenants to login the website and access their Office 365 resource, we only need to enable the multiple-tenant app on the Azure portal.
but if i want to access the tenant using the same application but in different azure subscription whats the way.
It depends on which REST you were using. It is same as we are call the REST API for the single tenant app if we are using the Microsoft Graph to query the OneDrive for business. The endpoint of the list children of a driveItem is still like below no matter which tenant the user login:
GET https://graph.microsoft.com/v1.0/me/drive/root/children
GET https://graph.microsoft.com/v1.0/me/drive/items/{item-id}/children
GET https://graph.microsoft.com/v1.0/me/drive/root:/{item-path}:/children
If you were using the Office 365 REST API, we need to discover the service endpoint. You can refer to here for more detail about Office 365 Discovery Service REST API.
Depending on the permissions that you need normally the tenant admin of the other tenant has to add the application to their own Azure AD. With the newer app model v2 this is quite a lot easier as the admin can simply give consent once in the normal consent screen for the entire tenant. See here for a mor elaborate explanation of how this would work.