2

現在、JBoss EAP 6.4/7.0 を使用して JAAS と JACC を採用しています。適用方法について簡単に説明します。

  • HttpServletRequest.login(...)認証に使用します
  • その後、HttpServletRequest.logout()ログアウトに使用します。
  • 資格情報を検証し、ロールを準備する LoginModule があります。

すべて問題ありませんが、アプリケーションの一部で、特定のユーザーのセットを許可する必要があります。

  • システムにログインするために他の誰かの役割を取り消します。
  • 現在アクティブなセッションからそれらを追い出します。

最初の部分は簡単ですが、誰かのセッションを無効にする方法を理解するのに苦労しています。どうにかして他のユーザーのサブジェクト/セッションを取得して無効にする方法はありますか?

とても有難い

4

1 に答える 1

1

用語に関する注意:

  • ここでの認証メカニズム (AM)は、関連する認証ステートメントを作成し、その結果として、Java EE ランタイムを使用して/で認証された呼び出し元エンティティの ID を登録/確立する役割を担うコンポーネントを指します。このようなコンポーネントは、Application Server (AS) または Java EE 標準に固有のものである場合があります。Java EE アプリケーション開発者による拡張が予定されている AS 実装の詳細またはタイプ。Java EE アプリケーションの一部として、または AS の一部としてデプロイされます。そのようなコンポーネントの 1 つがJAAS LoginModule (LM) です。アイデンティティ ストア (IS)は、最近 (とりわけ) LM を参照するために使用される (半) 規範的な用語のように見えますが、アプリケーション固有の永続化レイヤー (JPA など) 用に予約したいと思いました。 @Entity）ユーザーを表すタイプであるため、この（定義が不十分な）区別を確立する必要がありました。「なぜあいまいなのですか?」、「LM を LM と呼べないのですか?」と尋ねるかもしれません。JBoss LM について何も知らないからです。実際、私は JBoss ユーザーでも、Java EE で JAAS を使用している人でもありません。それでも、一般的なケースに適用される回答に貢献できると感じたため、避けられない曖昧さがあります。
  • 非アクティブ化されたユーザーとは、より適切な用語がないため、「追い出されるユーザー」、つまり、権利 (グループ、ロール、パーミッションなど、そこで呼ばれるものは何でも) が取り消されたユーザーを指します。ある意味ISレベル。

まず第一に、任意のユーザーをコードに公開する標準の Java EE API はありませSubjectんHttpSession。理論的には、認証中などにその情報を自分で記録することもできますが、これはあなたが望むものではないと思います。さらに、具体的には、 に代わって要求を処理する際に ( / 資格情報コレクションの) 変更をSubject明示的に禁止する標準はありませんが、いずれかでなければならないと述べているものはありません。実際には、現在の認証された呼び出し元(認証中に入力され、 JACCを介して取得できるもの)が必要かどうかさえ明確ではありません。PrincipalSubjectSubject"javax.security.auth.Subject.container" PolicyContextHandlerPolicy承認の決定を行う際にランタイムが照会するデータ構造と一致します。つまり、ランタイムはコピーのみを提供するか、認証された呼び出し元のまったく異なる表現を内部で使用するか、またはその間の何かを使用する可能性があります。したがって、 を変更できたとしてもSubject、実際のセキュリティ コンテキストに必ずしも影響するとは限りません。

できることを進めていきます。認証側および/または承認側のいずれかでニーズに対応できますが、前者のアプローチは後者よりも採用がはるかに簡単です。あなたは私のコメントに答えなかったので、考えられる答えの両方を簡単に説明します.

発信者再認証の禁止

アプリケーションがユーザーを非アクティブ化したら、AM が発行する後続の要求でユーザーの再認証を停止するように何らかの方法で AM に指示する必要があります。カップリングを減らすために、アプリケーションは通常 AM と直接通信しませんが、AM によって評価される条件を満たします。たとえば、アプリケーションは特別な「locked_out」権限をユーザーに割り当てたり、HttpSession属性を設定したりします。非アクティブ化されたユーザーの再認証を求められると、AM は非アクティブ化を認め、再認証を拒否します。その後、ユーザーのセッションが無効になります。それがどの程度正確に達成されるかは、その種類と実装によって異なります。あなたの LM はおそらく、その目的のために"javax.servlet.http.HttpServletRequest"JACCを活用しなければならないでしょう。PolicyContextHandlerジャスピック ServerAuthModulevalidateRequest引数として受け取ったリクエストインスタンスにすぐにアクセスできます。他のコンポーネントは、おそらく AS 内部の使用に頼る必要があるか、アプリケーションにセッション無効化の責任を負わせる必要があります ( Servlet Filterなどの一部の呼び出し傍受コンポーネントは、IS にもう一度クエリを実行し、それに応じて動作する必要があります)。

前述のアプローチでは、明らかに AM の機能を変更する機能が必要です。さらに、キャッシュ AM は、以前に確立された認証結果を再利用する前に、前述の非アクティブ化条件を評価する必要があります。最後に、コメントで述べたように、ユーザーの IS アクセス失効時に、そのユーザーに代わって要求が処理されている (アクセス失効イベントが発生する前に到着した/認証された) 場合、そのリクエストのサービスは正常にHttpServletRequest#完了します（アプリケーションが（login| ）などを介してそのユーザーの再認証をリクエストしない限りauthenticate）。

発信者再認証の禁止

冒頭で述べたように、ユーザーのSubjects は簡単に取得/変更できませんがPolicy、JACC 準拠の Java EE ランタイムでそれらが承認される裏付けは、実際には. 残念ながら、デフォルトの AS 提供の JACC プロバイダー ( PolicyConfiguration+ Policy) には重大な制限があります。それは、Java EEロールに対してのみ操作を許可し、 にマップされた(つまり、これらのロールを「持つ」)呼び出し元に対して操作を許可しませんPrincipal。たとえば、デフォルト プロバイダを使用すると、「admin」ロールにマップされたs が持つ を拡張できます。「admin」ロールとそのすべてのロールを削除できます。しかし、それはあなたが誰を決定することを許可しませんPermissionPrincipalPermission「管理者」になります--少なくとも標準的な方法ではありません。

この制限により、JACC に関する限り、基本的に 2 つの選択肢が残されます。AM に、それぞれのcaller と同じ名前の「ダミー」グループ Principalを各 caller に追加させる。次に、ユーザーの非アクティブ化時に、「ダミー」グループに関連するカスタムを ( 経由で)追加します。最後に、「application-space」コードから (たとえば、AccessController#checkPermission を介して) ユーザーが を持っているかどうかを確認し、持っている場合はそれらを追い出します。しかし、待ってください、これはまったく無意味です。それ自体で承認を処理できないのに、なぜそもそも をわざわざ使用する必要があるのでしょうか。別の方法は、独自の JACC プロバイダーを作成してインストールすることです。そうすることで、完全に制御できるようになりますSubjectPrincipalPolicyConfiguration#addToRolePermissionPermissionPolicyPrincipal-/グループからロールへのマッピングと、その時点からのその情報を使用して、承認に関して、ほとんど好きなように行動できるようにします。ただし、新しいプロバイダーを作成することは簡単ではありません。特に、単一のアプリケーションの範囲内だけでなく、JRE 全体の承認ニーズに対応する必要があるためです。あなたの要件が、それほど高い作業量を正当化するとは思えません。それでもその道をたどりたい場合は、Arjan Tijms のブログにある JACC 関連の記事が出発点として最適です。

于 2016-11-06T11:04:20.833 に答える