2011-02-06 5 views
3

レガシーシステムでホストされているサービスを公開するために、RESTサービスのレイヤーを開発する予定です。これらのサービスは、従来のWebアプリケーションとネイティブの携帯電話アプリケーションで使用されます。ステートフルなWebサービスのセキュリティを確保する

このレガシーシステムでは、初期ユーザー名+パスワード認証が必要です(プロセスには5〜10秒かかる可能性があります)。最初の認証後、時間制約のあるトークンが返されます。このトークンは、それ以降のすべての要求に含める必要があります。そうしないと、要求は拒否されます。

セキュリティ要件のため、レガシーセキュリティトークンはRESTサービスレイヤーの外部に返すことはできません。これは、RESTサービス層がこのトークンをユーザーセッションの何らかの形で保持する必要があることを意味します。そうしないと、レガシーシステムへのすべての呼び出しに対して高価なユーザー名+パスワード認証プロセスを繰り返す必要があります。

RESTサービス層は、Java 6 + Spring 3 + Spring Security 3スタックを使用して実装されます。一見すると、この設定はうまくいくようです:SpringベースのRESTサービスは、むしろ標準的なSpring Security構成を使用して保護されます。レガシーセキュリティトークンはユーザーのHTTPセッションに格納され、すべての呼び出しはユーザーのセッションを作成し、レガシーシステムに送信します。

しかし、RESTクライアントは、ユーザーのHTTPセッションが正しく取得されるように、必要なデータをどのように送信するのかという疑問があります。これは通常、JSESSIONIDクッキーを使用してWebブラウザによって透過的に行われますが、このプロセスにはブラウザは含まれません。確かに、RESTクライアントはコードにクッキー管理機能を追加することができますが、これはSpring RestTemplate、iPhone、BlackBerry、Androidクライアントすべてにとって簡単な作業ですか?

代わりに、RESTサービス層でHTTPセッションをバイパスし、HTTPセッションを介してRESTクライアントから送信されるいくつかのキーを使用して識別される、多分データベースを使用する他の形式のユーザーセッションを使用しますまたは単純な要求のクエリです。それでは、Spring Securityを標準のServlet HttpSessionの代わりにこの代替セッションメカニズムを使用するように設定するにはどうすればよいでしょうか?

確かに、私はこの状況を最初に扱うわけではありません。私は何が欠けていますか?

ありがとうございます!

答えて

3

クッキーに関する魔法はありません。それらはただstrings in HTTP headersです。まともなクライアントAPIはそれらを処理することができますが、多くの場合、Cookie処理を有効にするために明示的な設定が必要です。

クッキーを使用する代わりに、JSESSIONIDをURLに入れることもできます。私は春のセキュリティについては何も知らないが、それは実際にはdisable-url-rewritingが明示的にtrueに設定されていない限り、少なくともいくつかのタイプのURLリクエストのデフォルトのようだ。しかし、これは、ecurity weaknessと考えることができます。

+0

これはクッキーが発明されたものです。それらを使用してください –

+0

私はクッキーの使用が明白な解決であることに同意します。私は、SpringのRestTemplateやiPhone/Android /その他のネイティブモバイルアプリをバックエンドのRESTサービスと統合するための標準的なソリューションかどうかという疑問があると思う。たとえば、RestTemplateでクッキーを管理することは、そのままでは提供されず、追加のコードが必要になります。たぶん、私が見逃している、広く使われている別のユーザー状態管理スキームがあります。または、私は不必要に物事を複雑にしているだけかもしれません:) – Spiff

2

認証は非常に問題があります。ウェブ標準やブラウザの実装に関しては、盲点です。クッキーは「RESTful」だが純粋主義者とはみなされませんが、フル機能のブラウザでさえも、この記事で説明されているようにかなりのハッカーが必要です。Rest based authentication

残念ながら私はモバイル開発を一切行っていないので、最良の妥協策が何であるかを示唆することはできません。まず、対象のプラットフォームのどの認証モデルがをサポートしているかを確認します。具体的には、二つの主なオプションは以下のとおりです。

  • HTTP認証(理想的には、 "基本的" ではない、 "ダイジェスト")
  • クッキー

は一つの可能​​性は両方オプションを提供することです。技術的またはセキュリティ上の観点からは明らかに理想的ではありませんが、使い勝手の点でメリットがあります。

関連する問題