認証のためにSOAPヘッダー(プレーンなクライアント資格情報を含む)に依存しているSOAP Webサービスが本番環境にあります。WS は、Web アプリまたはデスクトップ アプリの両方の .NET/Java/PHP/Python/C++ クライアントを使用する異種環境で使用されます。
これらの WS の v2 を検討していますが、WS SOAP 認証のベスト プラクティスとはどのようなものでしょうか? (かなり安全でありながら、さまざまなプラットフォームで簡単に処理できます)。
認証のためにSOAPヘッダー(プレーンなクライアント資格情報を含む)に依存しているSOAP Webサービスが本番環境にあります。WS は、Web アプリまたはデスクトップ アプリの両方の .NET/Java/PHP/Python/C++ クライアントを使用する異種環境で使用されます。
これらの WS の v2 を検討していますが、WS SOAP 認証のベスト プラクティスとはどのようなものでしょうか? (かなり安全でありながら、さまざまなプラットフォームで簡単に処理できます)。
さまざまなプラットフォームでこれを処理する最も簡単な方法は、トランスポート層に HTTP 基本認証と HTTPS を使用することです。WS-Security は、単純なユーザー名とパスワードを超える必要がある場合に適していますが、サポートはプラットフォームによってかなり異なります。HTTP 認証は、すべての適切な SOAP 実装でサポートされています。
すべて自分で行う必要があり、HTTPS を使用できない場合は、WS-Security のハッシュ ベースの UsernameToken 部分をお勧めします。ライブラリにハッシュ関数がある限り、実装は非常に安全で簡単です。
Web サービスを行っている場合、認証に HTTP を使用することはありません。
WS-Security は全体として大きすぎます。
これまで私が取り組んできた方法は、標準の WS-* 機能を使用することでした。
認証機能を使用する代わりに、メッセージ ヘッダーの整合性機能をオンに設定します。これには、ダイアログの両側が公開鍵と秘密鍵のペアにアクセスできる必要があり、ヘッダーのユーザー名フィールドの改ざんを検出します。したがって、メッセージを送信してユーザー ID を設定した人は誰でも秘密鍵にアクセスできることを確認できます。
キーが適切に管理されていれば、妥当なレベルの整合性が得られます。