0

私は最近WIFをよく研究していますが、いくつかの詳細についてはまだかなり混乱しています。ADFSを使用している場合、それは素晴らしいことだと理解していますが、それは私のシナリオではありません。私の組織内には、少なくとも3つの主要なセキュリティシステムがあります。私は会社にすべての内部用途にADを使用させようとしましたが、それは実現しません。統一されたプログラミングモデルを作成するために、認証/承認のために追加のSTSを構築することを検討しました。

  1. これは本当に賢明ですか?私が読んだもののほとんどは、ADFSを使用するだけだと言っています。そうでない場合は、気にしないでください。カスタムSTSを作成するプロセスが難しい場合、統合クレームモデルにWIFを使用する価値はありますか?

  2. すべてのユーザーがマップ先のADログインを持っているわけではない場合はどうしますか。たとえば、個人アカウントで実際にマシンにログインすることのない季節限定の従業員がたくさんいます。マシンは上司によって午前中にログインされ、従業員は自分のバッジをスキャンし、従業員IDが使用されます。

  3. 少なくとも3つの異なるユーザーセットがコードベースにアクセスする新しいアプリケーションを作成しています。1つのグループは内部(ADを使用)であり、他の2つはおそらくasp.netのデフォルトメンバーシップを使用します(わかりました。2つの異なるユーザーストアのセットです)。WIFを使用して承認/認証を統合できるようにしたいと思いますが、WIFでは反対方向に進みたいようです。それは認証を強調せず、多くの場合それが主な関心事である場合、それがすべて良いと仮定します。このシナリオでWIFを活用するにはどうすればよいですか?

私はこの記事を読んでみました:

http://msdn.microsoft.com/en-us/library/ff359105.aspx

そして私はStarterSTSについて読みましたが、それでももう少し読む必要があります。StarterSTSの作者のビデオも見ました。私は本当にすべてをまとめることに失敗しています。WIFは私には役に立たないように感じますが、私が本当に求めているのは認証と承認の統一されたモデルであるため、そうすべきだと思います。ありがとう

4

1 に答える 1

1

必要なものは、Federated Identity モデルに似ています。アプリケーションのクレームを正規化する Federated STS (StarterSTS など) を構築できます。次に、ACS / AD FS V2 などを使用して、これらの ID プロバイダーをフェデレートできます。クレーム ベース ID ガイドを読むことも、良い出発点です。クレームをアプリケーションで有効にすると、さらに多くの ID プロバイダーを追加し、フェデレーション プロバイダーを使用してクレームを制御し、ルールを設定できます。

CodePlexで新しいバージョンのガイド(ドキュメントとコード) をリリースし、制作プロセスを進めています。

于 2011-06-09T22:14:54.747 に答える