The question was answered many times already but I am looking a way to customise login screen for multi-tenant web applications registered in Azure AD the way https://portal.azure.com does.
I am aware about custom login page for b2c apps documented at https://learn.microsoft.com/en-us/azure/active-directory-b2c/customize-ui-overview and company branding documented at https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/customize-branding.
The former uses b2clogin.com domain and an option to use MSA as external ID provider. The later applies branding of user's tenant and on the password prompt only.
portal.azure.com instead looks like a mix of both. It uses regular OpenId Connect v1 endpoints and redirects to
https://login.microsoftonline.com/common/oauth2/authorize
?resource=https%3a%2f%2fmanagement.core.windows.net%2f
&response_mode=form_post
&response_type=code+id_token
&scope=user_impersonation+openid
&client_id=c44b4083-3bb0-49c1-b47d-974e53cbdf3c
&redirect_uri=https%3a%2f%2fportal.azure.com%2fsignin%2findex%2f%3ffeature.refreshtokenbinding%3dtrue
The login prompt however presents application logo and github login option similarly to b2c but allows to use MSA account like usual login.microsoftonline.com:
I am wondering if it is possible to do something similar for my own app. The similar question Custom Branding for Login on a Azure AD Multi-Tenant App was asked a few years ago, and the only answer there suggests it's a feature of Microsoft owned apps. Even tho the answer was not accepted I'd trust Anton on this account. Is it still the case today?
Related
I have included SSO (SAML) authorization in my existing application. But for me it was an unpleasant surprise to find that only 2 types of users can use the login through the providers I added (Okta, Azure AD):
Users who are located in the corporate directory of the provider (for example, I made an application on my account, there are no more
users. This means that any other user will not be able to use the
login form, because he is not a member of my tenant)
Third-party users of companies, whose administrators have added a
template of my application from the general list and connected their
users to it.
I expected other results, I need ANY user to be able to log in through these providers (regardless of whether he is in the corporate directory or has his own separate account that is not integrated into my application)
I thought about changing the SAML protocol to OIDC (OpenID Connect), but it seems to me that everything will work in the same way (at least Azure AD, because it seems there are no other options for working with it, except for corporate distribution)
Who had a similar experience, could you tell me what I should use among technologies and protocols so that ABSOLUTELY ANY user can log into my application through Okta / Azure AD / Google? Thanks!
Azure AD login fail screen
Okta login fail screen
You can use Azure AD OAuth2 flows and multitenant apps with MSA (personal account) support to allow any user from any domains and personal accounts to login into your application. Or you can switch to Azure AD B2C (which also relies on OAuth2) to connect different identity providers (Local Azure B2C, Azure AD, Facebook, Google, Amazon, Github, Linked in, Twitter, generics, etc) and allow all their users to login into your application.
I have been able to set up Azure AD Authentication with Auth0. According to my research, Azure AD is similar to AWS Cognito and Firebase. So can we use Azure AD to handle flows like User Creation, Password Reset, Expire Password etc. from a NodeJS Admin Backend?
Azure Ad is microsoft's identity platform. while yes in some ways is similar to aws cognito, it is a bit different as well. it's not designed specifically for developers, it's designed as an identity platform for your organization.
to answer your second question, it really depends on what you are expecting it to do. For example, there is an api, called graph api, which lets you interact and do almost everything you want to azure ad through that api. https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-graph-api create users, groups etcetc. but if you are looking for user signup using their own emails and that sort of thing, the closest thing you should be looking at is Azure Ad B2C.
Azure B2c Takes care of some of the more common scenarios like signups and such
https://azure.microsoft.com/en-us/services/active-directory/external-identities/b2c/
We are building applications in ASP.Net MVC and Web API that use a range of OAuth 2 features - AcquireTokenByAuthorizationCode (using microsoft.identity.web), AcquireTokenSilently, AcquireTokenOnBehalfOf, AcquireTokenForClient for different parts of the application landscape.
The applications use MSAL.Net to interact with Azure AD and users provisioned in it to provide access to resources and that works ok.
We are now looking at building a connect back to the organization's on-prem maintained user accounts so the end users are not duplicated in AAD and on prem, so ADFS maintained in the org is an option. Considering the ADFS instance to be 2016, the one option to have MSAL.Net work with ADFS appears to be having Azure AD federated with ADFS as explained in this article:
https://learn.microsoft.com/bs-latn-ba/azure/active-directory/develop/msal-net-adfs-support
The article only discusses AcquireTokenInteractive and I do not see explanation that other MSAL.Net operations are supported on having AAD federated with ADFS. I would assume that is true, and we have to run through our tests after we have it all configured, but meanwhile,
would anyone have any experience or documentation around having the range of operations with MSAL.Net (and even msal.js) and AAD work OK when AAD is federated with ADFS?
So I went ahead and tried this for myself, setting a VM up in Azure, installed Active Directory, AD FS and configured the federation between Azure AD and the VM AD FS as per the article https://learn.microsoft.com/en-us/azure/active-directory/b2b/direct-federation-adfs.
Then validated the different OAuth features used by our application, specifically (I would expect other oauth features to work as expected too based on the below observations):
AcquireTokenByAuthorizationCode
AcquireTokenSilently
AcquireTokenOnBehalfOf
AcquireTokenForClient
All these feature work as expected. The user is redirected to org login page and redirected back to the application.
A couple of observations along the way
The refresh token lifetime is 12 hours when working with On premise AD credentials integrated via ADFS instead of the few days when user is provisioned in AAD. This is apparently to mitigat the risk of user information changing e.g. password change. If the browser is idle for > 12 hours, re-login by the user is required.
Once authenticated, further OAuth operations do not involve On prem AD / ADFS. The operations are against Azure AD, any browser redirects are to Azure AD for re-auth.
I'm building a service where each user has a calendar, I want to sync users 365 calendar events into their calendar, the tricky part seems to be, that this should be done repeatable by background job on the server, to keep them in sync.
I feel like I've read a bible of documentation from Microsoft, but still gotten nowhere. I eventually stumbled upon this article https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds which allows a server to query the graph api, on behalf of users. This is exactly what I want.
Having created a Azure account, and Active Directory service, I found that only users within the tenant can use this, which makes it rather useless, requiring to add users manually from azure panel.
AADSTS50020: User account 'm#****.com' from identity provider 'live.com' does not exist in tenant 'Default Directory' and cannot access the application 'c0193dea-5145-430a-9c90-325f1229a1fc' 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.
So I'm back at square one, how can I achieve what I described?
I'm not looking for a code implementation, merely a description of how to navigate the monstrosity of Microsoft.
Thank you
Update: Accordingly to Marc link. I tried to flick the multi tenant option, and change the endpoint to use common instead of tenant id. Sadly i'm still getting the same error.
You cannot sign-in to AAD with a non-AAD account using the v1 Endpoint. If you want to use a consumer Microsoft Account (#outlook.com, #hotmail.com, #live.com) then you need to use the Converged Auth model provided by the v2 Endpoint.
I have a walkthrough for the v2 Endpoint that you might find helpful: Microsoft v2 Endpoint Primer. It is similar to the v1 Endpoint but you'll need to register via https://apps.dev.microsoft.com rather than the Azure Portal. Also, v2 apps use Scopes instead of Resources and are multi-tenant out of the box.
This is a broad a question for Stack Overflow. That said, you're incorrect about Azure AD. It is absolutely not limited to a single-tenant. You do however need to register it as a multi-tenant application:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
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.