現在、ユーザーが認証されている場合(SWTトークンに対してWIFが有効になっているAzure ACSを介して)、新しいプロバイダーで再度サインインして2つのトークンを取得できるようには見えません。
ユーザーが2つのアカウントをリンクできるパターンを探していますか?
現在、ユーザーが認証されている場合(SWTトークンに対してWIFが有効になっているAzure ACSを介して)、新しいプロバイダーで再度サインインして2つのトークンを取得できるようには見えません。
ユーザーが2つのアカウントをリンクできるパターンを探していますか?
もう少し説明する必要があります。これはウェブサイトですか?(質問に「MVC」のタグを付けたので、はいと仮定します)。どのプロバイダーを使用していますか?(例:FB、LiveID、Google、独自のもの)。アプリはどのようにユーザーを識別していますか?(例:一意のハンドル、電子メールアドレスなど)。
取得するトークンは常にACSからのものであり、プロバイダーから独立しています。実際にACSを使用して、すべての異なるプロバイダーからの情報を共通のものに正規化できます。したがって、それらの2つを「リンク」します。これは、ACS変換ルールを使用して行います。
「パススルー」ルールを使用すると、IdPが提供するものはすべて取得され、関連付けはアプリで行われる必要があります。
ID プロバイダーに従って、プロバイダーごとに一意の「名前識別子」を取得します。それらをリポジトリに保存して、手動でリンクする必要があります。
例えば
アップデート:
通常の SQL メンバーシップ プロバイダーのような「コントロール」ID が必要です。したがって、最初にこの ID としてログインします。次に、「別の ID を使用しますか?」と尋ねるワークフローがあります。コントロール ID がわかっているので、新しい「名前識別子」をコントロール ID にマップします。ACS ID の 1 つを使用してログインする場合は、リポジトリを検索します。見つからない場合。「この ID は以前に見たことがありません。コントロールとしてログインしてからマップしてください」と言います。