ADFS 2.0 タイムアウト シナリオでの Freshness Value、TokenLifetime、および WebSSOLifetime パラメータの関係を知りたいです。私はすでにこれについて少し分析を行っていますが、まだ明確な全体像を把握していません。
1 に答える
いくつかの情報源から ADFS タイムアウトに関する以下の詳細を収集しました。
ADFS 構成に関係する 2 つの主要なタイムアウトがあります。
- WebSSOLifetime – サーバー全体のタイムアウト パラメータ – デフォルト値 = 480 分
- TokenLifetime – これは Relying party ごとに設定されます – デフォルト値 = 10 時間
WebSSO ライフタイム:
これは、すべての RP (Relying Party) に適用されるサーバー全体の設定です。ユーザーが特定の RP のトークンを要求するときはいつでも、最初に ADFS サービスに対して認証する必要があります。ADFS サービスと通信すると、彼は 2 つのトークンを受け取ります。彼が誰であるかを証明するトークン (ADFS トークンと呼びましょう) と RP のトークン (RP トークンとしましょう) です。WebSSOLifetime タイムアウトにより、ADFS トークンを使用して新しい RP トークンを再認証することなく要求できる期間が決まります。つまり、ユーザーはこの RP または他の RP の新しいトークンを要求でき、WebSSOLifetime が ADFS トークンを期限切れにするまで、自分が誰であるかを証明する必要はありません。
トークンの有効期間:
これは、特定の RP に適用される RP レベルの設定です。ADFS サーバーで構成されている他の RP には影響しません。ユーザーが RP トークンを受け取ると、いつでも失効します。その時点で、ユーザーは ADFS サーバーに再度アクセスして、新しい RP トークンを要求する必要があります。ADFS トークンがまだ有効かどうかに応じて、再認証する必要はありません。
TokenLifetime を下げる理由の 1 つは、クレームをより速く更新することです。デフォルトでは、属性ストア情報の一部が変更されるたびに、この変更がクレームでユーザーに届くまでに 10 時間かかる可能性があります。以下の手順を使用して、シェル スクリプトを介して TokenLifetime を設定できます。
• 管理者モードで PowerShell を起動し、コマンドを実行します。
“Add-PSSnapin Microsoft.Adfs.Powershell”
• 次のコマンドを使用して、アプリケーションの構成の詳細を取得します。
Get-ADFSRelyingPartyTrust -「ADFS 証明書利用者信頼でのアプリの表示名」に名前を付けます</p>
• 次のコマンドを使用して、ADFS 設定の TokenLifeTime 値を必要な値に変更します。
set-ADFSRelyingPartyTrust -Targetname "ADFS 証明書利用者信頼でのアプリの表示名" -TokenLifetime "分単位の値"
これにより、指定された期間が経過すると RP トークンが無効になります。
上記の設定では、ユーザーに再認証を促すために、WebSSOLifetime を TokenLifetime よりも低くする必要があります。
RP ごとに再認証タイムアウト要件が異なるシナリオを想像してください。他の RP のサーバー レベル WebSSOLifetime が 50 分に設定されている場合、RP が 10 分 (TokenLifetime を 10 に設定) 後にユーザーに再認証することを望んでいるとします。この場合、ユーザーは ADFS 認証ページにリダイレクトされません。代わりに、ユーザーは認証なしで新しいセッションを作成されます。これは、RP レベルのトークンの有効期限が切れていても、WebSSO トークンがまだ有効であるためです。
鮮度値:
このループから抜け出すために、Freshness Value (OASIS - wfresh ) と呼ばれる設定を使用できます。このパラメーター (freshness="0" として設定) を web.config の federatedAuthentication セクションに含めると、IDP は WCT パラメーターの現在の時刻に基づいてトークンの鮮度値を確認するように求められます。
Freshness 値の OASIS の説明 – wfresh:
「このオプションのパラメーターは、鮮度の要件を示します。指定されている場合、これは分単位で指定された認証の望ましい最大経過時間を示します。IP/STS は、より長い有効期間を持つトークンを発行すべきではありません。「0」として指定された場合、IP/STS がトークンを発行する前にユーザーに認証を再プロンプトする要求を示します。」</p>
タイムアウトに影響を与えるその他の要因:
また、ADFS プロキシ サーバーが使用されていない場所で ISA または TMG リバース プロキシを介して ADFS を公開する際には、以下の要因も考慮する必要があります。
MSISSignOut は、(このセッションで) ADFS によって発行されたすべてのトークンを追跡するため、サインアウト要求は、要求が開始されたアプリケーションからサインアウトするだけでなく、ADFS が認証したすべての証明書利用者セッションを無効にすることができます。これは、シングル サインアウトまたはシングル ログアウトと呼ばれるものです。ただし、ISA/TMG は SAML クレームを考慮して設計されていないため、タイムアウト/サインアウト プロセスが開始されたときに適切に応答できません。
以下のシナリオのいずれかに直面すると、クレーム非対応のリバース プロキシ トークンの有効期間が明らかになります。
• 要求された Web アプリケーションでユーザーのセッションが期限切れになり、ADFS で再認証する必要がある場合、または
• 上記のように、サインアウトが開始されます。
リバース プロキシのセッションの有効期間内に、ユーザーは資格情報の入力を求められることなく ADFS に対して再認証できます。これは、プロキシがセッション中に既に収集された資格情報を ADFS に渡すためです。
これは ADFS とはまったく関係ありません。これは、リバース プロキシでのセッションの構成方法です。これは、このリスナーのリバース プロキシ セッションの有効期間を制限する強力な理由です。そのため、ADFS セッションがタイムアウトした場合でも、アクティブなリバース プロキシ セッションを使用して ADFS に対して再認証することができます。TMG – ADFS セットアップの詳細については、この ブログ投稿をお読みください。
このトピックに関するより多くの意見を得るために、この質問を開いたままにしています。