Using WS security policy on consumer WSD

Hi all !

I would like to call a simple webservice wich require usernameToken authentication. The request must contain a ws-security header as follows :

<soapenv:Envelope xmlns:soapenv=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:hel=“http://helloservice.test.fr/” xmlns:wsse=“http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”>
soapenv:Header
wsse:Security
wsse:UsernameToken
wsse:Usernameadmin</wsse:Username>
wsse:Passwordadmin</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>

</soapenv:Envelope>

I’m able to call that webservice only if :
I set my consumer’s “Pre-8.2 compatibility mode” property to true,
and I add a WS Security handler with a “Consumer policy for username”.

I would like to make the same thing by attaching a policy and thus setting “Pre-8.2 compatibility mode” property to false.

Here is the policy file I have used :

<wsp:Policy wsu:Id=“Username_Token” Name=“Username and Password”
xmlns:wsp=“Web Services Policy Framework (WS-Policy) and Web Services Policy Attachment (WS-PolicyAttachment)
xmlns:wsu=“http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>
wsp:ExactlyOne
wsp:All
<sp:SupportingTokens xmlns:sp=“…”>
wsp:Policy
<sp:UsernameToken sp:IncludeToken=“…/IncludeToken/AlwaysToRecipient” >
wsp:policy
sp:WssUsernameToken10/
</wsp:policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

It doesn’t work and I get this error :
org.apache.axis2.AxisFault: Error in getting password for user “admin”

Could someone provide me a working example of this use case ?

Thancks.

The service works when I use debug mode (i.e using restorePipelineFromFile), but not when calling the provider using soapUI.

Deleting the attached policy to my consumer, I get the classic com.sun.xml.wss.XWSSecurityException. So I thinck my policy file is correct.

Does someone has an idea to correct the problem ?

Hi Max, did you get it working … I am having similar issue, any help ?

See the attached policy file for implementing WS-Security UsernameToken. I had to add the .txt extension to the filename to upload it successfully. Just remove the .txt extension from the filename and copy it into your server at IntegrationServer\config\wss\policies There is no need to reatart IS

This policy file works with my 8.2.2 version. It should also work with other versions of 8.x because the policy file just implements the standard Web Services Policy 1.2 - Framework (WS-Policy)

I added a few comments to the policy file to help describe it.

I hope this helps.
OucUsernameToken.policy.txt (855 Bytes)

Thanks for your reply, Not sure if I can replace our policy file with yours one, better would be if you can spot whats wrong in ours policy file.

===========
<wsp:Policy wsu:Id=“TEST” Name=“MPPO”
xmlns:wsu=“http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
xmlns:wsp=“Web Services Policy Framework (WS-Policy) and Web Services Policy Attachment (WS-PolicyAttachment)”>
wsp:ExactlyOne
wsp:All
<sp:TransportBinding
xmlns:sp=“Web Services Security Policy Language (WS-SecurityPolicy)”>
wsp:Policy
sp:TransportToken
wsp:Policy
<sp:HttpsToken RequireClientCertificate=“false” />
</wsp:Policy>
</sp:TransportToken>
sp:AlgorithmSuite
wsp:Policy
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
sp:Layout
wsp:Policy
<sp:Lax />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
</wsp:Policy>
</sp:TransportBinding>
<sp:SignedSupportingTokens
xmlns:sp=“Web Services Security Policy Language (WS-SecurityPolicy)”>
wsp:Policy
<sp:UsernameToken
sp:IncludeToken=“WS-SecurityPolicy Token Inclusion Mechanism”>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
<sp:Wss10 xmlns:sp=“Web Services Security Policy Language (WS-SecurityPolicy)”>
wsp:Policy
<sp:MustSupportRefKeyIdentifier />
<sp:MustSupportRefIssuerSerial />
</wsp:Policy>
</sp:Wss10>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

In our case Software AG has confirmed that this is a bug which has been fixed in 8.2.2 core-fix4. Now we are working on a work around for this issue as fix can’t be applied before project need to go live.