Recently,
we received a use case for Oracle Service Bus (OSB) 11gPS4 to
consume a Web Service which is secured by HTTP transport level
security policy.
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:
[OSB
Kernel:398133]The service is based on WSDL with Web Services Security
Policies that are not natively supported by Oracle Service Bus.
Please select OWSM Policies - From OWSM Policy Store option and
attach equivalent OWSM security policy. For
the Business Service,
either you can add
the necessary client policies manually by clicking
Add button or you can let Oracle Service Bus automatically pick and
add compatible client policies by clicking Add Compatible button.
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.
