WS-Security Username Token Profile is a simple authentication scheme for SOAP-webservices using username an password sent in the requests‘ WS-Security headers. The password is hashed using a salt and a timestamp (password digest) to prevent replay attacks. It is specified in this document. As this does not involve any message encryption it should not be used without transport encryption.
In this post I will show how I configured this for a webservice to be deployed on a recent Weblogic Server (188.8.131.52).
On Weblogic webservices security is configured using policy files following WS-Policy standards. The easiest way to secure a webservice is to configure one of the prebuilt policy files shipped with Weblogic, in this case
Wssp1.2-2007-Https-UsernameToken-Digest.xml which enforces both authentication and transport level security. How to enable this manually after the service is deployed is described in the Admin Console Online Help.
In my case I just wanted to test authentication without bothering with certificates so I deployed my own policy file which does not enforce the use of transport level encryption:
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ ws-securitypolicy/200702"> <sp:SupportingTokens> <wsp:Policy> <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:HashPassword/> <sp:WssUsernameToken10/> </wsp:Policy> </sp:UsernameToken> </wsp:Policy> </sp:SupportingTokens> </wsp:Policy>
Custom policies are stored under
/WEB-INF/policies in the webservice war file. Automatic activation after deployment can be achieved either by use of a deployment plan or by annotating the service implementation class with the
weblogic.jws.Policy annotation as described in the Oracle documentation. The downside of this approach is that our code now depends on server-specific libraries but in our case this was the easiest way.
Configuring the security realm
Weblogic uses security realms to manage users and groups for authentication. In our case we used the default realm which is configured when setting up the default admin user. By default this security realm does not support password digest authentication, so we need to enable this using the WLS Admin Console: After selecting our default realm „myrealm“ in the Security Realms overview we change to the Providers-tab.
There we first select the DefaultAthenticator and switch to its Provider Specific-tab. There we check the Enable Password Digest-checkbox and save our changes.
Back in the myrealm |Providers-tab we now select the DefaultIdentityAsserter. On its Configuration-tab we add
wsse:PasswordDigest to the list of active authentication types.
We save our changes and restart Weblogic. As we changed the way Weblogic stores its users‘ passwords we need to reset the passwords of all users we want to access our webservice with.
In most cases I use SoapUI for manually testing webservices. It supports password digest authentication but unfortunately at least the version I used seems to add a binary nonce to the SOAP-header which Weblogic cannot understand. I therefore built a Java-Client using only standard JDK-features following the description in this blog post.
Wrapping it up
To configure a webservice to use authentication following the WS-Security Username Token Profile we need to add a corresponding WS-Policy file. To make password-digest-authentication work we also need to configure our security realm to support this feature. Testing a webservice using password-digest-authentication might be a little inconvenient depending on the tools you use.