認証に ADFS を使用する asp.net Web アプリの作成を任されています。ただし、アプリケーションのある段階で、ユーザーは再認証を行い、ユーザー名とパスワードを再度入力する必要があります。
これは ADFS で実行できますか?
認証に ADFS を使用する asp.net Web アプリの作成を任されています。ただし、アプリケーションのある段階で、ユーザーは再認証を行い、ユーザー名とパスワードを再度入力する必要があります。
これは ADFS で実行できますか?
ASP.NETアプリは、STSのアクティブクライアントでもパッシブクライアントでもかまいません。ステップアップする必要がある場合は、いくつかの入力フィールドを入力し、ユーザーにそれらが誰であるかを示す追加の証拠を求めます。WSTrustChannelFactoryを使用して、この情報(および場合によっては元のトークン)をSTSに渡して、より新しい、より価値の高いトランザクションを承認するのに十分なクレームを含む新しいトークンを取得します。
再認証の目的は何ですか。つまり、ユーザーは何を証明する必要がありますか?
私は、アプリケーションが最近の認証タイムスタンプ (たとえば、最後の 10 秒以内) を持つサインイン トークンを必要としていると推測しています。これにより、アプリケーションは、クライアント システムが実際に同じユーザーの制御下にあることを合理的に確信できます。
(ちなみに、Web サーバーと AD FS サーバーの時計の違いに注意してください。)
今後数か月で、同様のシナリオを調査する予定です。現在のアイデアは、Vittorio Bertocci によるこのブログ投稿で説明されているように、 SessionAuthenticationModule.SessionSecurityTokenReceived Eventを使用することです。ただし、これは完全なソリューションではありません。これは、AD FS にトークンを強制的に発行させるだけであり、AD FS に最近の認証タイムスタンプを持つトークンを強制的に発行させるわけではないためです。
したがって、まだ答えはありませんが、おそらくこれらのヒントが役立ちます.
この記事では、このシナリオで役立つ可能性がある "ステップアップ" 手順について説明します。まだ使っていないので、詳細なコメントはできません。あなたがやろうとしていることに非常に近いように見えます。
TokenLifetime プロパティを減らすと、ユーザーを再認証できます。TokenLifetime はデフォルトで 60 分ですが、20 分前にポップアップが表示されます。ただし、データが失われる可能性があります