8

私はSOAにかなり慣れていないので、いろいろと実験しています。

現在、私にとって最大の問題を引き起こしているのは認証です。これについての私の現在の考えは次のとおりです。

クライアントはある種の認証メッセージを認証/ユーザーサービスに送信します。このサービスはデータベースにクエリを実行し、ユーザーが見つかり、パスワードが有効な場合、セッションIDで応答します。このIDは、以降のすべてのリクエストで使用されます。このクライアント。

これは私にはかなり問題ないように思えますが、他のサービスへのリクエストをどのように処理する必要があるのか​​わかりません。3つの異なるアプローチを考えました。

  1. すべてのサービスは、セッションが有効かどうか、有効な場合はユーザーがどの役割を果たしているかを認証サービスに問い合わせます。認証サービスはデータベースを調べ、それに応じて応答します。

  2. 認証サービスはすべてのセッション情報をRAMに保持し、dbラウンドトリップなしで要求に応答します。

  3. 認証サービスは許可されたメッセージをesbに送信し、esbはこの許可されたメッセージをすべてのサービスに転送し、これらのサービスはそれをキャッシュします。認証サービスへのそれ以上の要求は必要ありません。ユーザーがログアウトしたり、役割が変更されたりすると、別のメッセージが送信され、すべてのサービスによって処理されます。

最初のアプローチは、認証サービス/ dbに過度のストレスを与えると思いますが、実装にかかる労力は最小限です。

2つ目はまだ実装が非常に簡単ですが、認証サービスへのストレスはほとんど同じです。

3つ目は、実装が少し複雑ですが、認証サービスへのアクセスが行われないため、応答時間が短縮されます。ただし、セッション情報が多すぎると、このアプローチは失敗し、スケーラビリティはほとんど得られません。

4

2 に答える 2

5

すべてのサービスが内部にある場合、最善のアプローチは次のようになります。

  1. 認証サービスは、サービスクライアントにトークンを発行します。
  2. サービスクライアントは、WS-SecurityなどでラップされたSOAメッセージにトークンを含めます。
  3. サービスは、サービスを提供する前に、認証サービスでトークンを検証する必要があります。

外部サービスについては、SAMLなどのフェデレーションソリューションを検討することをお勧めします。

于 2009-08-18T23:04:58.957 に答える
3

時期尚早の最適化を行わないでください。あなたのオプションはありません。実装がより複雑になることを認める3は不要です。オプション番号を選択します。2それがあなたが速く実装できるものなら。後でプロファイリングして変更することもできますが、オプション2を使用する場合は、「ボトルネック」が発生しないことをお勧めします。

于 2009-08-18T23:10:34.483 に答える