Add support for WS-Security UsernameToken with digested password, nonces and timestamps.
----------------------------------------------------------------------------------------
Key: JBESB-3723
URL:
https://issues.jboss.org/browse/JBESB-3723
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Security, Web Services
Affects Versions: 4.10
Environment: JBoss SOA-Platform 5.2.0
Reporter: Duncan Doyle
Current support for WS-Security UsernameToken in JBoss ESB is limited to usernames and
passwords passed in plain text in the WS-Security SOAP header. JBossWS supports
UsernameToken with digested passwords, nonces and timestamps. So, an ESB service could be
fronted with a JBossWS webservice with UsernameToken with digested password and nonce,
which can call the ESB service via ServiceInvoker, or which can be used in an
ActionPipeline via SOAPProcessor. However, in that case, the authenticated user (and his
roles) will not be propagated through the ESB services as no AuthenticationRequest is set
on the ESB message. This has the big disadvantage that the ESB services themselves can not
be secured.
The attached code shows an implementation which is able to retrieve the username, digested
password, nonce and timestamp from within a JAX-WS endpoint. This data is used to create
an ESB AuthenticationRequest, where nonce and timestamp are set on the properties map. The
new UserDigestPasswordCallbackHandler is based on the UserPassCallbackHandler and is able
to retrieve the nonce and timestamp from the AuthenticationRequest and make them availble
to the UsernameTokenCallback.
This solution provides the ability to propagate the original user and his roles through
the entire services chain. It also allows the ESB services to use the same security-domain
configuration as the JAX-WS endpoint.
I'm aware that the JAX-WS endpoint code might be hard to include in the ESB platform
itself, but, if it can not be included in a default component, it might be a nice idea to
include this example in one of the quickstarts.
The 'application-policy' used in this setup is the setup from the Web Services
chapter in the JBoss EAP 5.1 Administration and Configuration Guide:
<application-policy name="jbossws-domain">
<authentication>
<login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">
<module-option
name="usersProperties">props/jbossws-domain-users.properties</module-option>
<module-option
name="rolesProperties">props/jbossws-domain-roles.properties</module-option>
<module-option name="hashAlgorithm">SHA</module-option>
<module-option
name="hashEncoding">BASE64</module-option>
<module-option
name="hashUserPassword">false</module-option>
<module-option
name="hashStorePassword">true</module-option>
<module-option
name="storeDigestCallback">org.jboss.ws.extensions.security.auth.callback.UsernameTokenCallback</module-option>
</login-module>
</authentication>
</application-policy>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira