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.
Related
I have a multi tenant enterprise app. It authorises a few graph API permissions when installed and has SAML SSO configured. The whole idea is that my customers can install this and in one process grant my application access to their tenant, and setup SSO for that customers users.
The graph API permissions work totally as expected, I get the needed access to the tenants who installed the app.
Then there is the SAML SSO part. That's just totally not working. In my test tenant where I installed my app, it says that the app has SAML SSO and that it is only application owner who can configure - all fine.
I then try to log in (to the web app using this SSO configuration) with a user from my test tenant - no luck!
First I thought that it had to do with the user not being assigned the app, but it complains the the application in tenant A is not available for user in my test tenant and the user should be added to tenant A. That of course is not a solution since I want to use this for customers.
So right now I am stuck with 2 app's. One gallery app for SAML SSO and my app granting API permissions. It works, but it just seems SO stupid. Isn't there a better way?
Azure AD SAML applications are not intended to be multi-tenant, this is why you need to invite external users as guests.
It's worth to mention it's possible for an Azure AD app to support both OIDC/OAuth2 and SAML and thus rely on the same session cookie to obtain an access token for MS Graph.
If you need multi-tenancy, you should use modern protocols such as OpenID Connect for authentication and OAuth2 for authorization. MS Graph relies on JWT access token anyways.
We noticed that, on Azure AD Joined devices on the internet, the browser requests to authenticate on web resources protected by Azure AD (e.g. authentication on office.com) do not pass through ADFS, despite the fact that we have federated authentication in Azure AD. Why this happen?
We also noticed that the MFA challenge is requested only once, on the very first user access to any Azure AD protected resource, despite the fact that we have not allowed MFA token caching (we unchecked the option: “Allow users to remember multi-factor authentication on devices they trust”). Why this happen?
Where are these behaviors documented?
NOTES:
In our tests, the PCs are on the internet (not on the internal network)
On the Azure AD sign-in logs, we see that, every time a user login to the Azure AD Joined PC, there is a Windows Sign-In event logged with source IP equal to the internal IP of the Load Balancer in front of ADFS. That authentication then goes through ADFS. As said, this event does not appear in the logs when the signed-in user then authenticate to a web page protected by Azure AD.
Our Conditional Access policy asks for MFA on every access with the single exclusion of "trusted networks" that, in our case, corresponds to the MFA option "Skip multi-factor authentication for requests from federated users on my intranet"
We are doing our tests on Chrome browser with the W10 Account extension installed for the current user (but no profile authenticated) and on Edge with the profile authenticated with the same user who did the windows sign-in. Same behavior.
If we repeat the tests on the same PC, with another account not having the W10 Account extension installed on Chrome, the behavior on Chrome is completely different: we go through the authentication in ADFS and the MFA challenge, exactly as we see on PC not Azure AD Joined.
Thank you
Its because the Azure AD joined devices have a PRT. See https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token for details. The PRT is a feature to provide an enhanced SSO experience. It is available regardless of whether user is federated or not.
The PRT is acquired during logon. This is what you see as a "Windows signin event" in the Azure AD signin logs. The PRT prevents the need for further AAD resource access to be redirected via AD FS.
Chrome with the Windows 10 account extension makes use of the PRT. Not having the extension forces the federated logon you've observed.
Thank you for your answer.
I have a few additional doubts about this.
Is there a way to force the MFA challenge every time when accessing specific cloud applications from a W10 Azure AD Joined device (with a PRT) by using Chrome W10 Account Extension or Edge with logged in profile? All our tests with Conditional Access Policies were unsuccessful: in the sign-in logs we always found the condition: "MFA requirement satisfied by claim in the token". I understand that the recommendation is to "Configure authentication session management with Conditional Access", but this solution cannot force the MFA challenge for every access to specific cloud applications.
I understand that the PRT is automatically renewed with a rolling window of X days. Here it is written that the lifetime of a PRT is 14 days. Here I read that the sign-in frequency for the rolling window is 90 days. So, what is the default number of days for the renewal of the PRT? And under which conditions (Azure AD settings) the user get an MFA challenge when the PRT is expired? Is the PRT renewed only at Windows Sign-In or also when authenticating through the browser on a Cloud application or in other conditions, maybe also automatically, without user intervention?
The SSO through PRT should be "applicable to the Registered owner of the device and not to any other user who signs in to that device". In our tests this is not true: other Azure AD users who signin to the Azure AD jojned device go in SSO without MFA. Why?
Thank you again
About my question "Is there a way to force the MFA challenge every time when accessing specific cloud applications from a W10 Azure AD Joined device (with a PRT) by using Chrome W10 Account Extension or Edge with logged in profile?"
My understanding is that the answer is NO. Can you please confirm?
I understand and totally agree on the need to minimize MFA challenges but not all the enterprises already moving to modern device management with the first devices in AAD Join & MDM have previously developed a fully comprehensive set of security policies for their devices. For sure, not all of them are ready to use WHfB. I know enterprises that - for some reasons - have excluded the MFA challenge for the MDM device enrollment actions: in these (bad) conditions, from any AAD joined devices, any AD user synched in Azure can access sensitive cloud applications which were protected by MFA when accessed from devices not joined to Azure AD.
IMHO, the documentation is not clear enough on that evidence that the PRT suppresses the MFA: I could see only this small paragraph describing the evidence that AAD Joned device with "adequate" browser conditions do not get MFA challenges. IMHO, this should be clearly highlighted in the documentation related to planning for device management in Azure AD.
About the question on "applicable to the Registered owner of the device and not to any other user who signs in to that device", let me clarify the context, already tested on different lab/prod environments.
Get an Azure AD Joined device registered in Azure AD by the AAD User X
Sign-in to Windows with User X. Open Edge with signed-in profile for User X, open office.com and authenticate: no MFA challenge. This is expected: SSO by PRT
Sign-in to Windows with another User Y in the same directory. Open Edge with signed-in profile for User Y, open office.com and authenticate: no MFA challenge. This is not expected according to this documentation ("[no MFA is] applicable to the Registered owner of the device and not to any other user who signs in to that device").
Thank you
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.
Scenario:
(Azure-hosted) Web App. Users should be able to sign in to my app using a Microsoft Account (i.e. #live.com, #hotmail.com, etc accounts) that has one or more Azure subscriptions. The application would then allow them to view and manage their Azure resources in specific ways through my app.
Points of confusion/frustration:
ADAL vs MSAL for authentication
Azure AD vs Azure AD B2C for the tenant hosting the application
Where do you register the tenant app? In the AD B2C under "App Registrations"? In a regular AD under "App Registrations (Preview)"? On the App Registration Portal (i.e. apps.dev.microsoft.com)?
Which of the above client ID & secret do you use in the web app (in the .config file)?
The documentation for none of these seem to cover the scenario end-to-end and most of it is completely out of sync with other developments.
I am hoping here to get some point of guidance from other developers that have actually gone through this journey themselves (rather than folks that just read the documentation). In specific, I am hoping to get answers from the Azure CXP team that monitors these questions and provides official & supported answers.
Your scenario requires access to Azure APIs, thus you have to make the logins against "regular" AAD, not B2C.
You can't make your logins against MSA accounts directly as they must be members of an AAD to have access to subscriptions.
You can use either ADAL or MSAL to handle the authentication.
Note you must use v2.0 endpoint for MSAL and the "v1" endpoint for ADAL.
See limitations of the v2 endpoint here: https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison.
You register it under Azure portal -> Azure Active Directory -> App registrations.
You can also use the preview version if you want.
You will need the application id (= client id) + a key (secret) from the app registration.
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.