次のような適切な例はありますか?
見渡すWIF SDK についてWSFederationAuthenticationModule (FAM)、 ASP.NETサイトにリダイレクトするためにWIFをASP.NETと組み合わせて使用する例があります。薄い皮膚ユーザーが認証に使用するセキュリティ トークン サービス (STS) の上にあります (ユーザー名とパスワードの入力による)。
WIF とクレーム ベースのアクセスを正しく理解していれば、アプリケーションで独自のログイン画面を提供して、ユーザーがユーザー名とパスワードを入力し、認証を STS に委任して、ログインの詳細をセキュリティ標準 (WS-*) 経由でエンドポイントに送信し、SAML トークンが返されることを期待したいと思います。理想的には、 をと組み合わせてSessionAuthenticationModule使用して例のように動作し、つまり、セキュリティ セッションの有効期限が切れたときに、がセッション セキュリティ チャンク クッキーから を再構築し、アプリケーションのログイン ページにリダイレクトする役割を担うことになります。FAMSessionAuthenticationModuleIClaimsPrincipal
私が説明したことは、適切な web.config 設定を使用して実行できるのでしょうかFAM、SessionAuthenticationModuleそれともこれを処理するために自分で書くことを検討する必要がありますかHttpModule? あるいは、受動的なリクエスター シナリオでは、ユーザーがログインする薄い Web サイト STS にリダイレクトするのが事実上のアプローチでしょうか?
ベストアンサー1
WIF + MVC の例は、「クレーム ID ガイド」のこの章で参照できます。
http://msdn.microsoft.com/en-us/library/ff359105.aspx
すべての基本原則を理解するために、最初の数章を読むことをお勧めします。このブログ投稿では、MVC + WIF の詳細について説明します。
ログイン エクスペリエンスを制御することはまったく問題ありません。独自の STS (自分のドメイン、自分のルック アンド フィールなど) を展開するだけです。アプリは AuthN をそれに依存するだけです (アプリが通常「証明書利用者」と呼ばれるのはそのためです)。
このアーキテクチャの利点は、認証が 1 つのコンポーネント (STS) に委任され、多くのアプリに分散されないことです。しかし、もう 1 つの (大きな) 利点は、より高度なシナリオを非常に簡単に実現できることです。たとえば、他の組織の ID プロバイダーと連携できるようになりました。
エウジェニオの助けになれば幸いです
@希望の星：
トークン (クレームを含む) はオプションで暗号化できます (暗号化しない場合はクリア テキストになります)。このため、ブラウザーと STS 間のやり取りには常に SSL が推奨されます。
トークンはデジタル署名されているため、平文であっても改ざんは不可能であることに注意してください。