0

ご存じのとおり、B2B 機能を使用するマルチテナント Azure アプリケーションを作成しています。

私は B2B 機能をテストしており、いくつかの調査の後、実際のサンプルを入手しました。

簡単な要約: ユーザーは共通機関に対して認証を行います。最初のトークンは、認証コードを使用して共通機関を介して取得されます。それ以降、サービス クライアントが必要になるたびに、「現在のテナント」機関からそれらのトークンを取得しようとします。

「私」をリクエストすると、ホーム テナントに対してのみ機能します。信頼できるテナントを要求すると、ユーザー識別子がディレクトリに存在しないというエラーが表示されました。おそらく、信頼されたテナントにユーザーが実際に存在しないためです。

ユーザーをリクエストすると、正常に動作します。ホーム テナント ユーザーと信頼できるテナント ユーザーの両方を取得できます。

これは正常な動作ですか？これはプログラムで処理する必要があるものですか、それとも AD グラフを使用することで解決されますか? (つまり、ユーザー情報が必要なことがわかっている場合は、ホーム テナントにクエリを実行するだけですか?) それとも、これはバグですか?

これについての考えは大歓迎です！

4

2 に答える 2

0

テナントを切り替えたい場合、現在のテナントに対して再認証する必要があることに気付きました。1. 最初のサインインは、共通のエンドポイントに対して行う必要があります。2. 特定のリソースのトークンが必要になるたびに、静かにトークンを取得しようとします。

=> これにより、2 つの異なる AdalSilentTokenAcquisitionException がスローされる可能性があります

  • キャッシュに何も見つからず、更新トークンも見つからない => この場合、ユーザーを再度ログイン ページにリダイレクトします。
  • テナントを切り替えるときに、信頼されているテナントを使用して初めてログインしようとすると、次のようなエラーが発生する可能性があります: ユーザーまたは管理者は、このアプリケーションに同意する必要があります。ホーム テナントの管理者はホーム テナントのディレクトリにアプリケーションを追加しましたが。この同意が必要な理由を知っている人はいますか? したがって、テナント A とテナント B の管理者の両方に同意が与えられています。A の B からの信頼できるユーザーが何らかの形で同意する必要があるのはなぜですか?

ユーザーを認可リクエスト URL にリダイレクトすることで、同意フローをトリガーすることができました。したがって、AdalSilentTokenAcquisitionException を取得し、エラー コードが「failed_to_acquire_token_silently」の場合、キャッシュがクリアされたときに authContext (authenticationContext.GetAuthorizationRequestUrlAsync) によって生成された URL にユーザーをリダイレクトする必要があり、リフレッシュ トークンが見つからず、リダイレクトします。ユーザーが辞任します。

于 2016-11-21T08:49:41.603 に答える
0

共通のエンドポイントを使用している場合、B2B コラボレーション機能を介してディレクトリに追加されたゲストは、マルチテナント アプリまたは Microsoft Graph で正しく機能しません。

共通エンドポイントは、ユーザーがゲストであるテナントに対してではなく、常にホーム テナントに対してユーザーを認証します。

ゲストの /me を正常にクエリするには、ゲストであるテナントのテナント固有のエンドポイントを介してサインインさせる必要があります。

より詳細な説明/コンテキストについては、この他の投稿に対する私の回答を参照してください: 管理されていない Azure AD ディレクトリのユーザーは、別のディレクトリにある Azure AD マルチテナント アプリケーションにサインインできますか?

于 2016-11-20T08:19:10.857 に答える