Microsoft.Owin.Security.WsFederation 自定义授权属性 API 重定向
Microsoft.Owin.Security.WsFederation Custom Authorize Attribute API Redirect
因此,我们已将 Okta
集成到我们的应用程序中,以利用 OWIN
堆栈和 Microsoft.Owin.Security.WsFederation
nuget 包作为 SSO
解决方案。它总体上似乎运行良好,但是当将 WebApi
的授权属性添加到混合中时,我们遇到了问题。自定义授权属性按照为通过字符串参数提供的权限设计的方式工作,但是问题似乎出现在返回 401 response
的默认行为中。似乎这个 401 在全球范围内受到监视,因为我从来没有点击我的自定义 OWIN middleware
组件登录(即:重新定向到 Okta),但当 302
是时,API 请求仍然失败返回触发重定向到 Okta
。我读过的每个 post 都表明要遵循 this blog post by Brock Allen, however as I mentioned the re-direct never triggers this code. I thought about building an Angular Interceptor but I don't like that approach at all, so I went with returning a 403 (Forbidden)
for now from the Authorize
attribute, which isn't ideal but is workable. This 所以 post 似乎是关于这个问题的主要讨论,但我没有按照那里的建议走运。这是到目前为止使用的中间件代码,有没有人对如何排除 /api 路由被重定向到 Okta 有任何想法或想法?
var fileSystem = new PhysicalFileSystem(@".\wwwroot");
var options = new FileServerOptions()
{
FileSystem = fileSystem,
EnableDefaultFiles = true,
EnableDirectoryBrowsing = true,
};
app.SetDefaultSignInAsAuthenticationType(WsFederationAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(
new CookieAuthenticationOptions
{
AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType,
});
app.UseWsFederationAuthentication(
new WsFederationAuthenticationOptions
{
MetadataAddress = ConfigurationManager.AppSettings["MetadataAddress"],
Wtrealm = ConfigurationManager.AppSettings["Wtrealm"],
TokenValidationParameters =
{
ValidAudience = ConfigurationManager.AppSettings["ValidAudience"]
}
});
app.Map("/api", x =>
{
dependencyResolver = x.UseApi();
});
app.UseFileServer(options);
我建议看一下 http://www.cloudidentity.com/blog/2014/04/28/use-owin-azure-ad-to-secure-both-mvc-ux-and-web-api-in-the-same-project/ - post 是关于 OIDC 的,但也应该适用于 wsfed。
因此,我们已将 Okta
集成到我们的应用程序中,以利用 OWIN
堆栈和 Microsoft.Owin.Security.WsFederation
nuget 包作为 SSO
解决方案。它总体上似乎运行良好,但是当将 WebApi
的授权属性添加到混合中时,我们遇到了问题。自定义授权属性按照为通过字符串参数提供的权限设计的方式工作,但是问题似乎出现在返回 401 response
的默认行为中。似乎这个 401 在全球范围内受到监视,因为我从来没有点击我的自定义 OWIN middleware
组件登录(即:重新定向到 Okta),但当 302
是时,API 请求仍然失败返回触发重定向到 Okta
。我读过的每个 post 都表明要遵循 this blog post by Brock Allen, however as I mentioned the re-direct never triggers this code. I thought about building an Angular Interceptor but I don't like that approach at all, so I went with returning a 403 (Forbidden)
for now from the Authorize
attribute, which isn't ideal but is workable. This 所以 post 似乎是关于这个问题的主要讨论,但我没有按照那里的建议走运。这是到目前为止使用的中间件代码,有没有人对如何排除 /api 路由被重定向到 Okta 有任何想法或想法?
var fileSystem = new PhysicalFileSystem(@".\wwwroot");
var options = new FileServerOptions()
{
FileSystem = fileSystem,
EnableDefaultFiles = true,
EnableDirectoryBrowsing = true,
};
app.SetDefaultSignInAsAuthenticationType(WsFederationAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(
new CookieAuthenticationOptions
{
AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType,
});
app.UseWsFederationAuthentication(
new WsFederationAuthenticationOptions
{
MetadataAddress = ConfigurationManager.AppSettings["MetadataAddress"],
Wtrealm = ConfigurationManager.AppSettings["Wtrealm"],
TokenValidationParameters =
{
ValidAudience = ConfigurationManager.AppSettings["ValidAudience"]
}
});
app.Map("/api", x =>
{
dependencyResolver = x.UseApi();
});
app.UseFileServer(options);
我建议看一下 http://www.cloudidentity.com/blog/2014/04/28/use-owin-azure-ad-to-secure-both-mvc-ux-and-web-api-in-the-same-project/ - post 是关于 OIDC 的,但也应该适用于 wsfed。