更新时间:2023-12-03 10:12:46
正如@Tratcher 所说,AuthenticationType
参数被 Microsoft.Owin.Security
用作密钥查找身份验证中间件实例.
As @Tratcher said, the AuthenticationType
parameter is used by Microsoft.Owin.Security
as a key to do lookups of authentication middleware instances.
下面的代码将使用以下简单的辅助方法来要求所有请求都经过身份验证.在实践中,您更有可能在敏感控制器上使用 [Authorize]
属性,但我想要一个不依赖任何框架的示例:
The code below will use the following simple helper method to require that all requests are authenticated. In practice you're more likely to use an [Authorize]
attribute on sensitive controllers, but I wanted an example that doesn't rely on any frameworks:
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)
调用将从每个提供的身份验证类型发出身份验证质询.我们将只提供一种,即我们的 WS-Federation 身份验证类型.
The context.Authentication.Challenge(authenticationTypes)
call will issue an authentication challenge from each of the provided authentication types. We're just going to provide the one, our WS-Federation authentication type.
首先,这里是一个***"Owin Startup 配置示例,该示例仅用于像您一样仅使用 WS-Federation 的站点:
So first, here's an example of the "optimal" Owin Startup configuration for a site that's simply using WS-Federation, as you are:
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 服务器作为后备,如果您有该要求.
Note the use of the "WS-Fed Auth (Primary)"
AuthenticationType
to uniquely identify the WS-Federation middleware instance we've configured. This means that you could, for example, use a "WS-Fed Auth (Secondary)"
with a separate WS-Federation server as a fallback, if you had that requirement.
此配置将执行以下操作:
This configuration will do the following:
CookieAuthenticationDefaults
类上的一个常量字符串,它是 CookieAuthenticationOptions.AuthenticationType
属性使用的默认值.)AuthenticationType
键.Microsoft.Owin.Security
方法的自定义帮助程序方法向任何未经身份验证的请求发出质询)CookieAuthenticationDefaults
class, and it's the default value used by the CookieAuthenticationOptions.AuthenticationType
property.)AuthenticationType
key that we set as the default in step 1.Microsoft.Owin.Security
methods for issuing challenges to any unauthenticated request)所以这里有几种方法可能出错.
So there are a couple ways you can go wrong here.
为了实验,我尝试这样做,您会立即看到问题所在:
To experiment, I tried doing this, and you'll see right away what the problem is:
public void Configuration(IAppBuilder app)
{
var x = app.GetDefaultSignInAsAuthenticationType();
app.SetDefaultSignInAsAuthenticationType(x);
}
第一次调用会给你你在第一条评论中提到的例外:
That first call will give you the exception you mentioned in your first comment:
在 IAppBuilder 属性中未找到 SignInAsAuthenticationType 的默认值.如果您的身份验证中间件添加顺序错误,或者缺少某个中间件,就会发生这种情况."
"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
甚至不知道存在),所以它不知道应该是默认值.
Right - because by default the Microsoft.Owin.Security
pipeline doesn't assume anything about the middleware you're going to use (i.e., Microsoft.Owin.Security.Cookies
isn't even known to be present), so it doesn't know what should be the default.
今天这花费了我很多时间,因为我真的不知道我在做什么:
This cost me a lot of time today because I didn't really know what I was doing:
public void Configuration(IAppBuilder app)
{
app.SetDefaultSignInAsAuthenticationType("WS-Fed AAD Auth");
// ... remainder of configuration
}
因此,这将继续尝试在每次调用时使用 WS-Federation 验证调用者.这并不是说太昂贵了,而是 WS-Federation 中间件实际上会发出对每个请求都是一个挑战. 所以你永远无法进入,你会看到一大堆登录 URL 从你身边飞过.:P
So, that's going to keep trying to authenticate the caller with WS-Federation on every call. It's not that that's super-expensive, it's that the WS-Federation middleware will actually issue a challenge on every request. So you can't ever get in, and you see a whole lot of login URLs fly past you. :P
因此,在管道中拥有所有这些灵活性的好处在于,您可以做一些非常酷的事情.例如,我有一个域,其中包含两个不同的 Web 应用程序,在不同的子路径下运行,例如:example.com/foo
和 example.com/bar
.您可以使用 Owin 的映射功能(如在 app.Map(...)
中)为每个应用程序设置完全不同的身份验证管道.就我而言,一个使用 WS-Federation,而另一个使用客户端证书.试图在单一的 System.Web
框架中做到这一点将是可怕的.:P
So what's great about having all this flexibility in the pipeline is that you can do some really cool things. For instance, I have a domain with two different web apps inside of it, running under different subpaths like: example.com/foo
and example.com/bar
. You can use Owin's mapping functionality (as in app.Map(...)
) to set up a totally different authentication pipeline for each of those apps. In my case, one is using WS-Federation, while the other is using client certificates. Trying to do that in the monolithic System.Web
framework would be horrible. :P