0

私は安全なシステムを構築しています。メッセージを送信するユーザーがアクセスキーを受信したユーザーと同じであることを確認する必要があります。例。

ユーザーBobは、uniqueCode彼だけに固有のプロパティを持っており、サーバーからさまざまな情報を受信できるようにします。

さまざまな機密データを返すためのさまざまなメソッドを備えたWebサービスがあります。ユーザーが最初に使用しているクライアントがWebサービスに接続するとき、それは認証方法を介して接続します。

  1. このユーザーの疑似ランダムキーを生成します
  2. そのキーをサーバーに保存し、ユーザーに返します。

クライアントからWSへの後続の各要求には、uniqueCodeとキーが必要です。ペアが有効な場合、リクエストは必要な情報を返します。x分間アクティビティがない場合、キーは無効になり、クライアントはユーザーに再ログインを要求します。

今私の質問は、サーバーにキーを保存する方法ですか?キーは、シリアル化できるJavaオブジェクトになります。

私のオプション

  • それらをセッションに保持します。これは会社の上級プログラマーが提案したことですが、それは進むべき道ではないようです。私が読んだすべての場所で、WSは基盤となるHTTPセッションに依存すべきではないことを示唆しています。
  • それらをデータベースに保管します。考えられる解決策ですが、特定のデータベースを作成して、問題にまったく別のレベルを追加する必要があります。
  • それらをバイナリ暗号化ファイルに保存します。これは道のりのようですが、そうですか?ログイン時にキーを生成するので、キーといくつかの情報をバイナリファイルに保存し、それ自体を暗号化して、ユーザーに渡すことができます。受け取ったキーでユーザーファイルを解読でき、情報が正しい場合は、ユーザーが要求した情報を返します。

私の考えは正しいですか、それとも何かが足りないのですか?誰かが私のシステムにアクセスした場合、dbに侵入するのは簡単ですが、別のユーザーのキーを知らずにファイルを解読するのは非常に難しいため、最後の方法が最も安全な方法だと思います。

ありがとう!

4

1 に答える 1

1

サーバーの再起動後に使用できるように、キーを保持する必要がありますか?

はいの場合は、データベース、ファイルシステム、またはその他の機能するメカニズムにキーを保持する必要があります。私はデータベースを使用します。そうすれば、アプリケーションを移動したり、アクセス許可を変更したりする場合に、ファイルシステムに依存しなくなります。

いいえの場合は、アプリ内でTime To Liveでキャッシュを使用してみませんか?キーとして使用uniqueCodeし、暗号化キーを値として使用します。人気のあるオプションは次のとおりです。

  • Ehcache
  • グアバキャッシュ
  • 古いセッションを時間どおりに手動でクリーンアップしてもかまわない場合は、普通の古いセッションでもかまいませんHashMap
于 2012-04-23T07:41:29.007 に答える