2

Web サービスを可能な限りステートレスに保ちたいという野心のために、問題が発生しました。私は最近 Axis2 の使用を開始し、実行可能な認証ソリューションを見つけようとしました。認証とは、ユーザー/パスワードを意味します。私はすでに SSL を WS-Policy と組み合わせて使用​​して、プロシージャー呼び出しを保護しています。

ただし、Rampart 1.6.2 にバンドルされているサンプルの一部、特に「sample-tomcat」という名前のポリシーの例とその WSPasswordCallback ハンドラー (ここにあります) が古くなっていることがわかりました。メッセージのセキュリティ ヘッダーの UsernameToken 要素内でパスワードが指定されている場合でも、WSPasswordCallback.USERNAME_TOKEN_UNKNOWN1.6 で廃止され、常に null を返します。WSPasswordCallback.getPassword()

そう。すべてのメッセージのユーザー名とパスワードの確認をどこで行うべきかわかりません。私はこれらの2つのオプションを見ています：

  1. ユーザー名/パスワード認証を実行するハンドラーを使用してモジュールを作成します。

  2. ステートレス性を放棄し、他のすべてのサービスで必要なトークンを返すログイン サービスを記述します。

他のオプションはありますか？

4

1 に答える 1

1

実際、WSS4Jの開発者であるColm O Heigeartaighによると、バリデーターインターフェイスで動作するように変更する前は、もっと奇妙でした。WSS4J1.6の新しいバリデーターの設計に関する彼の最初、2番目、3番目のブログ投稿を参照してください。

認証を処理するべきではありません。WSPasswordCallbackそれは悪い設計であり、関心の分離に反対していると考えられているため、彼ら（WSS4J開発者）はWSS4Jのこの部分を書き直しました。

ただし、私が知る限り、Rampart開発チームは、開発者がカスタムバリデーターを適用する方法をまだ実装していません。またNoOpValidator、WSS4Jで利用可能であっても、-などのWSS4Jバリデーターを適用する方法もありません。彼らの（Rampartの）プロジェクトJIRA（ここで読んでください）に登録されている問題がありますが、優先度は低く、現時点ではこれが書かれています。その問題は、次のマイナー（1.6.3）またはメジャー（1.7.0）リリースには含まれていません。

したがって、私自身の好みの順に、次の3つのいずれかを実行する必要があります。

  • トランスポート層ベースの認証を使用します。HTTPSトランスポートを使用した認証ヘッダーをお勧めします。
  • Axis2とRampartを1.5.xにダウングレードしますが、これは引き続き維持されます（重大なバグ修正）。
  • wss4jのソースを編集し、新しいjarをコンパイルします。
  • これを解決するAxis2用のモジュールを作成します。

追加の解決策/回避策がある場合は、コメント/修正してください。

于 2013-02-21T09:43:50.650 に答える