そのため、スタックとナゲット パッケージを利用したソリューションOkta
をアプリケーションに統合しました。全体的にうまく機能しているように見えますが、authorize 属性がミックスに追加されると問題が発生します。カスタム認証属性は、文字列パラメーターを介して提供されるアクセス許可用に設計されたとおりに機能しますが、. この 401 はグローバルに監視されているようです。サインインするためにカスタム コンポーネントをヒットしたことはありません (つまり、Okta にリダイレクトします) 。私が読んだすべての投稿は、これに従うことを示していますSSO
OWIN
Microsoft.Owin.Security.WsFederation
WebApi
401 response
OWIN middleware
302
Okta
Brock Allen によるブログ投稿ですが、前述したように、リダイレクトによってこのコードがトリガーされることはありません。Angular Interceptor を構築することを考えましたが、そのアプローチがまったく好きではないので、403 (Forbidden)
今のところAuthorize
属性から a を返すことにしました。これは理想的ではありませんが、実行可能です。 このSO 投稿は、この問題に関する主な議論のようですが、そこでのアドバイスに従うことはできませんでした。これまでに使用されているミドルウェア コードは次のとおりです。/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);