0

ACSをフェデレーションSTSとして検討しています。独自のカスタムSTSをIP-STSとして構成したり、Facebook、Live、Googleなどの「組み込み」IDプロバイダーとして構成したりできます。しかし、私たちが取り戻す主張はかなり「貧弱」です。ACSでのクレーム変換は、非常に単純なシナリオでのみ役立ちます。
「クレームの欠落」の状況に対処するためのベストプラクティスを探しています。ACSの前に「装飾STS」を配置する必要があると考えています。ACSがセキュリティトークンを持って戻ってきたとき、このデコレータは追加のクレームでセキュリティトークンを「強化」できます。クレームが単に欠落している場合は、ユーザーインターフェイスを表示して、ユーザーにプロファイルを完成させるように(1回)依頼することができます。このように、ユーザーの出身地に関係なく、アプリケーションに必要なクレームがあります。これは良い考えですか?この場合の「ベストプラクティス」とは何ですか?(ACSはプログラムによる拡張を許可していないようです。)

4

2 に答える 2

1

答えは、正確なシナリオに大きく依存すると思います。ACS はプロファイルを管理することを意図したものではありません。したがって、ACS ができること、すべきこと、発信クレームに関しては設計によって多かれ少なかれ制限されています。

サービス ID を管理する場合とは別に、ID プロバイダーから受け取った入力に対してのみ機能し、ユーザー プロファイルなどを管理する権限はありません。

それを念頭に置いて、実際には2つの合理的なオプションしかないと思います.IDを提供してより多くの情報を提供し、ACSを通過して変換するか、アプリケーションがACSを介してIPから基本的なIDを受け取り、その拡張を管理します。プロファイル。

後者についてはこちらに書いています

于 2013-02-09T16:14:19.370 に答える