[esb-issues] [JBoss JIRA] (JBESB-3723) Add support for WS-Security UsernameToken with digested password, nonces and timestamps.

[ https://issues.jboss.org/browse/JBESB-3723?page=com.atlassian.jira.plugin... ] Duncan Doyle updated JBESB-3723: -------------------------------- Description: 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 UserDigestPassCallbackHandler 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> was: 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