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.
