.net - OWIN 身份验证管道正确使用 Katana 中间件？

Question

我希望对内部 ADFS 2 服务使用 WsFederation 身份验证并使用 OWIN 身份验证管道。
什么是中间件应该挂接的顺序，以及在各种场景中需要哪些模块以最少的代码？

例如，看起来 UseWsFederationAuthentication应与UseCookieAuthentication一起使用，但我不确定正确的是什么 AuthenticationType将是( this 帖子表明它只是一个标识符字符串，但它的值是否重要？)或者即使我们仍然需要使用 SetDefaultSignInAsAuthenticationType .
我也注意到 this Katana 项目讨论板上的线程，其中 Tratcher 提到了一个常见错误，但对于代码的哪一部分有错误并不是很具体。
以下(使用自定义 SAML token 处理程序将 token 字符串读入有效的 XML 文档)有效，但它是否最佳？

var appURI = ConfigurationManager.AppSettings["app:URI"];
var fedPassiveTokenEndpoint = ConfigurationManager.AppSettings["wsFederation:PassiveTokenEndpoint"];
var fedIssuerURI = ConfigurationManager.AppSettings["wsFederation:IssuerURI"];
var fedCertificateThumbprint = ConfigurationManager.AppSettings["wsFederation:CertificateThumbprint"];

var audienceRestriction = new AudienceRestriction(AudienceUriMode.Always);

audienceRestriction.AllowedAudienceUris.Add(new Uri(appURI));

var issuerRegistry = new ConfigurationBasedIssuerNameRegistry();

issuerRegistry.AddTrustedIssuer(fedCertificateThumbprint, fedIssuerURI);

app.UseCookieAuthentication(
    new CookieAuthenticationOptions
    {
        AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType // "Federation"
    }
);

app.UseWsFederationAuthentication(
    new WsFederationAuthenticationOptions
    {
        Wtrealm = appURI,
        SignOutWreply = appURI,
        Configuration = new WsFederationConfiguration
        {
            TokenEndpoint = fedPassiveTokenEndpoint
        },
        TokenValidationParameters = new TokenValidationParameters
        {
            AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType
        },
        SecurityTokenHandlers = new SecurityTokenHandlerCollection
        {                        
            new SamlSecurityTokenHandlerEx
            {
                CertificateValidator = X509CertificateValidator.None,
                Configuration = new SecurityTokenHandlerConfiguration
                {
                    AudienceRestriction = audienceRestriction,
                    IssuerNameRegistry = issuerRegistry
                }
            }
        }
    }
);

Answer 1

正如@Tratcher 所说，AuthenticationType参数由 Microsoft.Owin.Security 使用作为查找身份验证中间件实例的关键。

下面的代码将使用以下简单的辅助方法来要求对所有请求进行身份验证。在实践中，您更有可能使用 [Authorize]敏感 Controller 上的属性，但我想要一个不依赖任何框架的示例:

private static void AuthenticateAllRequests(IAppBuilder app, params string[] authenticationTypes)
{
    app.Use((context, continuation) =>
    {
        if (context.Authentication.User != null &&
            context.Authentication.User.Identity != null &&
            context.Authentication.User.Identity.IsAuthenticated)
        {
            return continuation();
        }
        else
        {
            context.Authentication.Challenge(authenticationTypes);
            return Task.Delay(0);
        }
    });
}

context.Authentication.Challenge(authenticationTypes) call 将从每个提供的身份验证类型发出身份验证质询。我们将只提供一种，即我们的 WS-Federation 身份验证类型。

正确的代码

首先，这里有一个“最佳”Owin Startup 配置示例，它适用于一个仅使用 WS-Federation 的站点，就像您一样:

public void Configuration(IAppBuilder app)
{
    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

    app.UseCookieAuthentication(new CookieAuthenticationOptions());

    app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions
    {
        AuthenticationType = "WS-Fed Auth (Primary)",
        Wtrealm = ConfigurationManager.AppSettings["app:URI"],
        MetadataAddress = ConfigurationManager.AppSettings["wsFederation:MetadataEndpoint"]
    });

    AuthenticateAllRequests(app, "WS-Fed Auth (Primary)");

    app.UseWelcomePage();
}

注意 "WS-Fed Auth (Primary)"的使用 AuthenticationType唯一标识我们配置的 WS-Federation 中间件实例。例如，这意味着您可以使用 "WS-Fed Auth (Secondary)"如果您有该要求，可以使用单独的 WS-Federation 服务器作为后备。

此配置将执行以下操作:

首先，告诉 Owin 安全管道，默认情况下我们希望使用 对请求进行身份验证默认的 CookeAuthentication AthenticationType 值 . (这只是 CookieAuthenticationDefaults 类上的一个常量字符串，它是 CookieAuthenticationOptions.AuthenticationType 属性使用的默认值。)

接下来，注册一个带有所有默认选项的cookie认证中间件实例，所以它对应于AuthenticationType我们在步骤 1 中设置为默认的键。

接下来，使用我们在 Web.config 文件中定义的选项注册一个 WS-Federation 身份验证中间件实例，并带有自定义的 AuthenticationType 值，以便我们稍后引用 .

在所有身份验证中间件注册完成后，我们告诉管道对所有请求进行身份验证(通过我们的自定义帮助方法调用 Microsoft.Owin.Security 方法来向任何未经身份验证的请求发出质询)

最后，如果用户已通过身份验证，则显示欢迎页面!

错误的代码

所以这里有几种方法可能会出错。

不提供默认身份验证类型

为了进行实验，我尝试这样做，您会立即看到问题所在:

public void Configuration(IAppBuilder app)
{
    var x = app.GetDefaultSignInAsAuthenticationType();

    app.SetDefaultSignInAsAuthenticationType(x);
}

第一次调用将为您提供您在第一条评论中提到的异常(exception)情况:

"A default value for SignInAsAuthenticationType was not found in IAppBuilder Properties. This can happen if your authentication middleware are added in the wrong order, or if one is missing."

对 - 因为默认情况下 Microsoft.Owin.Security管道不对您将要使用的中间件做任何假设(即， Microsoft.Owin.Security.Cookies 甚至不知道是否存在)，因此它不知道默认值应该是什么。

使用错误的默认身份验证类型

今天这花费了我很多时间，因为我真的不知道我在做什么:

public void Configuration(IAppBuilder app)
{
    app.SetDefaultSignInAsAuthenticationType("WS-Fed AAD Auth");

    // ... remainder of configuration
}

因此，这将继续尝试在每次调用时使用 WS-Federation 对调用者进行身份验证。并不是说这太贵了，而是 WS-Federation 中间件实际上会针对每个请求发出挑战。所以你永远无法进入，你会看到大量的登录 URL 从你身边飞过。 :P

可能性

因此，在管道中拥有所有这些灵 active 的好处在于，您可以做一些非常酷的事情。例如，我有一个域，其中包含两个不同的 Web 应用程序，在不同的子路径下运行，例如: example.com/foo和 example.com/bar .您可以使用 Owin 的映射功能(如 app.Map(...) 中所示)为每个应用程序设置完全不同的身份验证管道。就我而言，一个使用 WS-Federation，而另一个使用客户端证书。试图在整体中做到这一点 System.Web框架将是可怕的。 :P