1

現在、ユーザーを認証するために独自のSTS(Microsoft WIF)を実装することを検討しています。その過程で、答えることができなかったいくつかの質問が出てきました。

さまざまな種類のアプリケーションを使用して、さまざまな種類のユーザーがいます。各種類のユーザーには、その種類のユーザーと所属するアプリケーションにのみ関連する特別な種類のクレームが必要です。すべてのクライアントを管理しているわけではないことに注意してください。

すべてのユーザーが、ユーザー名とパスワード(.NET MVC3)を使用した単純なhttpsを使用して認証されているとします。ユーザーは、そのタイプ、ユーザー名、およびパスワード(ユーザー名とパスワードだけではない)によって一意に識別されます。したがって、ユーザータイプを区別できるように、ユーザータイプごとにエンドポイントを作成する必要があります。ユーザーが承認すると、ユーザータイプを表すクレームを含むトークンを発行します。これを行うためのより簡単な方法はありますか?ユーザータイプごとにエンドポイントを回避できますか(現在は3つあります)?

次に、私のトークンサービスは、許可されたユーザーのトークンを調べてクレームを変換し、すべてのユーザーのタイプ固有のクレームを含むトークンを発行できます。私が思う複数のエンドポイントを除いて、これまでのところ良いですか?

複数のエンドポイントが必要な場合、エンドポイントごとに1つずつ、異なるメタデータドキュメントも公開する必要がありますか?すべてのクレームの説明を含む1つの大きなメタデータドキュメントがあると、すべてのクレームを必要とするアプリケーションがないため、意味がありません。

アップデート

いくつかの説明。

特定のアプリケーションは、特定のタイプのユーザーのみが使用します。1つのアプリケーションを複数のユーザータイプで使用することはできません。

リクエストの送信元のアプリケーションの種類に応じて、そのユーザーの種類についてユーザー名とパスワードを比較する必要があります。アプリケーションの種類ごとにユーザーストアがあります。そのため、リクエストの送信元のアプリケーションの種類を知る必要があります。ユーザー名とパスワードだけではタイプを解決できません。

4

2 に答える 2

1

問題の説明に基づくと、3つの独立したユーザー「リポジトリ」(ユーザータイプごとに1つ)があるようです。

したがって、これは3つのSTSまたは複数のエンドポイントを持つSTSの有効なシナリオになります。

これを解決する別の方法は、ユーザーをstsにリダイレクトする応答側の識別子によってユーザータイプを区別することです。この識別子はwtrealmパラメータで送信されます。

処理シーケンスは次のようになります。

  1. 構成ストアから証明書利用者(wtrealm)の構成を取得します(かなり複雑なケースのデータベースをお勧めします)
  2. ユーザー名、パスワード、およびユーザータイプ(証明書利用者の設定から)を使用してユーザーを検証します
  3. ユーザータイプまたは証明書利用者固有の構成に応じてクレームを追加します。

このためのデータベース/クラス構造は、これに似ているように見える可能性があります。 複数のユーザータイプのSTS

于 2011-11-23T15:37:21.410 に答える
0

答えるにはさらに情報が必要です:

特定のアプリケーションは特定のタイプのユーザーのみが使用しますか?または、任意のユーザータイプが任意のアプリケーションにアクセスできますか?前者の場合、そのユーザータイプをクレームとして渡すようにそのアプリケーションのSTSを構成できます。各アプリケーションは、独自のクレームのサブセットを持つように構成できます。

ユーザータイプはどこから派生していますか?リポジトリからの場合、それに対するクレームを単純に作成することはできませんか?

アップデート:

@Peterのソリューションは機能するはずです。

に関して。3つのSTSと3つのエンドポイント、

多くのSTS-異なる「コードビハインド」で同じ標準エンドポイントを使用できます。すぐに使用できるソリューションに移行した場合でも機能します。証明書更新のための追加作業。

1つのSTS-カスタムエンドポイントは移行できません。証明書の更新のために更新するSTSは1つだけです。

メタデータ-動的に生成できることを考えると、実際には重要ではありません。フェデレーションメタデータの動的な生成を参照してください。

于 2011-11-22T22:54:34.237 に答える