asp.net-web-api - 身份验证/授权 MVC 5 和 Web API - Katana/Owin

Question

我在尝试决定开展我的项目的路线时遇到问题。

我一直在阅读 OWIN 规范和 Katana 在 .NET 中的实现。我之所以选择 Katana 路线，是因为与 ADFS 和 token /Cookie 生成相关的 owin 组件。

我有两个项目，一个用于 MVC 5 网站，另一个用于 Web API。将来它们可能位于两个单独的服务器上，但目前它们位于同一台服务器上。

我知道我将使用 IIS，因此我不需要调查 Owin 管道。

我的要求是，有些用户将使用 ADFS 登录，而其他用户将使用角色/成员身份提供商的 token /Cookie 生成登录。根据经过身份验证的人员，我的网页的某些部分将被公开。网页工程师是在razor中完成的。

有谁有任何 Material 可供我阅读以帮助解释我可以采取的设计流程吗？或者有人做过与我正在经历的类似的项目可以添加任何建议吗？有很多不同的文档描述了我需要的特定内容，但没有描述全局；就像只谈论 WebAPI 和 ADFS，或者 WebAPI 和 windows azure 等等。

我的理论是在MVC5网站项目上实现身份验证/授权，在Web API上实现授权(两者之间需要以某种方式存在通信)。然后，我可能会为 ADFS 创建项目的副本，并为 token /cookie 身份验证创建另一个副本？或者也许我必须进行 4 种不同类型的身份验证:2 种用于 adfs，我在其中针对 MVC5 网站和 Web API 进行身份验证，另外 2 种用于 token /cookie 生成。

任何建议都会有帮助，因为我对这种技术不太熟悉。

Answer 1

我可以说 OWIN 中的 WsFederation 选项很好，但需要 cookie...而且它们是与使用 cookie 的本地身份验证不同类型的 cookie。 ADFS 2.0/WsFederation 使用 AuthenticationType="Cookies"，本地身份验证使用 AuthenticationType="ApplicationCookie"。据我所知，它们显然是不兼容的。我认为您必须对 ADFS 使用 token 身份验证，但我相信这需要 2012R2 上的 ADFS 3.0。为此，请使用 OWIN OAuth。

更新:经过一段时间的研究，我已经弄清楚如何让这两种身份验证类型在同一个 Web 应用程序中和平共存。使用 OWIN，设置调用 UseCookieAuthentication 两次，一次启用新的 WsFederationAuthentication 中间件，另一次启用本地 cookie 身份验证。它并不直观，而是在幕后为每个指定不同的身份验证类型，将它们设置为不同的身份验证“引擎”。这是它在我的启动中的样子:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
        {
            OnResponseSignIn = ctx =>
            {
                ctx.Identity = TransformClaims(ctx, app);
            }
        }
});

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    Provider = new CookieAuthenticationProvider
    {
        OnResponseSignIn = ctx =>
        {
            ctx.Identity = TransformClaims(ctx, app);
        }
    }
});

app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions
{
    Wtrealm = Realm,
    MetadataAddress = Metadata,
    Caption = "Active Directory",
    SignInAsAuthenticationType = CookieAuthenticationDefaults.AuthenticationType
});

这成功地允许用户对本地 SQL 表或 ADFS 2.0 进行身份验证。 TransformClaims 标注允许我标准化这两个提供者之间的声明，以便它们保持一致。

编辑:这是一个非常基本的 TransformClaims。您可以在其中执行很多操作:从数据库获取用户、设置导航声明、自定义权限、角色集合等等。我刚刚根据一个更大的实现构建了这个精简版本，因此我没有运行它，但希望您了解如何利用 OnResponseSignIn 事件。

private static ClaimsIdentity TransformClaims(CookieResponseSignInContext ctx, IAppBuilder app)
{
    var ident = ctx.Identity;

    var claimEmail = ident.Claims.SingleOrDefault(c => c.Type == ClaimTypes.Email);
    var claimName = ident.Claims.SingleOrDefault(c => c.Type == ClaimTypes.Name);

    //normalize my string identifier
    var loginString = (claimEmail != null) ? claimEmail.Value : (claimName != null) ? claimName.Value : null;
    var efctx = ctx.OwinContext.Get<DBEntities>();

    var user = UserBL.GetActiveUserByEmailOrName(efctx, loginString);
    if (user == null)
    {
        //user was auth'd by ADFS but hasn't been auth'd by this app
        ident.AddClaim(new Claim(ClaimTypesCustom.Unauthorized, "true"));
        return ident;
    }

    if (ident.Claims.First().Issuer == "LOCAL AUTHORITY")
    {
        //Local
        //local already has claim type "Name"
        //local didn't have claim type "Email" - adding it
        ident.AddClaim(new Claim(ClaimTypes.Email, user.Email));
    }
    else
    {
        //ADFS
        //ADFS already has claim type "Email"
        //ADFS didn't have claim type "Name" - adding it
        ident.SetClaim(ClaimTypes.Name, user.UserName);
    }

    //now ident has "Name" and "Email", regardless of where it came from
    return ident;
}