WSO2:ログインとパスワードによる認証を使用したサービスへのプロキシの構成

挑戦する


特定のプロトコルを使用してデータを要求できるアプリケーションがあり、データを送信できるサービスがありますが、別のプロトコルを使用しており、ログインとパスワードによる認証が必要です。
アプリケーションには、サービスにアクセスするために必要な資格情報がありません。 友達をアプリケーションとサービスにする必要があります。

解決策


バス: WSO2 Enterprise Service Busを使用して、プロキシサービスを構成します。

WSO2 ESBバージョン4.7.0を使用します。

ポリシーを作成する

ターゲットサービスはWS-Security標準に従って保護されているため、このサービスへのアクセスを標準の最大限の範囲で構成します。
ポリシーは、インターフェイスのローカルリポジトリのリソースとして作成されます。管理-サービスバス-ローカルエントリ-ローカルエントリの追加-インラインXMLエントリの追加。

発信ポリシー

ここおよび将来、名前は任意に指定できますが、すべてのアーティファクトがリンクされるため、それらに焦点を当てます
名前を指定: service-policy
ポリシーを指定します。

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UTOverTransport"> <wsp:ExactlyOne> <wsp:All> <sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:TransportToken> <wsp:Policy> <sp:HttpsToken RequireClientCertificate="false"/> </wsp:Policy> </sp:TransportToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic128/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> </wsp:Policy> </sp:TransportBinding> <sp:SignedSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"/> </wsp:Policy> </sp:SignedSupportingTokens> <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy"> <ramp:user>MyUsername</ramp:user> <ramp:passwordCallbackClass>serPasswordCallbackHandler</ramp:passwordCallbackClass> </ramp:RampartConfig> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> 

このポリシーの主な部分は、ターゲットサービスのユーザー名とクラスを指定することです。この場合、必要なパスワード、 serPasswordCallBackHandlerクラスを単純に置き換えます。

 package ser; import org.apache.ws.security.WSPasswordCallback; import javax.security.auth.callback.Callback; import javax.security.auth.callback.CallbackHandler; import javax.security.auth.callback.UnsupportedCallbackException; import java.io.IOException; public class PasswordCallBackHandler implements CallbackHandler { private static final String PASSWORD = "MyPassword"; @Override public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException { for (Callback callback : callbacks) { if (callback instanceof WSPasswordCallback) { WSPasswordCallback pc = (WSPasswordCallback) callback; if (pc.getUsage() == WSPasswordCallback.USERNAME_TOKEN_UNKNOWN) { if (pc.getPassword().equals(PASSWORD)) return; throw new UnsupportedCallbackException(callback, "Check failed"); } pc.setPassword(PASSWORD); } else { throw new UnsupportedCallbackException(callback, "Unrecognized Callback"); } } } } 


jarにパックし、WSO2_HOME / repository / components / lib /に配置します。
WSO2を再起動します。

受信トレイポリシー

名前を指定します: empty-policy
ポリシーを指定します。

 <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UTOverTransport"> <wsp:ExactlyOne> <wsp:All> <sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy/> </sp:TransportBinding> <sp:SignedSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy/> </sp:SignedSupportingTokens> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> 


アドレスエンドポイントを作成する

名前my-endpointを指定します
サービスのアドレスを指定します。
追加のオプションでは、WS-Securityの使用に注意し、以前に作成した送信メッセージと受信メッセージのポリシーを指定します。
エンドポイントソース:

 <endpoint name="my-endpoint"> <address uri="http://service/soap/"> <enableSec inboundPolicy="empty-policy" outboundPolicy="service-policy"/> </address> </endpoint> 


XSLTメッセージ変換を作成する

XSLT変換は、政治家と同じ場所で作成されます。管理-サービスバス-ローカルエントリ-ローカルエントリの追加-インラインXMLエントリの追加。

受信メッセージを変換する

アプリケーションのリクエストを、サービスが理解できるビューに持ってくる必要があります。
名前を示します: in-xslt
変換を指定します。

 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template match="/"> <!--  --> </xsl:template> </xsl:stylesheet> 


送信メッセージに変換

サービスの応答を、アプリケーションが理解できる形式にする必要があります。 このステップは、名前: out-xsltのみが着信メッセージのステップと同じです。

プロキシサービスを作成する

UIの場合:管理-サービス-追加-プロキシサービス-カスタムプロキシ
名前をexternal-serviceに指定します 。 この名前で、たとえばlocalhost :8280 / services / external-serviceのように、バスでサービスを利用できます。
この場合、httpsプロトコルのチェックを外します。
次に、ソースモードに切り替え(ソースビューに切り替え)、コンテンツを次のようにします。

 <?xml version="1.0" encoding="UTF-8"?> <proxy xmlns="http://ws.apache.org/ns/synapse" name="external-service" transports="http" statistics="disable" trace="disable" startOnLoad="true"> <target faultSequence="fault" endpoint="my-endpoint"> <inSequence> <xslt key="in-xslt"/> <send> <endpoint key="my-endpoint"/> </send> </inSequence> <outSequence> <xslt key="out-xslt"/> <send/> </outSequence> </target> <description/> </proxy> 


着信メッセージと発信メッセージには2つのシーケンスがあり、どちらも適切な変換で始まり、正しい方向にメッセージを送信します。

できた!

オプショナル



プロキシメッセージの変化を監視するには、フィドラーを使用しました

構成方法と最終メッセージを見る場所が見つからなかったからです。
フィドラーの詳細:


プロキシはアプリケーションから送信されたActionヘッダーを転送しますが、サービスは誓いますか?

プロキシサービスシーケンスにメディエーターを追加し、アクションヘッダーを削除します。

 <inSequence> <xslt key="in-xslt"/> <header name="Action" value=""/> <property name="SOAPAction" value="" scope="transport"/> <send> <endpoint key="my-endpoint"/> </send> </inSequence> 


プロキシは間違ったエンコーディングでデータを返しますか?

メッセージを返すエンコードを指定します。

 <outSequence> <xslt key="out-xslt"/> <property name="messageType" value="text/xml;charset=windows-1251" scope="axis2" type="STRING"/> <send/> </outSequence> 


サービスの応答はいくつかの部分で構成されていますか?

例:

 <soapenv:Envelope> <soapenv:Body> <part1/> <part2/> </soapenv:Body> </soapenv:Envelope> 


WSO2は、デフォルトでは、答えは1つの部分で構成されると見なします。したがって、パスに沿った変換を渡します。 s12:Body / child :: * [position()= 1]、結果として最初の部分のみを変換できるため、これを修正するために、サービス内のコンバーターの呼び出しを変更します。

 <outSequence> <xslt xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" key="stav-out-xslt" source="SOAP-ENV:Body"/> <send/> </outSequence> 


...そして、コンバータでこれを考慮します:

 <xsl:stylesheet> <xsl:template match="."> <xsl:apply-templates select="/part1"/> <xsl:apply-templates select="/part2"/> </xsl:template> <!--   part1   --> <xsl:template match="part1"/> <xsl:template match="part2"> <forbody> <!--     ,  ,         --> </forbody> </xsl:template> </xsl:stylesheet> 


未解決の問題



2つのセキュリティポリシーを構成する必要がありました

単独でそれを行うことができるという感覚がありますが、単一のポリシーでは、サービスの応答にセキュリティヘッダーが含まれていないというエラーがありました。 しかし、彼は本当にそれらを含んでいません。 これを回避するには、回答用の空のポリシーを作成する必要がありました。

サードパーティの資格情報を保存するための組み込みソリューションが見つかりませんでした

パスワードストレージクラスを使用した不器用なソリューションは、組み込みまたは自転車のいずれかの適切なソリューションと交換する必要がある明らかな松葉杖です。

まとめ


Source: https://habr.com/ru/post/J212267/


All Articles