私はAzureACSで遊んでいて、その非常にクールで、次のプロジェクトで使用するつもりだと思います。
私が持っている1つの質問は、ClaimsIdentityを取り戻すときに、電子メールと名前だけでかなり空になっていることです。これは仕様によるものですか?
これでより多くの情報を得ることが可能ですか?ユーザーが持っているアバターをサービスに利用できることを本当に望んでいました。
どんな助けでも素晴らしいでしょう。
乾杯。ste。
私はAzureACSで遊んでいて、その非常にクールで、次のプロジェクトで使用するつもりだと思います。
私が持っている1つの質問は、ClaimsIdentityを取り戻すときに、電子メールと名前だけでかなり空になっていることです。これは仕様によるものですか?
これでより多くの情報を得ることが可能ですか?ユーザーが持っているアバターをサービスに利用できることを本当に望んでいました。
どんな助けでも素晴らしいでしょう。
乾杯。ste。
返されるクレームは、ほとんどIDプロバイダーの裁量によるものです。それぞれが異なるクレームを返すことができます(各IDプロバイダーが返すものの詳細については、http://msdn.microsoft.com/en-us/library/windowsazure/gg185971.aspxを参照してください)。すべてのIDプロバイダーから返される「NameIdentifier」および「IdentityProvider」クレームのみを取得することが保証されています。
http://msdn.microsoft.com/en-us/library/windowsazure/gg185933.aspxでさらに役立つ情報。
@mcollierが書いたように、提供されるクレームは通常、IdPの提供内容に依存します。ただし、ACSでセキュリティトークンを強化し、任意のクレームを追加することができます。次のようなルールを作成できます。
「誰かがemail=someone@gmail.comでGoogleで認証するとき、バリューマネージャーでタイプロールの申し立てを発行します」
したがって、このようなルールに何でも(アバターを含む)追加できます。
ACSは本質的に、任意のIdPからのトークン内のクレームをアプリが理解できるものに変換するクレームの「ノーマライザー」です。
管理下にあるIdP(たとえば、独自のADFSサーバーまたは会社のサードパーティIdP)は、追加のクレームを提供する可能性があることに注意してください。通常は制限されているのは事前にプロビジョニングされたものです(たとえば、電子メール、名前、ID)。
変換ルールは、ACSポータル、API、またはAuth10などのサードパーティツール(APIを使用)を使用して自分で定義できます。