現在、ADFS 2.0 を使用する SSO プロジェクトに取り組んでいます。IDP/CP トラストとして。アプリケーション設計に関する基本的な要件の 1 つは、アイドル期間 (何でもかまいません) の後にユーザーを再認証することです。広範な検索の結果、WebSSOlifetime と TokenLifeTimeについて説明している (SharePoint の例を除く) 実装はほとんど見つかりませんでした。ADFS サーバーの設定。WebSSOLifeTime はサーバー全体の設定 (デフォルト値: 480) であり、TokenLifeTime はトークンの有効期限の RP レベル設定 (デフォルト値 0 - 10 時間) であることを理解しています。設定をランダムにテストするために、RP アプリケーションの WebSSOlifetime 値を 5 分に、TokenLifeTime を 3 分に変更しました。ただし、5 分間のアイドル期間 (WebSSOlifetime で設定) の後、再認証はトリガーされませんでした。私がテストした RP アプリケーションには、Google アプリ、ADFS 統合 SSO、およびクレーム値をテストするための単一ページ アプリケーションが含まれます。ADFS 2.0 セッションのメンテナンス機能に関連するポインタを誰かが投稿できれば、それは素晴らしいことです。
1 に答える
汗をかいた後、これに対する解決策を見つけました。Stackoverflow のこの投稿は、私に出発点を提供してくれました (ありがとうございます!)。IP/STS のログイン プロンプトを制御する重要なパラメーターは、フレッシュネス値です (これは、 Oasis のドキュメントに記載されているオプションのパラメーターです)。
このパラメーター (freshness="0" として設定) を web.config の federatedAuthentication セクションに含めると、IDP は WCT パラメーターの現在の時刻に基づいてトークンの鮮度値を確認するように求められます。その後、(多くのテストの後)シェルスクリプトを介して設定された TokenLifeTime が明らかになることがわかりました。これ (TokenLifeTime) は、ログイン画面にリダイレクトする前にユーザーがアクティブでいられる時間を制御します。
リクエスト URL でわかるように:
https://XXX/adfs/ls/?wa=wsignin1.0&wtrealm=https%3a%2f%2fXXX%2fXXX&wfresh=0&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fXXX%252fDefault.aspx&wct=2013-02-14T01%3a36%3a17Z
wfreshとwctxの値は、検証のために IDP に渡されます。
すべて (鮮度、TokenLifetime、および WebSSOLifetime) が舞台裏でどのように同期されているかはまだわかりません。背景についての適切な説明は非常に役立ちます (もちろん、評判がさらに向上します:))。