Are Azure Active Directory app roles only supported for accounts in the same tenancy?
I am trying to use Azure Active Directory to authenticate users both on my tenancy, others, and social accounts, and be able to manually assign different app-level roles.
What I would like:
Users would sign up using any of these methods, and I would see them in the 'Users and groups' blade of the Enterprise Application in Azure portal (or I could invite them). I would assign app roles (roles specific to my app, eg engineer/technician/residential user) via the 'Add user/group' button.
When logging in to my app, I retrieve the app roles via idTokenClaims.roles[]
What happens instead:
This works fine for user accounts already in my Azure tenancy. But for other Microsoft accounts (eg theirname#outlook.com or MS accounts created with any email address), the user doesn't appear in Azure portal after logging in unless I manually invite them. After inviting them (and accepting the invite), I see a user like theirname_outlook.com#EXT##mytenancy.onmicrosoft.com. I can assign app roles to this user, but their idTokenClaims.roles[] is not returned.
Other social accounts (eg Twitter, facebook) seem to not be supported at all
What else I tried
I also investigated AD B2C, which gives the developer more control over the login flow, and supports other social accounts other than MS (which looks good), but it seems that doesn't support app roles at all.
Am I trying to use the wrong tool for the job?
All I want to do is support any user to sign up to my app, and for an admin to set what their app-specific roles should be.
Update
I am using the MSAL auth library, following the instructions
https://login.microsoftonline.com/Enter_the_Tenant_Id_here should be one of the following:
If your application supports accounts in this organizational directory, replace this value with the Tenant ID or Tenant name. For example, contoso.microsoft.com.
If your application supports accounts in any organizational directory, replace this value with organizations.
If your application supports accounts in any organizational directory and personal Microsoft accounts, replace this value with common.
To restrict support to personal Microsoft accounts only, replace this value with consumers.
Because I wanted this to work with any social account, I chose https://login.microsoftonline.com/common. This shows a UI that allows you to use any organisation or personal MS account, or sign up for a personal MS account with any email address. But I noticed the objectId returned for personal accounts is different to the id when I manually invite the account in azure portal. I changed to use my TenantID instead, and that worked. Personal accounts that have been previously invited via portal can log in. Other personal accounts get an error and cant log in. App roles are now returned for these personal accounts. This now partially solves my original problem, but I still have some unsolved issues:
this method shows a slightly different UI that doesn't allow the user to sign up for a new MS account in this flow
I still can't use other oauth accounts eg Twitter/Facebook. Do these not support app roles at all?
the instructions quoted above seem incorrect, clearly it is possible to log in using "accounts in any organizational directory and personal Microsoft accounts" via TenentID, not common, once they've been invited to the app
App roles absolutely support guest accounts. But as you can see, the id token of the guest account does not seem to contain the roles claim, and it is not clear whether this is by design. But the roles claim will appear in the access token.
I think an access token you can be used, and the access token also contains user information.
Related
I have an app (ASP.Net Classic) that is using Azure AD authentication. Now, we want to allow user outside of the organization to sign in. I read few document B2C and B2B, but I am unable to see which one to good for me.
I am looking that members in the organization should sign in and doesn't have to create new account. One of the option B2B suggested that to add user to in AD as a guest user but this is the manual process, it would be good if it can be automated. Also that doesn't describe how user would send the request to for login info.
It depends on your use case.
Imagine a large company. They have Azure AD for their employees. Now they want some suppliers to have access to their billing system. Those suppliers are guest users. That's B2B.
For guest users, an admin can send an invitation email that contains a redemption link.
B2C is for the customers of the company. They use the company's e-commerce system. They do not need access to the billing system.
B2C is self-service i.e. these users self-register and can change their profile or reset their password.
We have an application which uses AAD B2B collaboration to invite users. These users are created as guest users in our AAD. This all works great:
Users that have an AAD/Office 365 can use their normal credentials to sign in.
Users that don't have an AAD/Office 365 create their account in the invite redeem process, and can use it to sign in. Microsoft stores these acounts in an external, for us hidden AAD.
Situation:
An organization uses our application. This organization doesn't have an own AAD/Office 365 yet. We invite some employees of this organization in our AAD using their email addresses. They get guest accounts in our AAD.
After a while this organization gets its own AAD/Office 365, for their existing domainname. This domainname was previously used in the email addresses in the invite redeem process.
The AAD admin of the organization creates the AAD, and immediately sees existing user accounts: all the accounts that have been invited are shown in the AAD. He didn't expected this when creating a new AAD, and he doesn't know where they come from.
It appears the external, for us hidden AAD, has become visible to the AAD admin.
The AAD admin might decide to delete these accounts, to start with an empty AAD. As a result the employees aren't able to sign in anymore in our application.
Our application uses the Microsoft Graph API to invite the users.
Is there a way to mark the users in the external hidden AAD in some way to make clear where the accounts are coming from? Like mentioning our organization/application in an existing field?
So to be clear: We don't want to set properties on the guest account. We want to set properties on the user account that an AAD admin sees when he has created the AAD. We want to make clear he must not delete this user, because it's created by/for application X.
No, this is a feature of Azure AD.
A domain owner can choose to take over the hidden Azure AD if they choose to create one later.
They control the domain, and thus control the users so it is up to them.
Now of course if you create an AAD Guest user with a Gmail account, they don't actually get added to a huge hidden Google Azure AD.
If AAD thinks the account is a social account, currently they create a personal Microsoft account transparently for that user (so the user always is in control of their account).
So if you invite users using their work emails, you must expect their domain owner to have control over their users' accounts.
AFAIK, there is no property that you could set.
Is there a way to prevent users from logging into their own AAD tenants? For example, allow login to contoso.onmicrosoft.com but not fabrikam.onmicrosoft.com.
My customer has a highly-controlled Azure environment where they are running some servers and PaaS/SaaS applications. Users connect to those servers are use a variety of Azure services and some SaaS (primary concern is PowerBI). They’re concerned that a user could login with a non-company account (wahid#hotmail.com) and then upload sensitive data their own PowerBI workspace.
You cannot prevent a user who has already been in the tenant to login to that AAD tenant, except deleting the user from that tenant.
If one account was created/invited to one tenant, the user just can login to that tenant.
For the scenario you described, I suggest you could revoke the Product license for those users. If you don't assign product license to the user, the user cannot use that App or cannot see that app in My Apps panel. For other SaaS/PaaS app(Web App), you may use user assignment to allow specific users to access the App.
For others: Daniel answered this for me. Short answer, this isn't easy, you would need to inspect the response body for the tenant ID (or name) and then block it. This would also lead to a poor user experience but that's all we can do today.
Yes, you have a few options.
Option 1: Single tenant apps
If you have the ability to create apps in the tenant you want to accept users from, you can mark your app as available to only this tenant (the field is called availableToOtherTenants). This will notify the token service to only authorize access from users in the tenant the app was created in.
Option 2: Multi-tenant app w/ token validation
The other option is to mark your app as multi-tenant (same field as above, just set to true) and implement logic in your app to validate the user's tenant from which the token was issued.
In this scenario, you will need to have some kind of web service that can safely validate access tokens (.NET code sample on this). To check the tenant the user's account belongs to, you'll need to validate the iss field. It'll look something like this,
"iss": "https://sts.windows.net/7fe81447-da57-4385-becb-6de57f21477e/"
in which the GUID represents the tenant ID. This allows your web API to have an allow or deny list based off tenant IDs.
More help
Here's an excellent blog post on token validation.
Azure AD Developer Docs
.NET Web API Code Sample
I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".
We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.
With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.
However, when I use my personal live.com account (with username xxx#gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx#gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:
AADSTS50020: User account 'xxx#gmail.com' from identity provider
'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot
access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
What configuration do I need to change if I want people from any identity provider to be able to access my app ?
Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.
I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.
AppSource only requires work accounts to sign-in. You are using an #gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.
You have three options:
If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.
The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.
For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.
For more information about AppSource requirements and trial options - please see this article.
I'm trying to use Azure Active Directory to authenticate users. I also want Microsoft Accounts (#live.com, #outlook.com, etc.) to be able to sign in to my application.
When I sign in with an AAD user, my application gets a Claim Value back from the login.onmicrosoft.com screen with the user's email address as the claim (user#mydomain.com).
When I sign in with a Microsoft Account user that I've added to my AAD, it returns a Claim Value of "live.com#username#outlook.com" which is perfect.
However, I also want random people to be able to sign in, not just users I add to my active directory. I want anyone to be able to sign in with their Microsoft Account, and it should give me the claim value so that I can create an account for them in my application.
Is there any way to allow these users to log in to my application?
you have 2 options:
Add the MSA OWIN individual auth middleware alongside the OpenId Connect one
If you want to experiment, we are integrating that feature in a future version of Azure AD: http://aka.ms/aadconvergence