今日、アプリケーションを一緒に接続する内部使用のために開発されたWebサービスがますます増えています。このWebサービスを制御して保護するためのESBはありませんので、それらを保護するための良い方法は何かを推測します。内部のプライベートネットワーク上でSOAP Webサービスを保護する最良の方法
双方向SSLをセットアップしようとしましたが、特定のWebサービスの承認を制御することはできません。
私のウェブサービスを呼び出すアプリケーションと、このアプリケーションを呼び出す権限があることを制御できるようにする必要があります。
これはWS-TrustとWs-Securityが元のSOAPメッセージを変更するので好きではありませんが、他の解決策ではないようです。
おかげ
は私の必要性は、私のウェブ サービスを呼び出すと、このアプリケーションは、それを呼び出すために許可されているどのアプリケーションを制御できるようにすることです。
あなたが望むのは、サービスプロバイダ側の承認メカニズムです。
SOAPメッセージに暗号化を行わない場合は、SOAPメッセージに新しいパラメータを追加することを検討してください。例えばWSの新しいパラメータとしてクライアントの<applicationId> and <password>（または暗号化されたAppId, PassWord文字列）をWSに渡すと、WSはアプリケーションが呼び出し権を持っているかどうかをチェックします。
しかし、これはクライアントとサービスの実装に変更をもたらします。
または、要求のクライアントIPを確認して、どのアプリケーションからのものかを判断できます。アプリケーションにIPアドレスが固定されている場合。
httpsでhttp基本認証を使用できます。これにより、バックエンドアプリケーションはユーザーを知ることができ、したがって許可を行うことができます。
このリンク[1]は、私がWSO2 ESBと同様のことをした方法を示しています。しかし、あなたのスタックに応じて、方法があるかもしれません。メッセージレベルのセキュリティが出ていること -
は、[1]あなたの質問にhttp://wso2.org/library/articles/2011/06/securing-web-service-integration
あなたは現在のSOAPメッセージを変更したくないことを言及します。
したがって、トランスポートレベルのセキュリティに進む必要があります。
双方向SSLの場合でも、ユーザー証明書の拇印に基づいてユーザーを認証することができます。その方法は、使用するスタックによって異なります。その他のオプションがある
..
差は、ある基本的な認証にはないながら、2本足のOAuthは、否認防止をサポートしています。
認証に使用するメカニズムにかかわらず、XACMLを使用してきめ細かな認証を行うことができます。