Context
I'm building a web application deployed to Azure Webapps where users need to sign in. To accomplish this, I'm leveraging Azure AD with OAuth 2.0 Authorization Code Grant. Since I'm using Nancy (with the ASP.NET host) instead of MVC, I can't follow the official Azure AD MVC examples where all the OAuth handling seems to happen magically in the background.
Redirecting to the OAuth endpoint is straight-forward, and the user is also correctly redirected back to my application with an authorization code.
Problem
Now I need retrieve the user ID in order to match it to the user database in my application. I'm using ADAL for this, because this is basically step D & E of the authorization code grant flow, from what I understand.
Now what puzzles me is that this use case is not supported by Azure AD, stating that
The client '[ClientId]' and resource '[ResouceId]' identify the same application.
Also, as indicated by this answer, "ADAL is not meant to achieve web sign-on in a web application."
I've been able to work around this problem by creating two applications in Azure AD, as suggested by this blog, but it feels like I misunderstood something. This could very well be the case, as I am new to OAuth and Azure AD.
So my question is, what is the correct way to authenticate a user from a non-MVC web application using Azure AD?
the OWIN middleware should work with non-ASP.NET as well. See for example http://unlustrously55.rssing.com/browser.php?indx=24287735&item=13 - in your case you will have to use the OpenId Connect one or the ww-federation one.
Is this purely for users inside your organisation/tenant? It sounds like it.
Why don't you use an App Registration in Azure AD and grant it permissions to access the users profile? You should then be able to retrieve a user's UPN from the token. Please see here:
https://learn.microsoft.com/en-us/azure/app-service/scenario-secure-app-authentication-app-service
Related
My ASP.NET MVC web application is currently using on-premise SMTP server to send mails.
To understand, here is the classic scenario:
Users have to sign-in in the web app with a user/password (encrypted and stored in SQL DB)
Users fill in a form
When form is posted 2 mails are sent (one for the user and one for the team)
We have to migrate to an Azure VM (Virtual Machine) based solution. I am asked to use Microsoft Graph to send mails as a replacement of using SMTP server. I found a lot of documentation and tutorials on this subject. The classic solution asks the user to sign in using Open ID Connect and Azure AD is used for the authentication (MSAL). So a new authentication page is showed to the user where he should authorise the application to perform specific actions like sending mails (for example). See picture below.
In my situation, I prefer not force user to authenticate a second time. As explained in scenario above users already sign in with (basic) user/password not related to Azure AD.
So I thought I would use app's identity in place of user's identity. This way the user should not authenticate a second time. I found a quickstart on the Microsoft's website which seems to fit my needs.
Here is the link: https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-netcore-daemon
Obviously I thought to integrate this concept in my ASP.NET web app and not in a console app but you get the idea.
So I would like to know if the solution of using app's identity in place of user's identity (authentication in Azure AD) to send mails in my ASP.NET web app is a good approach.
I think this is feasible.
In fact, Microsoft does not recommend users to log in to applications based on username/password, which requires a very high level of trust in the application and may bring certain risks.
In your question, you want to use the application to act as its own entity instead of performing operations on behalf of a specific user, so as to avoid repeated login authorization for users. I think this is a good method, but you have to pay attention, if you need to use the application's own identity request token to access MS graph api, then you must grant application permissions to the application, and then use the client credential flow as the authentication flow.
If you're using a VM you could enable managed identity and avoid dealing with credentials. Take a look to this article.
I wanted to know if there is a way for a custom developed web app to tell if an Azure AD SSO also had MFA. Ultimately, I'm trying to block access to a website if there was no MFA during the SSO process. I would essentially be creating a multi-tenanted application. Their documentation doesn't offer anything in this regard, and I know that MFA status isn't available via Graph yet, so I can't check if the user even has it enabled or enforced yet. Thanks!
What tokens are your web app receiving? For example with JWT tokens the amr (authentication mechanism reference) claim can be checked for the MFA claim. See https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens
I'm having difficulties finding documentation for auth0 and microsoft graph integration. My end goal is to have a SPA that can login with a microsoft profile to auth0 (connected to azure ad). Then I want my app to get a token for microsoft graph and do some api calls.
As I've understood it so far, auth0 does not allow you to get the access token to different identity providers in a front end application, but rather that they should use a proxy to get this token. My flow therefore is:
I login with a SPA auth0 app (using a microsoft identity)
This is then used to authenticate to a backend server using a api registration in auth0
The backend has its seperate machine-to-machine app in auth0
Backend api uses this seperate app to get access token to auth0 management api
Current user is fetched (based on the logged in user from front end app login) from management api,
Here i find an access token under the azure identity (if I do the same in the front end, the access tokens are omitted)
Token does not work to call graph, I am unsure of where to send it next.
I am aware that the above is probably completely wrong, that's why I am here :)
My questions are:
1) Is it even possible to get an access token for microsoft graph starting from a login to auth0 in the way I want it to. If not, can it be done from a backend?
2) Does anyone have a link that discusses this, ideally with some code samples.
To answer your first question:
1) Is it even possible to get an access token for microsoft graph starting from a login to auth0 in the way I want it to. If not, can it be done from a backend?
I have had the chance to authenticate apps using the microsoft identity library called MSAl whose documentation is found here. It gives a pretty detailed way to authenticate directly from your SPA.
I have also used the microsoft javascript sdk as it comes inbuilt with token caching and refreshing so that I do not need to build that for myself.
In relation to this,
Does anyone have a link that discusses this, ideally with some code samples.
You can find the samples well described in the samples section of the SDK
I hope this helps.
I've been searching for many hours about a viable architecture for my scenario.
We would like to have a multitenant MVC application where each tenant belongs to a different company.
Each tenant have settings where we can configure their authentication type : Customer AD or Forms.
Is it possible to allow each company to login using their own active directory ? Or by default if they don't have AD, we use forms authentication.
I've read some articles about Azure AD, AD Federation Services + WIF (or more recently OWIN), but I would like some guidance about solutions to achieve it.
Thanks
This is a pretty standard scenario in Azure AD. You'll want to register an Azure AD app in the Azure portal, and use the OWIN OpenIdConnect middleware to do login/session management. If you want to also call a web API or the Microsoft Graph, you may also need to include ADAL (Active Directory Auth Library) to help exchange auth codes for tokens.
Here's a great code sample that shows you how to build a .NET multitenant MVC App. Moreover, the rest of the docs for this stuff can be found at the Azure AD developer page.
Having done this before, the way I did it was to use asp.net-identity and per tenant override the SignIn Manager via dependence injection.
The sign in manager is where the authentication takes place, so there isn't a drop-in framework that just does it (I am aware of), but just overriding a couple of methods in a single class is pretty easy.
Have you looked into Azure AD B2C? You can have users sign in with their companies emails/ AD.
Take a look here: https://azure.microsoft.com/en-us/services/active-directory-b2c/?cdn=disable
As per other answers, Azure AD allows multi-tenancy. Literally just selecting a check-box in the config.
However, the standard way of authentication is OpenID Connect / OAuth.
Also, you cannot change the mode of authentication.
You mention ADFS and on-premises AD. Where do these fit in?
Using ASP.NET Identity along with OpenID connect, you get this functionality. ASP.NET Identity has local accounts, and with OpenID Connect to Azure AD you can have users sign in with their Azure AD account.
The application definition needs to be a multi-tenant application.
You can pretty much follow the instructions here if you are using ASP.NET Core, and then add OpenID Connect as described e.g. here or by just adding code similar to this after the app.UseIdentity calls:
// Add Authentication services.
services.AddAuthentication()
// Configure the OWIN pipeline to use OpenID Connect auth.
.AddOpenIdConnect(option =>
{
option.ClientId = Configuration["AzureAD:ClientId"];
option.Authority = String.Format(Configuration["AzureAd:AadInstance"], Configuration["AzureAd:Tenant"]);
option.SignedOutRedirectUri = Configuration["AzureAd:PostLogoutRedirectUri"];
option.Events = new OpenIdConnectEvents
{
OnRemoteFailure = OnAuthenticationFailed,
};
});
If you create a new app with Individual User Accounts, you can add the code above after the boilerplate code for Identity in the ConfigureServices method of Startup.cs, and then you are pretty much good to go.
I'm looking for some guidance on what people think are the best set of technologies to use. We are looking to create a web portal to allow customers to register/login with standard credentials or their social accounts (Google, Twitter etc).
Once they are registered and logged in to the portal they can access our different web apps which will know who they are and what permissions they have based on a token. We will also need to secure a set of web APIs using some sort of OAuth mechanism, so the user would possibly create an account on the web app and then create an application which would give them the keys they need to access the API from their own app.
We have a basic portal app using MVC 4 and DotNetOpenAuth which allows a user to create an account and login with either a username and password or their Google, Facebook account etc.
The APIs would be MVC 4 Web APIs
Ideally the whole set up needs to be as simple as possible, I've briefly looked into using Windows Azure Access Control (ACS) as a way to cut out some of the heavy lifting but its hard to tell where exactly it all fits together.
Currently we run an ADFS 2.0 server and WIF to allow web login to our apps but it doesn't seem like it would be an ideal choice when integrating the social login and for securing the web APIs
I guess it could be two quite seperate parts, once they are logged into the portal, how would we go about providing some sort of claims token to the other apps they then access to understand who the user is and what they are allowed to do. And maybe the web API authentication/authorisation is its own entity?
Thanks for your time
We ended up using the built in MVC 4 login system and also added JWT token support, when a user is logged in a JWT token containing their claims is stored as a cookie. This is then automatically passed around our sites on the same domain by the browser, when the web API is called from javascript it checks for the token in the headers sent by the browser and either validates it and returns the correct data or returns an unauthorised response.
It doesn't cover all the bases, we can't give trusted third parties access to our web services yet