.NET4.5フレームワークをAzureAccessControl Service（ACS）と組み合わせて使用するASP.NET MVC 4アプリケーションで、ユーザーに複数の認証の可能性（Google、Facebook、Windows Liveなど）を提供したいと思います。単一のユーザーを複数のIDプロバイダーに関連付けるための「ベストプラクティス」とは何ですか？
たとえば、ユーザーがある日Googleにログインし、翌日別のブラウザにアクセスしてFacebookにログインするとします。Facebookのログインを同じユーザーの以前のGoogleのログインに関連付けるにはどうすればよいですか？
この良い例については、stackoverflow自体をご覧ください。ユーザープロファイルをクリックして、[マイログイン]を選択します。
ユーザーがアカウントを作成するときに、サインインに使用するIDプロバイダーを選択します。内部では、アプリケーションは新しいサイト固有の一意のユーザーIDを作成し、サードパーティが提供する一意のIDとリンクします。（電子メールを使用する場合もありますが、ほとんどのIDプロバイダーは、ユーザーが電子メールを変更しても変更されない一意のユーザーIDクレームも提供します）
これで、ユーザーがサインインした後、他のIDプロバイダーへの追加のリンクを確立できるアカウント管理コントロールパネルが表示されます。
これを達成するための2つのオプションがあります。
MVCアプリケーションにアカウントリンクを永続化させます。ユーザーがサインインすると、サードパーティの一意のIDクレームを使用してアカウントリンクストアにクエリを実行し、サイト固有の一意のユーザーIDを解決します。
ACSルールエンジンを使用します。アカウントリンクごとに1つのルールを作成します。たとえば、Gmailまたはliveidのいずれかでサインインでき、一意のIDが1234であるとします。2つのルールは次のようになります。
google+me@gmail.com->出力ユーザーIDクレーム1234
liveId+me@live.com->出力ユーザーIDクレーム1234
一意のID出力クレームタイプについては、使用可能なクレームタイプから選択するか、独自のクレームタイプを指定できます。ACSには、MVCアプリケーションからプログラムでこれらのルールを作成するために使用できるODataベースの管理サービスがあります。これがコードサンプルです。
ACSを使用している場合は、ACSでクレーム変換を使用して、各IdP（Gogle、Yahoo！、FBなど）からの情報を共通のハンドルに変換できます。人々が使用する一般的なハンドルは、ユーザーの電子メールです。ただし、同じユーザーにマッピングされた多数の電子メールを受け入れたい場合は、独自のIDを（クレームとして）導入し、IdPが提供するクレームをそれにマッピングします。
これはACSAPIを介して自動化できます。また、ユーザーがサイトに初めてログインするときも処理する必要があります（たとえば、ユーザーに電子メールを要求し、マッピングをトリガーする確認メッセージを送信します）。
おそらく、この情報を使用してアプリのローカルデータベースからデータを取得しています。そうでない場合は、クレーム内のすべてをエンコードするだけで、同等性について心配する必要はありません。クレームは、一般的なプロファイルデータをエンコードするのに適した場所であることがよくあります。（例：役割など）