AzureのAD SSOマルチテナントアプリケーション/ AD FSクレームプロバイダーの問題

Question

いくつかの背景：（SPとして作用する）

私の会社は現在、AD FS 2.0通じ、当社のフェデレーションパートナー（IdPの）でSSOを処理します。各パートナーはクレームプロバイダとして設定され、Webアプリケーションに送信される着信クレームを変換するためのルールが作成されます。

クレームを含むトークンはSTSエンドポイント（たとえばhttps://sts.companyname.ca/adfs/ls）に送信され、クレームが変換されてWebアプリケーションのURL（https://companyname.ca/externalsignin.aspx）に送信され、アカウントの検索/作成に先立つOWINミドルウェアによって処理されます。

これは完全に機能します。これで、Azure AD SSOをミックスに統合して、オンボード処理を簡単にすることができます。

私は、Azureで新しいディレクトリを作成して、新しいアプリケーションを作成しています。私はアプリケーションをマルチテナントとしてマークし、返信URLを "https://sts.companyname.ca/adfs/ls"に設定しました。私のサーバー上のAD FS 2.0クライアントでは、「AzureAD」という新しいクレームプロバイダを作成し、Azureコンソールのアプリケーションのエンドポイントセクションからmetadataurlをインポートしました。私たちのテナントからの電子メールでログインをテストすることは完全に働いていました。これがlogin.microsoftonlineのために構築されたログインフォームによるものであったと思われるいくつかの研究の後

：問題は、他のテナントからの組織の電子メールでのテスト、認証が悪い要求メッセージで失敗したときにあります。 com/tenantidの場合はlogin.microsoftonline.com/commonをマルチテナントアプリに使用する必要があります。そこで、https://login.microsoftonline.com/common/federationmetadata/2007-06/federationmetadata.xmlのメタデータを再インポートして更新しました。

他のテナント組織アカウントでログインすると実際に同意を求めることができますが、認証後にsts.companyname.ca/adfs/lsへの投稿は失敗します。その理由は、トークンが "sts.windows .net/0000-000000-000000-0000 "と表示されますが、AD FSのクレームプロバイダはsts.windows.net/{tenantid}プレースホルダによって識別されます。

テンプレート付きエンドポイントを持つ単一のAzureクレームプロバイダー（これはすべて同じ署名証明書を使用しているため、1つの匿名クレームプロバイダーのみを追加することができます）のみでこの作業を行う方法はわかりません。

この障害を克服する助けがあれば幸いです。

Answer 1

Azure ADがトークン（同じ署名キーでも異なるテナント発行者）を同じ署名鍵で複数のクレームプロバイダーの信頼を許可しないADFSの制約で発行する方法でインピーダンスが不一致であるため、これは機能しません。

これを行う方法は、次のいずれかです。

1. 使用アズールあなたのAzure ADテナントに一の以上のAzure ADテナントからのゲストを招待して、一つとして、あなたのテナントにADFSをフックするためのAD B2B CPの信頼。
2. ADFS 2016では、Azure ADの各テナントをクレーム受領/増補に関するさまざまなポリシー/ルールとは別のCPトラストとして扱うよう依頼しました。このために、Azureの各ADテナントをユニークなCPの信頼としてモデル化することができます。

あなたの質問にお答えします。

おかげ //サム（@MrADFS）