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.
Related
We need to authenticate both corporate users and external users (partner, customers, third party) into the same application.
Corporate users will authenticate using Azure AD, I want them to have SSO experience.
For external users I was thinking of Azure AD B2C.
The application is built with Asp.NET MVC/WebApi + AngularJs.
For the scenario described above, I understand I will need 2 different Azure AD tenants.
I'm planning to use the Microsoft new Authentication Library MSAL, but I can't find how to configure 2 tenants.
What is the recommended approach for login both corporate and external users ?
Thanks in advance for any help!
At this time, you must treat Azure AD & B2C as two separate identity providers in your application. I've created a quick & dirty example of such dual integration in a web app here. In an AngularJS app, or in an app that uses MSAL, the integrations will be different. But the high level pattern will be the same.
With this approach, you'll have to ask users which type of account they want to sign-in with, so you know which provider to invoke.
I'm building a web portal where my customers can log in - pretty standard stuff.
Now I would like my customers to log into the portal by using their "own credentials".
The optimal solution would be that users could use one of the following:
Office 365
If they have O365 then just sign in with their own credentials. This scenario is covered by the OOTB VS template
On-premise ADFS
If the customer has an on premise ADFS then they should be redirected to that to sign in. (I know this needs configuration for both parties, buts that's ok)
None of the above
The customer does not have any of the above and therefore need a "local account". In this case I would like to use Azure AD B2C to store the credentials.
I can do all of the above, but I have never tried to do it all together in one site.
Therefore, is it at all possible and how should I be constructed?
And how would the login experience be?
I'm using OWIN.
Any advice would be helpful.
Thanks!
When you say "local". you mean in AAD?
Azure B2C allows non-federated (i.e. don't use ADFS) users to provision and then authenticate themselves.
However, such users are "outside" of the normal authentication flow and cannot use ADFS or have O365 licenses.
In terms of ADFS and O365, you need to set:
Convert-MsolDomainToFederated
as in Step-By-Step: Setting up AD FS and Enabling Single Sign-On to Office 365.
In future Azure AD B2C will add the ability for users to login using their 'Work Accounts'. Those are the accounts used for O365. If the respective tenants have setup federation with Azure AD, ADFS federation will also work.
Meanwhile, the old work around for you to get it to work is to have your application
1. handle multiple tokens. [Azure AD, Azure AD B2C, ADFS or other federations] by implementing each federation to get the tokens.
2. implement the idp selection screen on the application and federate to appropriate party.
I have an ASP.NET MVC 4.6 application and I want to be able to use an application identity to provide access to the Azure Graph API behind the scenes, but I want to use Azure AD users for my applications authentication and authorization.
The end goal is to be able to have a user initially register using Google, Facebook, or enter their own username. During this registration, my application would leverage the Graph API to create an Azure AD user behind the scenes.
Once registered, if the user logs on using Google, Facebook, or their own username, it will look up against the Azure AD users to retrieve groups or roles.
Is this possible, or even a good idea? I'm open to other suggestions. Thanks!
This is possible. Azure AD recently released Azure AD B2C (business to consumer) to public preview. B2C will allow your users to sign up and sign in with consumer identity providers (e.g. Google, Facebook, etc.).
The sign up portion of this creates a special kind of user in Azure AD that has a reference to an identity in the consumer identity provider. The sign in portion of B2C allows users to authenticate with their corresponding identity provider, and that authentication is recognized in Azure AD.
The full documentation starts at: https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2c-overview/, and a ASP.NET MVC sample is at: https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2c-devquickstarts-web-dotnet/.
Alternatively, if you want to do you own, off the top of my head, the best you can do is to build a mechanism where you associate a "regular" Azure AD user with the corresponding social identity provider (e.g. maintain a lookup table). Your users would sign in to your app using each identity provider's protocol, and when they've done so, you "artificially" link them to the corresponding Azure AD users. From Azure AD's perspective, however, these users would not actually be authenticated, so at best, you'd be using Azure AD as a place to store users and groups.
Check out the new Azure B2C offering, in preview, which supports the exact scenario you are asking about out of the box.
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
We are trying to build an ASP.NET MVC 5 web application where two types of users can log in. We have some clients who use Google apps and others use Office 365. Here we already know which client use what service.
The way users login to our website should be as follows:
User sees a page where user has to select their company name from a drop-down.
Depending on company name the user choose, s/he should be redirected to that particular SSO login page.
After authentication, the user shall return to our website, and be considered as authenticated.
Depending on the service they use, we are also planning to leverage their apis, like Calender, Notes, etc.
I searched a lot but found nothing/irrelevant in this regard. Please help.
If you want to implement this on your own, here are some tips from my experience:
Office365 (which is based on Windows Azure Active Directory): speaks a protocol called Ws-Federation with SAML tokens. To this moment, there are libraries for various platforms and languages.
Google Apps, is easier to Office365 since you have to use plain Google OAuth. One thing that might help you is that you can force the domain of Google Apps when doing the authentication by using the querystring parameter "hd" like "?hd=x.com". See this answer and the comments.
What you are trying to do it is not impossible but it requires some work and understanding all the protocols.
Another option is to use an authentication broker like Auth0. Your application sees auth0 as an OAuth provider and you can connect to your customers Google Apps and Office 365 from the dashboard or from an API which means that you can easily automate on-boarding customers. After you create the connection Auth0 will give you a link that you need to give to your customer so they can grant consent to your app to use their directory. From the client side perspective, you can achieve the combobox UI you describe by using auth0.js as follows:
var auth0 = new Auth0({
//settings provide by auth0
});
var combo = $('#company-combo');
//loads the company combobox directly from auth0
auth0.getConnections(function (err, connections) {
connections.forEach(function (c) {
$('<option>')
.attr('value', c.name)
.text(c.name)
.appendTo(combo);
})
});
//trigger login
$('.login').on('click', function (e) {
auth0.login({
connection: $("option:selected", combo).val()
})
});
Once the user logins, your application will get a profile. This profile has a property that indicates the connection/company.
Auth0 also provides an unified API to query/search users, in these two cases it uses the underlying directory but you get again the same profile representation.
Disclaimer: I work for Auth0.
You can use Windows Azure Active Directory ACS as a broker. From MSDN: Windows Azure Active Directory Access Control (also known as Access Control Service or ACS) is a cloud-based service that provides an easy way of authenticating and authorizing users to gain access to your web applications and services while allowing the features of authentication and authorization to be factored out of your code. Instead of implementing an authentication system with user accounts that are specific to your application, you can let ACS orchestrate the authentication and much of the authorization of your users. ACS integrates with standards-based identity providers, including enterprise directories such as Active Directory, and web identities such as Windows Live ID (Microsoft account), Google, Yahoo!, and Facebook.
This blog provides details steps on how to set up ACS.
This article explains how to use ACS in ASP.NET MVC.