ACS（および一般的なクレーム）を使用する場合は、注意する必要があることが1つあります。つまり、クレームを理解する必要があります。
さて、ACS固有の質問に。Windows Azureアクセス制御サービスは、必要な処理を自動的に実行する魔法の杖ではありません。ACSは、クレームを処理し、特定のクレームの1つのセットのみを処理する最も簡単な方法であり、異なるプロトコルのすべての異なる実装を気にする必要はありません。実際、ブラウザベースのアプリケーションを作成するときに使用するのはWS-Federationプロトコル（デフォルトではSAMLトークンですが、SWTトークンも使用できます）であり、OAuthプロトコルではありません。誰かがサイトにログインしたときにACSを使用したときに得られるユーザーの一意性は、次の2つの要素の厳密な組み合わせです。
取得する一意性は、NameIdentifierクレームです（ http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifierで表されます）。
最初のキャッチは、私がhttp://yourcompany.accesscontrol.windows.netを通じてあなたのサイトに識別された「john.doe@gmail.com」であるとすると、名前識別子「X」を取得するということです。同じ「john.doe@gmail.com」がhttp://yourcompany-live.accesscontrol.windows.net/を介して自分のサイトを識別すると、名前識別子「Y」が表示されます。これは、アクセス制御サービスを介してリンクするすべてのIDプロバイダーに当てはまります。
2番目のキャッチは次のとおりです。ライブIDIDプロバイダーは、ACSを介して構成されている場合、NameIdentifierクレームのみを提供します。そしてそれ以上は何もありません。
今質問に：
質問1：リンクする方法は？
IDをリンクする唯一の実行可能な方法は、アプリケーションに独自のリンクロジックを構築することです。私がすることは、自動生成されたすべてのコードとACSへのパッシブリダイレクトの使用を停止することですが、パッシブフェデレーションの一部を手動で処理することです。つまり、ユーザーがログインしているかどうかを確認します。ログインしていない場合は、ユーザーを自分のカスタムログインページにリダイレクトします。このページで、ACSから構成済みのログインオプションを取得します。ユーザーがログインしたら、自分のユーザーデータベースにそのユーザーのエントリを作成します。単一のユーザーにリンクしたいすべての可能なIDプロバイダーのフィールド（またはリンクされたテーブル）があります。理解してください、私はユーザーが持っているかもしれないすべてのNameIdentifiersを保存します。では、ユーザーアカウントをどのようにリンクしますか。さまざまなアプローチがあるかもしれません。初め、ユーザーがアカウントをリンクできるようにするには、ユーザーを特定する必要があります。次に、一意のID（GUIDではなく、ユーザーが簡単に覚えられるようにするため）を使用して「リンケージチケット」を作成します。このIDをユーザーに表示し、別のプロバイダーでログインするオプションをユーザーに提供します（ACSから特権のリストを取得します）。ユーザーが別のプロバイダーに同行する場合-チケットを入力できるタイミングをフィールドに表示します。チケットを確認し、有効かどうかを確認します-既存のアカウントにリンクします。
質問2：システムで識別する方法は？
answe oneで述べたように、独自のカスタムユーザーデータベースが必要です。ユーザーごとに1つのアカウントがありますが、そのアカウントには、さまざまな機関によって発行されたすべてのNameIdentifierクレームが保持されます。したがって、リンクされたアカウントを持つユーザーを一意に識別することができます。
質問3：どのように役割を与えるのですか？Azureの管理ページからではなく、コードを介して提供する
複数のアカウントをリンクする必要がある場合に入力する複雑さのため、アーキテクチャでは、ACSでの役割を維持することは非常に困難です。アプリケーションデータベースでユーザーロールの割り当てを維持することをお勧めします。ローカルユーザーアカウントを持っている部分では、各アカウントに役割を割り当てます。
私がローカルユーザーアカウントと言うとき、私はローカルログイン資格情報をサポートすることを意味するのではなく、ユーザープロファイルだけをサポートすることに注意してください！