0

作成中の新しいアプリケーションで WIF の実験を始めたところです。これまでのところ、LocalSTS を機能させ、web.config をセットアップして、LocalSTS に対するフェデレーション認証を有効にすることができました。私の計画では、当面は LocalSTS を使用し、後でカスタム STS を実装することについて心配します。

フェデレーション認証を使用してユーザーを認証し、認証されたら、内部でさまざまなアクションを実行することを許可します。そのため、STS が認証し、アプリケーションが内部的に承認します。

これを行うには、各ユーザーの許可されたアクション (おそらく数百の固有のアクション) をアプリ データベースに保存し、ユーザーが新しいセッションを開始したときにそれらを読み取ってキャッシュする必要があります。

私が疑問に思っているのは、フェデレーション認証を使用して認証されたユーザーを、自分のデータベースに存在する一意のユーザー ID にマップする方法です。アプリケーションを使用する STS (ADFS、オープン認証など) に依存しないままにします。 ?

nameidentifier トークンは良い候補のようですが、SAML 2 ではそれが別のトークンに置き換えられることを読みました。

私はこれに完全に間違った方法でアプローチしていますか? 私は何かを逃していますか？

どんな助けでも大歓迎です。

4

1 に答える 1

1

名前は良い候補ですが、電子メール、upn、または「固有の番号」でも同様です。ポイントは、究極の候補がいないということです。

あなたの懸念が不可知性のままである場合は、rp の sts を「sts エンドポイントのアドレスと、ユーザーの照合に使用されるクレームのセット」として定義することを検討する必要があると思います。

このように、sts1 は " https://sts1.blah " および "username claim"として定義できますが、sts2 は " https://sts2.blah " および "email" として定義できます。

数年の経験の後、私はそのようなアプローチが唯一の可能性であると考えています。なぜなら、異なるstsesが異なるクレームを提供し、「常に発生することが保証されている1つのクレーム」がないという理由だけです。

そうは言っても、ほとんどの場合、sts は少なくともユーザー名または電子メールを返し、rp はこれを信頼できると想定しています。これにより、rp 側でのユーザーのマッチングが簡素化されます。

于 2013-05-08T22:34:38.153 に答える