How to deal with transport level security policy with OSB
Posted
by Jian Liang
on Oracle Blogs
See other posts from Oracle Blogs
or by Jian Liang
Published on Tue, 3 Apr 2012 07:17:26 -0500
Indexed on
2012/04/03
17:36 UTC
Read the original article
Hit count: 947
/OSB
The WSDL of the remote web service looks like following where the part marked in red shows the security policy:
<?xml version='1.0' encoding='UTF-8'?>
<definitions xmlns:wssutil="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="https://httpsbasicauth" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="https://httpsbasicauth" name="HttpsBasicAuthService">
<wsp:UsingPolicy wssutil:Required="true"/>
<wsp:Policy wssutil:Id="WSHttpBinding_IPartyServicePortType_policy">
<wsp:ExactlyOne>
<wsp:All>
<ns1:TransportBinding xmlns:ns1="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<ns1:TransportToken>
<wsp:Policy>
<ns1:HttpsToken RequireClientCertificate="false"/>
</wsp:Policy>
</ns1:TransportToken>
<ns1:AlgorithmSuite>
<wsp:Policy>
<ns1:Basic256/>
</wsp:Policy>
</ns1:AlgorithmSuite>
<ns1:Layout>
<wsp:Policy>
<ns1:Strict/>
</wsp:Policy>
</ns1:Layout>
</wsp:Policy>
</ns1:TransportBinding>
<ns2:UsingAddressing xmlns:ns2="http://www.w3.org/2006/05/addressing/wsdl"/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<types>
<xsd:schema>
<xsd:import namespace="https://proxyhttpsbasicauth" schemaLocation="http://localhost:7001/WS/HttpsBasicAuthService?xsd=1"/>
</xsd:schema>
<xsd:schema>
<xsd:import namespace="https://httpsbasicauth" schemaLocation="http://localhost:7001/WS/HttpsBasicAuthService?xsd=2"/>
</xsd:schema>
</types>
<message name="echoString">
<part name="parameters" element="tns:echoString"/>
</message>
<message name="echoStringResponse">
<part name="parameters" element="tns:echoStringResponse"/>
</message>
<portType name="HttpsBasicAuth">
<operation name="echoString">
<input message="tns:echoString"/>
<output message="tns:echoStringResponse"/>
</operation>
</portType>
<binding name="HttpsBasicAuthSoapPortBinding" type="tns:HttpsBasicAuth">
<wsp:PolicyReference URI="#WSHttpBinding_IPartyServicePortType_policy"/>
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<operation name="echoString">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="HttpsBasicAuthService">
<port name="HttpsBasicAuthSoapPort" binding="tns:HttpsBasicAuthSoapPortBinding">
<soap:address location="https://localhost:7002/WS/HttpsBasicAuthService"/>
</port>
</service>
</definitions>
The security assertion in the WSDL (marked in red) indicates that this is the HTTP transport level security policy which requires one way SSL with default authentication (aka. basic authenticate with username/password).
Normally, there are two ways to handle web service security policy with OSB 11g:
-
Use WebLogic 9.x policy
-
Use OWSM
Since OSB doesn’t support WebLogic 9.x WSSP transport level assertion (except for WS transport), when we tried to create the business service based on the imported WSDL, OSB complained with the following message:
Unfortunately, when tried with OWSM, we couldn’t find http_token_policy from OWSM since OSB PS4 doesn’t support OWSM http_token_policy.
It seems that we ran into an unsupported situation that no appropriate policy can be used from both WebLogic and OWSM.
As this security policy requires one way SSL with basic authentication at the transport level, a possible workaround is to meet the remote service's requirement at transport level without using web service policy. We can simply use OSB to establish SSL connection and provide username/password for authentication at the transport level to the remote web service. In this case, the business service within OSB will be transparent to the web service policy. However, we still need to deal with OSB console’s complaint related to unsupported security policy because the failure of WSDL validation prohibits OSB console to move forward.
With the help from OSB Product Management team, we finally came up with the following solutions:
Solution 1: OSB PS5
The good news is that the http_token_policy is made available in OSB PS5. With OSB PS5, you can simply add OWSM oracle/wss_http_token_over_ssl_client_policy to the business service.
The simplest solution is to upgrade to OSB PS5 where the OWSM solution is provided out of the box. But if you are not in a position where upgrading is an immediate option, you might want to consider other two workaround solutions described below.
Solution 2: Modifying WSDL
This solution addresses OSB console’s complaint by removing the security policy from the imported WSDL within OSB. Without the security policy, OSB console allows the business service to be created based on modified WSDL.
Please bear in mind, modifying WSDL is done only for the OSB side via OSB console, no change is required on the remote Web Service.
The main steps of this solution:
-
Connect to OSB console
-
import the remote WSDL into OSB
-
remove security assertion (the red marked part) from the imported WSDL
-
create a service account. In our sample, we simply take the user weblogic
-
create the business service and check "Basic" for Authentication and select the created service account
-
make sure that OSB consumes the web service via https.
This solution requires modifying WSDL. It is suitable for any OSB version (10g or OSB 11g version) prior to PS5 without OWSM. However, modifying WSDL by hand is troublesome as it requires the user to remember that the original WSDL was edited. It forces you to make the same edit each time you want to re-import the service WSDL when changes occur at the service level. This also prevents you from using UDDI to import WSDL.
Solution 3: Using original WSDL
This solution keeps the WSDL intact and ignores the embedded policy by using OWSM. By design, OWSM doesn’t like WSDL with embedded security assertion. Since OWSM doesn’t provide the feature to explicitly ignore the embedded policy from a remote WSDL, in this solution, we use OWSM in a tricky way to ignore the embedded policy.
-
Connect to OSB console
-
import the remote WSDL into OSB
-
create a service account
-
create the business service in which check "Basic" for Authentication and select the created service account
-
as the imported WSDL is intact, the OSB Kernel:398133 error is expected
-
ignore this error message for the moment and navigate to the Policies Page of business service
-
Select “From OWSM Policy Store” and click “Add” button, the list of policies will pop-up
-
Here is the tricky part: select an arbitrary policy, and click “Cancel”
-
Update and save
By clicking “Cancel’ button, we didn’t add any OWSM policy to business service, but the embedded policy is ignored. Yes, this is tricky. According to Oracle OSB Product Manager, the future release of OWSM will add a button “None” which allows to ignore the embedded policy explicitly.
This solution keeps the imported WSDL intact which is the big advantage over the solution 2. It is suitable for OSB 11g (version prior to PS5) domain with OWSM configured.
This blog addressed the unsupported transport level web service security policy with OSB PS4. To summarize, if you are using OSB PS5 or in a position to upgrade to PS5, the recommendation is to use OWSM OOTB transport level security policy directly. With the release prior to 11g PS5, you can consider the solution 2 or 3 depending on if OWSM is configured.
© Oracle Blogs or respective owner