WS-Security Websphere Configuration - websphere

Question

I'm trying to develop a web service that uses WS-Security using Websphere 7 and JAX-WS. Looking through some guides, it appears that I MUST create a application server user registry and maintain username/passwords inside of that server. Is there anyway to avoid having to create usernames in the server itself and somehow capture the header and do validation based upon another a custom security configuration like a single sign-on?
I'm able to create a handler to get the header, but when mustUnderstands is set to 1 in the request (which is mandatory), it gets rejected before my handler sees the message.
I'm only looking to use the UsernameToken part of WS-Security.
Any help is appreciated.
An example of my request
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" Id="unt_20">
<wsse:Username>some_username</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">some_password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
...body...
</soapenv:Body>
</soapenv:Envelope>
Is it possible to create a custom security implementation so I can use my existing user validation scheme?

Answer 1

It would appear that I can implement a custom user registry that can interact with the security implementation of my choice. A link to the IBM article:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tsec_useregistry.html

Answer 2

Another possible answer is to create a Trust Association Interceptor (TAI). This basically extends your current security.
Here is a useful link to get started:
http://www.ibm.com/developerworks/websphere/techjournal/0508_benantar/0508_benantar.html

Answer 3

You can use the out-of-box WS-Security runtime with policy/bindings to achieve this, but you must write custom code to override the default behavior of checking the user registry for UsernameTokens.
See this article for using your own authentication mechanism when consuming the UsernameToken:
Configuring a UsernameToken caller configuration with no registry interaction
See this article if you want to also create WebSphere credentials based on the user name in that token:
Replacing the authentication method of the UsernameToken consumer using a stacked JAAS login module

Answer 4

Can you elaborate on what you want to achieve?
The WAS Server needs to validate the username and password that comes in the header against its user registry (which could an LDAP, File based registry etc).
LTPA tokens (which are used by WebSphere and related products for SSO) can be used too.
If you spell out your requirements, folks here will be able to help you out.
HTH
Manglu

Answer 5

JAX-WS should allow you to have a custom interceptor.
Take a look at this spring config to see how I have added an interceptor to the service endpoint.
<jaxws:endpoint id="pqdws"
implementor="#Atypon"
address="/pqdws"
publishedEndpointUrl="#ws_webapp_url_ext#">
<jaxws:properties>
<entry key="exceptionMessageCauseEnabled" value="true"/>
<entry key="Content-length"
</jaxws:properties>
<jaxws:inInterceptors>
<bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
<constructor-arg>
<map>
<entry key="action" value="UsernameToken"/>
<entry key="passwordType" value="PasswordText"/>
<entry key="passwordCallbackRef">
<ref bean="passwordCallback"/>
</entry>
</map>
</constructor-arg>
</bean>
</jaxws:inInterceptors>
</jaxws:endpoint>
<bean id="passwordCallback"
class="access.ws.ServerPasswordCallback">
<property name="username" value="#ws_sec_username#"/>
<property name="password" value="#ws_sec_password#"/>
</bean>
The interceptor can then do whatever you wish including calling out to an external service for authentication.