私は Azure Access Control Service (ACS) を調査してきましたが、異種の (構成可能な) ID プロバイダーからの認証の処理に特に優れているようです。次に、サポートされていると思われる追加のシナリオがいくつかあります (たとえば、ACS のハウツーを参照してください)。
私が持っている質問は反対です.ACSを適切に使用するために、ACSが何に適していないかを理解するのに本当に役立ちます. ACS の制限は何ですか? また、ACS が不適切なシナリオは何ですか?
(議論のために、私が作成することを計画していると仮定します-収益性:)-AzureでホストされているパブリックWeb APIと対応するWebサイトフロントエンド-つまり、私はユーザーIDを気にかけています。必要に応じて、私のシステムが .NET を使用して構築されるとさらに想定することもできます。)
ありがとう！
ACSをIDプロバイダーとして使用しないでください。
ときどき、ACSがどのような役割を果たしているのか混乱することがあります。ACS at is coreはフェデレーションプロバイダーですが、バックエンドサービス（信頼できるサブシステム）が共有シークレットまたは証明書を使用してACSに対して直接認証するという有効なシナリオがあります。これは、サービスIDを使用して実行できます。ただし、複数のアカウントをプロビジョニングするACSシナリオが提案されているのを何度も見たことがあります。これは、ユーザーごとにサービスIDを作成することで実現されます。
それは実際にはACSが設計されている方法ではありません。突然数千人のユーザーがいる場合、ACSを信頼できるソースユーザーディレクトリに拡張することはできません。ACSは、さまざまなIDプロバイダーからの着信クレームタイプを正規化するため、またはロールクレームの生成などの単純な承認ポリシーのために設計された優れたルールエンジンを提供します。
ただし、ここでのACSの機能を、ADやADFSなどのフルパワーのディレクトリ、認証、および承認ソリューションと混同しないでください。つまり、ACSはAD/ADFSの可能なバージョンではありません。
Windows Live を ACS の ID プロバイダーとして使用できますが、使用したくない場合もあります。受け取るユーザー ID は、ACS ネームスペースによって異なります。これは、アプリケーションが複数の ACS 名前空間を使用している場合 (ヨーロッパ用に 1 つ、米国用に 1 つなど)、問題が発生する可能性があることを意味します。
ユーザーが USA 名前空間を介してログインするシナリオを想像してください。アプリケーションはそのユーザーの ID (ハッシュ) を受け取り、アプリケーションでそのユーザーのプロファイルを作成する場合があります。1 週間後、ユーザーはヨーロッパに旅行し、ヨーロッパの名前空間を介してログインする可能性があります。これは同じユーザーですが、そのユーザーの別の ID (ハッシュ) を取得し、そうではないにもかかわらず、これが新しいユーザーであるように見せかけます。これは、ID (ハッシュ) が ACS 名前空間に依存するためです。
ACS for Windows Live ID から受け取るユーザ ID は、サービス ネームスペースのそのユーザに固有のものです。別のサービス名前空間を使用すると、同じユーザーに対して別の値が取得されます。ご質問にお答えします: * Labs ACS と Prod ACS [異なる ID]
異なるサブスクリプション (本番環境) の異なる証明書利用者 [異なる ID]
同じサブスクリプション内の異なる RP [サービスの名前空間が同じ場合は同じ ID、同じサブスクリプション内の 2 つの名前空間では異なる]
RP を削除して再構築すると、同じレルム、同じアカウント [同じ ID]
アップデート：
コメントの 1 つに返信するには、Windows Live ID プロバイダーから電子メール アドレスを取得できないのは事実です。ただし、パブリック ID プロバイダーから取得する情報を制御できないと想定する必要があります。ユーザーの識別子に基づいて、ユーザーのプロファイルを作成することをお勧めします (アプリケーションでプロファイルを管理します)。ID プロバイダーから何らかの情報を取得したら、既にプロファイルを更新できますが、この情報が利用できない場合は、単にユーザーにプロファイルを更新するように依頼する必要があります。詳細については、BlobShareの例を参照してください。