Supporting Individual User Accounts AND Organizational Accounts in MVC5 / ASP.Net Identity 2

Question

I've created an ASP.Net MVC5 application, in which I have configured (and have working fine) Individual User Accounts via Google, Facebook, etc.

What I'd like to do is also support authentication against Azure Active Directory (Organizational Accounts). This would be for internal staff to be able to logon to the app as administrators.

All existing information/guides/documentation I've found typically deals with using one or the other. How would I enable them both together?

If there needs to be a separate logon form for each type of user, that would not be an issue.

EDIT:

I was looking at the Application configuration within Azure Active Directory portal, and notice that they define an "OAUTH 2.0 AUTHORIZATION ENDPOINT". Can MVC5 be configured within Startup.Auth.cs to use this?

Threesquare

Answer 1

I managed to implement this by doing the following:

First, adding a reference to the Microsoft.Owin.Security.OpenIdConnect Nuget package.

Second, configuring it in my Startup.Auth.cs:

app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
    ClientId = "From the Azure Portal (see below)",
    Authority = "https://login.windows.net/<domain>.onmicrosoft.com",
    Notifications = new OpenIdConnectAuthenticationNotifications
    {
        RedirectToIdentityProvider = (ctx) =>
        {
            if (ctx.Request.Path.Value.EndsWith("ExternalLogin"))
            {
                string appBasePathUrl = ctx.Request.Scheme + "://" + ctx.Request.Host + ctx.Request.PathBase;
                ctx.ProtocolMessage.RedirectUri = appBasePathUrl + "/";
                ctx.ProtocolMessage.PostLogoutRedirectUri = appBasePathUrl;
            }
            else
            {
                ctx.State = NotificationResultState.Skipped;
                ctx.HandleResponse();
            }

            return Task.FromResult(0);
        }
    },
    Description = new AuthenticationDescription
    {
        AuthenticationType = "OpenIdConnect",
        Caption = "SomeNameHere"
    }
});

Third, I setup the application in the Azure Portal (classic):

Fourth, I added a separate logon page for admin users:

@using (Html.BeginForm("ExternalLogin", "Home"))
{
    @Html.AntiForgeryToken()
    <div class="ui basic segment">
        <div class="ui list">
            <div class="item">
                <button type="submit" name="provider" value="OpenIdConnect" class="left floated huge ui button social">
                    <i class="windows icon"></i>
                    <span>My Org Name</span>
                </button>
            </div>
        </div>
    </div>
}

Fifth, the ExternalLogin action doesn't need to change - we just let OWIN middleware redirect us to the external login page. The flow would then direct the user back to the ExternalLoginCallback action.

Finally, in the ExternalLoginCallback action, I check the incoming claims to determine that the login was via Azure AD, and instead of calling into ASP.NET Identity, I construct my own ClaimsIdentity, which has all my (application specific) claim information which my application recognises as an admin user.

Now, admin users navigate to https://example.com/admin, click the login button, are redirected to the Azure AD login, and windup back at the application as an admin user.

Threesquare

Answer 2

Your best bet would be to leverage Azue AD Access Control Services (ACS) and setup the Identity Providers to include Azure AD, Facebook, et al. See the documentation here: http://azure.microsoft.com/en-us/documentation/articles/active-directory-dotnet-how-to-use-access-control/

Coker

Yes, I have had a quick look into that. I was really trying to avoid this - the user experience doesn't really match what I want to achieve. – Threesquare

You might be able to roll your own leveraging something like Thinktecture's Identity Server (thinktecture.github.io/Thinktecture.IdentityServer.v2). Downside is that is no longer a hosted service and you need to feed and maintain the server acting as your authentication handler. – Coker

Answer 3

ACS can indeed be used, however as you have already implemented Google/Facebook signin I recommend that you directly integrate with Azure AD instead of going through an intermediate STS like ACS/thinktecture.

If your app' signin experience involves the user clicking on "Signin with Google/Signin with Facebook" stickers - you can add "Signin with your company' account." (there's even a recommended branding style: http://msdn.microsoft.com/en-us/library/azure/dn132598.aspx If you app performs realm discovery and forwards the user to the appropriate IdP (employing a text box saying something like "Enter your email address to sign in") - then you could add matching for your company name email addresses and forward those users to AAD.

In both cases, your application will issue an SSO request to SSO endpoint of AAD: https://login.windows.net/{company domain name/id}/{wsfed/saml/oauth2}. If you're using .Net, WSFed, this should see you through: http://msdn.microsoft.com/en-us/library/azure/dn151789.aspx. Look for the code:

SignInRequestMessage sirm = FederatedAuthentication.WSFederationAuthenticationModule.CreateSignInRequest("", HttpContext.Request.RawUrl, false);
result = Redirect(sirm.RequestUrl.ToString());   

There's also an OpenIdConnect sample here: http://msdn.microsoft.com/en-us/library/azure/dn151789.aspx

Bigford