Using Windows Domain accounts AND application-managed accounts

Question

It's easy to create an ASP.NET MVC application that authenticates based on windows domain user. It's also easy to create one that uses individual accounts stored using Entity Framework. In fact, there are project templates for both.

But I want to utilize BOTH kinds of authentication in the same application. I tried to combine the code from both project templates. I have a problem in Startup.Auth.cs.

// from "Individual Accounts" template
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
    {
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(30),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
    }
});

The existence of cookie authentication owin middleware seems to cause domain identities to become un-authenticated. If I take this line out, the domain authentication works. But without it, I can't seem to support individual user accounts.

I've downloaded the katana project source code and examined CookieAuthenticationHandler.cs, but I don't quite understand how it works in the context of an OWIN pipeline.

How can I use the ASP.net identity framework to allow my application to authenticate users from the windows domain OR an application-specific user store?

Thanks @trailmax. It is certainly a related question, but I'd like to avoid creating application users for active directory authenticated users if I can. — recursive
The problem with trying to avoid creating app users for domain accounts is that your application specific tables referencing those domain accounts are going to look really funky. If a user has, say, a role that only exists in your app (and not the domain) you have to blast away your FK constraints to account for it. Application specific users are the best way of doing this. Your app would just authenticate domain users against AD and not against your app. — James Sampica
The simplest approach is to have 2 different presentation Projects only for Authentication/Authorization. This has the advantage of leaning on existing framework and standard configuration. From there, you decide to either A) create an AD user for every internet user, or B) create a DB/Internet user for every AD user. If you take this approach. B is easier to implement further. Once passed the Authentication/Authorization Projects, have all users operate in subdomains that look for common authentication cookie Or universal Claims. — Dave Alperovich
If you want a truly Unified Solution, this is the approach I would start with Install-Package OWIN-MixedAuth github.com/MohammadYounes/Owin-MixedAuth — Dave Alperovich

Dave Alperovich Dave Alperovich · Accepted Answer · 2015-05-15T17:15:19

The simplest approach is to have 2 different presentation Projects only for Authentication/Authorization.

This has the advantage of leaning on existing framework and standard configuration.

From there, you decide to either

create an AD user for every internet user, or
create a DB/Internet user for every AD user.

Creating an Identity user for each AD user is easier to implement further. Then the same cookies and filters can exist in the entire app.

In that case you can either

use subdomain(s) for your app
AD Authentiction Project can have the singular purpose of Authentication / Authorization, then the Web App can represent the rest of your app.

Alternatively, If you want a truly Unified Solution, use MohammadYounes/Owin-MixedAuth

MohammadYounes/Owin-MixedAuth

Install-Package OWIN-MixedAuth

In Web.config

<location path="MixedAuth">
  <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
</location>

In in Startup.Auth.cs

app.UseMixedAuth(cookieOptions);

:

How it works:

The handler uses ApplyResponseChallengeAsync to confirm the request is a 401 challenge. If so, it redirects to the callback path to request authentication from IIS which is configured to query the AD.

        AuthenticationResponseChallenge challenge = Helper.LookupChallenge(
              Options.AuthenticationType, Options.AuthenticationMode);

A 401 challenge is caused by an unauthorized users attempting to use a resource that requires Authentication

The handler uses InvokeAsync to check if a request is coming from a callback path (IIS) and then calls AuthenticateCoreAsync

    protected async override System.Threading.Tasks.Task<AuthenticationTicket>
                AuthenticateCoreAsync()
    {
        AuthenticationProperties properties = UnpackStateParameter(Request.Query);

        if (properties != null)
        {
            var logonUserIdentity = Options.Provider.GetLogonUserIdentity(Context);

            if (logonUserIdentity.AuthenticationType != Options.CookieOptions.AuthenticationType
                && logonUserIdentity.IsAuthenticated)
            {
                AddCookieBackIfExists();

                ClaimsIdentity claimsIdentity = new ClaimsIdentity(
                    logonUserIdentity.Claims, Options.SignInAsAuthenticationType);

                //  ExternalLoginInfo GetExternalLoginInfo(AuthenticateResult result)
                claimsIdentity.AddClaim(new Claim(ClaimTypes.NameIdentifier,
                  logonUserIdentity.User.Value, null, Options.AuthenticationType));

                //could grab email from AD and add it to the claims list.
                var ticket = new AuthenticationTicket(claimsIdentity, properties);

                var context = new MixedAuthAuthenticatedContext(
                   Context,
                   claimsIdentity,
                   properties,
                   Options.AccessTokenFormat.Protect(ticket));

                await Options.Provider.Authenticated(context);

                return ticket;
            }
        }
        return new AuthenticationTicket(null, properties);
    }

AuthenticateCoreAsync uses AddCookieBackIfExists to read the claims cookie created by AD and creates it's own Claims based.

AD users are provided a Claims based Cookie identical to Web Users. AD is now like any other 3rd party authenticator (Google, FB, LinkedIN)

Using Windows Domain accounts AND application-managed accounts

3 Answers

How it works: