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

创build一个基于Windows域用户进行身份validation的ASP.NET MVC应用程序很容易。 创build一个使用entity framework存储的个人账户也很容易。 实际上,两者都有项目模板。

但是我想在同一个应用中使用两种authentication。 我试图合并来自两个项目模板的代码。 我在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身份validationowin中间件的存在似乎导致域身份变得未经身份validation。 如果我把这条线路出去,域authentication工作。 但没有它,我似乎无法支持个人用户帐户。

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

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

最简单的方法是有两个不同的演示项目仅用于身份validation/授权。

这有赖于现有框架和标准configuration。

从那里,你决定要么

  • 为每个互联网用户创build一个AD用户,或者
  • 为每个AD用户创build一个DB / Internet用户。

为每个AD用户创build身份用户更容易实现。 那么相同的cookie和filter可以存在于整个应用程序。

在这种情况下,你也可以

  • 为您的应用使用子域名
  • ADauthentication项目可以具有authentication/授权的唯一目的,然后Web应用程序可以代表您的应用程序的其余部分。

或者,如果您想要一个真正的统一解决scheme,请使用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挑战 。 如果是这样,它将redirect到callbackpath,以便从configuration为查询AD的IIS请求身份validation。

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

401挑战是由未经授权的用户尝试使用需要validation的资源引起的

处理程序使用InvokeAsync检查请求是否来自callbackpath (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创build的声明cookie,并创build它自己的基于声明。

AD用户提供与Web用户相同的基于声明的Cookie。 AD现在像其他任何第三方authentication者( Google,FB,LinkedIN

正因为如此,我还没有能够使用预先解决的解决scheme进行身份validation。 在我们的项目中,过去的几年(和敏捷方法)给我们带来了4种不同的validation方式,这是令人讨厌的,但我们支持所有旧版本的应用程序,所以我们必须保留所有的(至less现在)。

最后,我创build了一个工厂,它可以计算出authentication机制(通过令牌格式,其他一些东西),然后返回一个包含validation该authentication方法和设置委托人的逻辑的包装器。

这将在一个自定义的HTTP模块中被启动,以便在请求到达控制器之前构build并validation委托人。 在你的情况下,我认为,Windowsauthentication将是最后的后备。 在我们的Web API应用程序中,我们采取了相同的方法,但通过委托处理程序而不是HTTP模块 。 这是一种本地令牌联合,你可以说。 目前的实现允许我们添加或修改任何validation程序,或添加任何其他的令牌格式; 最后,用户最后得到一个正确的身份或被拒绝。 只花了几天时间来执行。

在我看来,这个问题的最好答案是使用身份validation和授权框架。 有很多select(商业和免费)。 你当然可以自己写,但我会劝阻的。 许多非常聪明的人得到这个错误。

我会看看IdentityServer3 。 这当然不是唯一的解决scheme,但它是一个相当不错的authentication和授权框架。 这是开源的,很容易起床和运行匆忙。 你的用例是一个常见的用例,你会在上面的链接中find一些非常有用的信息。 在授权和authentication之间清晰分离,社交authentication选项,易于使用封装用户声明的json Web令牌等。

它如何帮助你

IdentityServer3允许您configuration身份提供商来处理身份validation,并且有很多扩展点可以让您实现可以处理两种情况的责任链。 从文档 :

IdentityServer支持使用外部身份提供者的身份validation 外部authentication机制必须封装在Katanaauthentication中间件中。

Katana本身也提供Google,Facebook,Twitter,Microsoft Accounts,WS-Federation和OpenID Connect等中间件,但也有社区开发的中间件(包括Yahoo,LinkedIn和SAML2p)。

要为外部提供程序configuration中间件,请在接受IAppBuilder和string参数的项目中添加一个方法。

IdentityServer3通过浏览器login窗口支持AD作为身份提供者,并通过自定义授权支持更多的编程实现。 您还可以在这里查看关于IdentityServer3和AD身份validation的更多信息。

它也将支持Windows身份validation,你可以看看这里的信息和实例。

这里也有一个相当不错的入门示例。

使用正确的configurationIdentityServer3可以处理您的要求。 你将需要实现自己的身份validation提供程序并将其插入到框架中,但没有比这更多的了。 至于授权,还有很多选项。

Interesting Posts