使用Windows域帐户和应用程序管理的帐户

Question

创建一个基于Windows域用户进行身份验证的ASP.NET MVC应用程序很容易.创建一个使用Entity Framework存储的个人帐户也很容易.事实上,两者都有项目模板.

但我想利用BOTH各种认证在同一应用程序.我试图结合两个项目模板的代码.我在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))
    }
});

中间件中存在cookie身份验证似乎导致域身份变为未经身份验证.如果我采用此行,域身份验证将起作用.但没有它,我似乎无法支持个人用户帐户.

我已经下载了katana项目源代码并检查了CookieAuthenticationHandler.cs,但我不太明白它是如何在OWIN管道的上下文中工作的.

如何使用ASP.net身份框架允许我的应用程序从Windows域或特定于应用程序的用户存储中验证用户？

Answer 1

最简单的方法是只有2个不同的演示项目用于身份验证/授权.

这具有依赖现有框架和标准配置的优点.

从那里,你决定要么

• 为每个互联网用户创建一个AD用户,或
• 为每个AD用户创建一个DB/Internet用户.

为每个AD用户创建Identity用户更容易实现.然后,整个应用程序中可以存在相同的cookie和过滤器.

在这种情况下,您可以

• 使用子域名为您的应用程序
• AD Authentiction项目可以具有认证/授权的单一目的,然后Web应用程序可以代表您的应用程序的其余部分.

或者,如果您想要一个真正的统一解决方案,请使用MohammadYounes/Owin-MixedAuth

MohammadYounes/Owin-MixedAuth

Install-Package OWIN-MixedAuth

在Web.config中

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

在Startup.Auth.cs中

app.UseMixedAuth(cookieOptions);

:

:

这个怎么运作:

处理程序用于ApplyResponseChallengeAsync确认请求是401挑战.如果是,则重定向到回调路径以从IIS请求身份验证,该IIS配置为查询AD.

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

一个401质询是由未经授权的用户试图使用要求身份验证的资源而导致的

处理程序用于InvokeAsync检查请求是否来自回调路径(IIS)然后调用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用于AddCookieBackIfExists读取由AD创建的声明cookie并创建它自己的声明.

向AD用户提供与Web用户相同的基于声明的Cookie.AD现在像任何其他第三方身份验证器(Google,FB,LinkedIN)

Answer 2

出于这个原因,我无法使用预先烘焙的解决方案进行身份验证.在我们的项目中,过去的几年(和敏捷方法)让我们有4种不同的方式来进行身份验证,这很烦人,但我们支持该领域的所有旧版应用程序,因此我们必须保留所有这些(至少目前为止).

我最终创建了一个工厂,它确定了身份验证机制(通过诸如令牌格式,存在其他一些东西之类的任何方法),然后返回一个包装器,其中包含验证该身份验证方法和设置主体的逻辑.

这将在自定义HTTP模块中启动,以便在请求到达控制器之前构建和验证主体.在你的情况下,我认为Windows Auth将是最终的后备.在我们的Web API应用程序中,我们采用相同的方法,但通过委托处理程序而不是HTTP模块.你可以说,这是一种本地令牌联合.当前实现允许我们添加或修改任何验证过程,或添加任何其他令牌格式; 最后,用户最终会获得适当的身份或被拒绝.只用了几天就实现了.