3

Web アプリと Web API を使用した Azure AD を使用したマルチテナント ソリューションに取り組んでいます。Web アプリは、OpenIdConnect を使用して (Azure Redis Cache にキャッシュされている) ベアラー トークンを取得します。このトークンは、Web API から JSON を取得するために Angular で使用されます。ユーザーの偽装は、Web アプリと Web API (Azure AD アプリケーションで設定) の間で使用されます。

問題：

これは約 1 時間は正常に機能し、その後 Web API 側で ID が突然消えます。Web アプリを更新すると、ページが Microsoft ログイン ページにリダイレクトされていることがわかりますが、ユーザーは Web アプリにリダイレクトされるだけで、すべてが再び機能するため、何もする必要はありません。私が見る限り、Web アプリは失敗したときと更新後 (同じ有効期限) に再び動作するときに同じベアラー トークンを使用します。AuthenticationContext.AcquireTokenSilent は両方のシナリオで機能します。

さまざまなタイムアウトを増やしてみましたが、何も役に立ちませんでした。また、Web API でのベアラー トークン認証以外はすべて無効にしました。ID が消える理由と、クライアントの更新に役立つ理由がわかりません。何か案は？:)

追加情報

これは、(Web API での) ログインまたは更新の約 1 時間後に RequestContext.Principal.Identity がどのように見えるかを示しています。

ここに画像の説明を入力

そして、これは約 1 時間後です。これにより、認証が失敗します。

ここに画像の説明を入力

私が試したコードの変更のいくつか:

Web API HttpConfiguration で:

config.SuppressDefaultHostAuthentication();
        config.Filters.Add(
            new HostAuthenticationFilter(
                new WindowsAzureActiveDirectoryBearerAuthenticationOptions().AuthenticationType));

これにより、認証されていないプリンシパルが WindowsPrincipal から ClaimsPrincipal に変更されましたが、1 時間後にも失敗します。

WindowsAzureActiveDirectoryBearerAuthenticationOptions BackChannelTimeout set to 5 days. Still fails

Web アプリ web.config で:

sessionState timeout="525600" for RedisSessionStateProvider. Still fails

Web アプリの認証プロセスで、タイムスパンが増加し、スライド式の有効期限が追加されました。それでも失敗します：

app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
        app.UseCookieAuthentication(new CookieAuthenticationOptions
        {
            CookieSecure = CookieSecureOption.Always,
            ExpireTimeSpan = TimeSpan.FromDays(5),
            SlidingExpiration = true,
            CookieHttpOnly = true
        });
        app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                ClientId = ClientId,
                Authority = Constants.CommonAuthority,
                UseTokenLifetime = false

アップデート：

いくつかの詳細を具体化するには: ハイブリッド MVC Angular Web アプリケーションがあります。それぞれがそのメニュー項目のAngular「シングルページアプリケーション」につながる多くのMVCメニュー項目。MVC は、ルーティング、認証、承認に使用されます。さらに、追加のクレームが取得され、現在のプリンシパル サーバー側に追加されます。メニュー項目は、Authorized および ClaimsPrincipalPermission 属性で保護されている MVC コントローラーです。Web ページは Azure で実行されるため、既定の sessionProvider を Microsoft.Web.Redis.RedisSessionStateProvider に変更しました。MVC サーバー側のみがこの redis セッション キャッシュと通信します。ベアラー トークン (リフレッシュ トークンではない) は、認可された保護された MVC コントローラーを介して Angular と共有され、ブラウザー セッション ストレージに格納されます (adal. js は localstorage を使用しますか?) Angular は、MVC アプリとは別のドメインにある CORS 対応 API から JSON コンテンツを取得します。API と MVC アプリも、2 つの異なる Azure AD アプリケーションに属しています。

4

1 に答える 1

2

ここでフローを渡っているようです。JavaScript から呼び出しを行っている場合は、クライアントでトークンを取得する必要があります ( http://www.cloudidentity.com/blog/2014/10/28/adal-javascript-and-angularjs-deep-dive/など) 。結果が Cookie であるリダイレクト ベースの認証フローは、JavaScript を介して API を呼び出すシナリオにはあまり適していません。さらに、私の理解が正しければ、プライベート クライアントとしてトークンを取得し、それを帯域外 (redis キャッシュ) で、ユーザー エージェント内で実行されているパブリック クライアントと共有しています。これはセキュリティの観点から見ても仕方のないことです。

とはいえ、現在のルートに本当に追いつく準備ができている場合は、http: //www.cloudidentity.com/blog/2014/04/28/use-owin-azure-ad-to をご覧になることをお勧めします。 -secure-both-mvc-ux-and-web-api-in-the-same-project/により、Web UX と Web API ルートを完全に分離できます。

于 2014-11-25T22:16:47.173 に答える