15

私は一般的に Java 認証フレームワークと認証ワークフローの経験があまりない (理論的な知識しかない) ため、教育目的で、HTTP アプリケーション用にこのタイプの認証を作成しようとしています。

  1. クライアントは、ログインとパスワードを に投稿します/login。
  2. Shiro は、指定された資格情報でユーザーにログインします。サーバーはクライアントに自分の を返しますsessionId。
  3. クライアントはある種のリソースを要求します/myresource?sessionId=1234567。
  4. Shiro は与えられた Subject でログインしsessionIdます。/myresource次に、サーバーは(メソッド レベルのアクセス権を管理する Shiro と共に)を取得する通常のワークフローを実行します。

基本的に私はこれらの質問があります：

  1. HTTP セッションもサーブレット セッションも必要ないと思います。Shiro には、私のニーズには十分な独自のセッション マネージャーがあります。私が間違っている？
  2. クライアントに実際の sessionId を与えるのは良い習慣ですか、それともある種の sessionToken (サーバー側で sessionId に解決される) を送信する必要がありますか?
  3. sessionId (クライアントがローカルに保存する必要があります) を使用してサブジェクトにログインするにはどうすればよいですか?
  4. この種の認証を行う前に、他に知っておくべきことはありますか?

前もって感謝します。

4

1 に答える 1

35

HTTP セッションもサーブレット セッションも必要ないと思います。Shiro には、私のニーズには十分な独自のセッション マネージャーがあります。私が間違っている？

いいえ、あなたは正しいです。だから士郎はすごい。ドキュメントから：

Shiro のセッション サポートは、これら 2 つの [Web コンテナーまたは EJB ステートフル セッション Bean] メカニズムのいずれよりも使用および管理がはるかに簡単で、コンテナーに関係なく、あらゆるアプリケーションで使用できます。

例えば

Subject currentUser = SecurityUtils.getSubject();    
Session session = currentUser.getSession();
session.setAttribute( "someKey", someValue);

ドキュメントからの引用：getSession calls work in any application, even non-web applications

クライアントに実際の sessionId を与えるのは良い習慣ですか、それともある種の sessionToken (サーバー側で sessionId に解決される) を送信する必要がありますか?

プレーンな sessionId を送信するのはお勧めできません。特に、暗号化されていないネットワーク経由でデータを送信している場合。HTTPS のようなものを使用するか、何かの行NONCEを使用します。

また、URL ではなく、http/s POST データを使用する場合の補足事項です。

sessionId (クライアントがローカルに保存する必要があります) を使用してサブジェクトにログインするにはどうすればよいですか?

セッション ID を取得したら、どうすればサブジェクトを認証できるということですか? あなたは簡単に、ドキュメントから、

Subject requestSubject = new Subject.Builder().sessionId(sessionId).buildSubject();

この種の認証を行う前に、他に知っておくべきことはありますか?

はい。

  1. Shiro のセッション管理を読む
  2. MITM 攻撃について学ぶ
  3. HTTPSとSSLについて
  4. 一部のハッシュ関数は this、Apache Commons DigestUtilsであり、 this である可能性があります

アップデート

そのサブジェクト認証部分について-新しく作成されたサブジェクトを現在認証されているサブジェクトにしますか? そうでない場合、どうすればそれを「現在の」主題にできますか?

について話している場合はnew Subject.Builder().sessionId(sessionId).buildSubject()、そうではありません。そして、スレッドのcurrentUserとして設定する方法がわかりません。Shiro のJavaDocによると、

[この方法] 返されたサブジェクト インスタンスは、後で使用するためにアプリケーション (スレッド) に自動的にバインドされません。つまり、SecurityUtils.getSubject() は、ビルダーによって返されるものと同じインスタンスを自動的に返すことはありません。構築されたサブジェクトを必要に応じて継続して使用するためにバインドするのは、フレームワーク開発者の責任です。

そのため、現在のスレッドでサブジェクトをバインドする方法、またはさらに使用する方法はあなた次第です。

SecurityUtils.getSubject();Web コンテナーのコンテキストで、thingyがどのように機能するかを心配している場合は、単純な Cookie を使用してセッション データを保存します。リクエストが Shiro フィルターを通過すると、現在のサブジェクトがそのライフサイクル (現在のスレッド) のリクエストに添付されます。そして、getSubject()それが単にSubjectfrom リクエストを取得したとき。ここで興味深いスレッドを見つけました。

nonce 部分について: 彼が sessionId の代わりにある種のハッシュを送ってきた場合、それをデコードして実際の sessionId を取得することはできません (それで彼を承認するため)。ここで何か不足していますか？

ノンス部分・・・首が痛いです。今考え直すと、NONCEをやるのはやり過ぎだと思います。とにかく、いくつか説明させてください。

  1. ユーザーは、自分のユーザー名とパスワードで初めてログインします。userid、nonce（UUIDなど）を設定し、HASH(sessionID+nonce)クライアント側でhash1と呼びます。クッキーで言ってください。これnonceをサーバー側に保存します。DBまたはマップにある可能性がありますuser_id <--> nonce,session_id

  2. 後続のリクエストでは、必ず passbackuseridと.nonceHASH

  3. サーバー側で最初に行うことは、リクエストの検証です。を取得し、クライアントから送信されたものに基づいてハッシュマップまたは DB に格納されsessionIdます。ハッシュ HASH(sessionId_from_db+nonce_from_db) を作成し、hash2 と呼びます。nonceuser_id

  4. これで、hash1 が hash2 と一致する場合、リクエストを検証できます。サーバー側に現在の sessionId を保存しているので、それを使用できます。リクエストの完了時に、Cookie とサーバー側で新しい nonce を設定します。

1 ～ 4 を経ると、認証に Shiro を必要としないことがわかります。(: したがって、私の言葉を撤回します。パフォーマンスよりもセキュリティにこだわりすぎない限り、この場合 NONCE は適用されません。

MITM 攻撃が問題になるのはなぜですか? 私のクライアント (javascript ajax コード) は、ajax を介してサーバーからデータをフェッチします。ですから、MITM を気にする必要はないと思います。

私はそれがあなたにとって重要であるべきだと思います。MITM 攻撃とは、要求/応答がマシン (MITM) を介してルーターにチェーンされていることを意味します。暗号化されていないリクエストの場合、MITM にはすべてプレーン テキストです。彼はあなたのすべてのリクエストを見ることができます...そしておそらくリクエストを偽装し、セッションをハイジャックする可能性があります. 例をいくつか見つけさせてください.... http://michael-coates.blogspot.com/2010/03/man-in-middle-attack-explained.html

于 2011-12-16T09:26:02.450 に答える