WSS4J-based WS-Security implementation [SWS-207]

[gregturn]

Arjen Poutsma opened SWS-207 and commented

The current implementation of WS-Security is based on SUN's XWSS, which requires SUN's JDK 1.5. This means that it cannot be used on WebSphere, for instance.

There is an alternative WS-Security implementation called WSS4J (http://ws.apache.org/wss4j/). We can use this library to build an alternative WS-Security implementation, which does not require SUN's Java 5.

---

Attachments:

• SWS-207.jar (104.46 kB)
• SWS-207.jar (104.03 kB)
• SWS-207.jar (88.70 kB)
• SWS-207.jar (78.67 kB)
• SWS-207.jar (66.04 kB)
• SWS-207.jar (55.53 kB)
• SWS-207.jar (44.64 kB)
• SWS-207.jar (27.93 kB)
• SWS-207.jar (17.24 kB)
• SWS-207.jar (13.77 kB)
• SWS-207.jar (10.35 kB)
• SWS-207.jar (9.07 kB)
• SWS-207.jar (9.07 kB)
• SWS-207.zip (49.90 kB)

Issue Links:

• Add removeHeaderElement(QName) to SoapHeader [SWS-272] #429 Add removeHeaderElement(QName) to SoapHeader
  ("depends on")
• Document Wss4jInterceptor [SWS-282] #439 Document Wss4jInterceptor
  ("is depended on by")

Referenced from: commits 8efae9f, a0c18b6, dc6b149, 671683b, 915cd94, 53fea29

16 votes, 7 watchers

[gregturn]

Chad Hahn commented

I'd like to see this get done and I'd be willing to help out. Is this already started or what is the status on this?

[gregturn]

Arjen Poutsma commented

Great! It's not started yet; it's not even planned yet, but it would be great to get it before 1.1

I suggest looking at the given link, and this one: http://ws.apache.org/wss4j/api.html

The extension point in SWS will probably be: http://static.springframework.org/spring-ws/site/apidocs/org/springframework/ws/soap/security/AbstractWsSecurityInterceptor.html

Let me know if you need any more help

[gregturn]

Nakul Bhuwalka commented

No comments have been added for a while. It would be a great help to know if someone is already working on this.

[gregturn]

Arjen Poutsma commented

I really would appreciate somebody working on this, since my TODO-list for version 1.5 is already pretty full.

[gregturn]

Tareq Abedrabbo commented

I've implemented a limited support for wss4j. For the moment it only contains support for Username token, a SimplePasswordValidationCallbackHandler and an AcegiPlainTextPasswordValidationCallbackHandler. I tried to mime Xwss behavior in Spring-WS as closely as possible. I tested it with both Saaj and Axiom message factories.
Here's a configuration example:
<bean id="wsSecurityInterceptor" class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
<property name="callbackHandler">
<bean class="org.springframework.ws.soap.security.wss4j.callback.SimplePasswordValidationCallbackHandler">
<property name="users">
<props>
<prop key="bob">hotdog</prop>
</props>
</property>
</bean>
</property>
<property name="secureResponse" value="false"/>
<property name="validateRequest" value="true"/>
</bean>

or

<bean id="wsSecurityInterceptor" class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor ">
    <property name="callbackHandler">
        <bean class="org.springframework.ws.soap.security.wss4j.callback.acegi.AcegiPlainTextPasswordValidationCallbackHandler">
            <property name="authenticationManager">
                <bean class="org.acegisecurity.MockAuthenticationManager"></bean>
            </property>
        </bean>
    </property>
    <property name="secureResponse" value="false"/>
    <property name="validateRequest" value="true"/>
</bean>

It is still rough and incomplete. It could certainly use some more work. I hope you find it useful.

[gregturn]

Arjen Poutsma commented

Great! I will take a look at it as soon as possible.

[gregturn]

Tareq Abedrabbo commented

Update:

• Improved the implementation of Wss4jSecurityInterceptor and the callback handlers
• added support for configuration of Wss4jSecurityInterceptor via actions (2 actions supported: UsernameToken and NoSecurity) with the appropriate validations:
  <bean id="wsSecurityInterceptor" class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
  <property name="action" value="UsernameToken"/>
  <property name="callbackHandler">
  <bean class="org.springframework.ws.soap.security.wss4j.callback.SimplePasswordValidationCallbackHandler">
  <property name="users">
  <props>
  <prop key="bob">hotdog</prop>
  </props>
  </property>
  </bean>
  </property>
  <property name="secureResponse" value="false"/>
  <property name="validateRequest" value="true"/>
  </bean>
• WSS4J validates timestamp headers out of the box :)
  <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
  <wsu:Timestamp wsu:Id="Timestamp-2157164" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  wsu:Created2007-11-20T22:17:11.940Z</wsu:Created>
  wsu:Expires2007-11-20T22:18:11.940Z</wsu:Expires>
  </wsu:Timestamp>
  </wsse:Security>

[gregturn]

Tareq Abedrabbo commented

Sorry. I attached the wrong file. Here's the new one.

[gregturn]

Arjen Poutsma commented

Thanks, Tareq. It will surely make its way into 1.5.

I have request: can you please give me the guarantee that the code that you attached can be released under the Apache License 2.0?

[gregturn]

Tareq Abedrabbo commented

No problem. The code can be released under the Apache License 2.0. Would you like me to include the license in the header of each file?
BTW, I'd like to work on it some more to add features/doc/comments ...

[gregturn]

Arjen Poutsma commented

Ok, cool. Adding the license would help, saves me some work, and also makes our lawyers happy. (Yes, I hate this legal stuff just as much as the next guy, but it's important to get it right).

I've taken a look at the code, and I think we can make this work. Some remarks:

• I'd like to see no dependencies between the wss4j package and the xwss package. If that means moving some classes from org.springframework.ws.soap.security.xwss.callback to a generic package like org.springframework.ws.soap.security.callback, that's fine with me. As long as we keep the public API in the xwss package the same. For instance, the AbstractCallbackHandler can be moved to org.springframework.ws.soap.security.callback. Also, we could create some abstract base classes in that package for stuff shared between xwss and wss4j. I can do this, if you want to.

• I am a bit confused by WSS4J's callback mechanism. If I read the Javadoc correctly, the role of the handler of WSPasswordCallbacks is to supply passwords and other credentials. That would suggest that the approach should be to put the password in the callback, but your code gets the password from this callback. I wonder how this should work?

[gregturn]

Tareq Abedrabbo commented

• Ok for the license. I'll take care of it soon.

• I'm aware that should be no dependencies between wss4j and xwss. I used AbstractCallbackHandler as a quick start. I thought about the refactoring you described but maybe we need a specialized base class for wss4j call handlers (maybe a subclass of a common AbstractCallbackHandler?). If you noticed there's a pattern that is occuring in the 2 callback handlers I implemented, mainly the following test:
  passwordCallback.getUsage() == WSPasswordCallback.USERNAME_TOKEN_UNKNOWN
  As the common part is going to grow as more usages are added, I thought I'd postpone the refactoring a bit till a clearer patterns emerges. What do you think?

• I was confused too about the callback mechanism. Reading through the code and the documentation here's what I found out:
  The callback handler should test the usage. if it the password is Digest then the callback handler must delegate the processing to the engine. If the password is plain text or any other type (usage = WSPasswordCallback.USERNAME_TOKEN_UNKNOWN that's why I added the test) then the callback handler is responsible for the authentication process and should throw an IOException or UnsupportedCallbackException to express failure.

from the WSPasswordCallback javadoc:
"USERNAME_TOKEN_UNKNOWN - either an not specified password type or a password type passwordText. In these both cases only the password variable is set. The callback class now may check if the username and password match. If they don't match the callback class must throw an exception. The exception can be a UnsupportedCallbackException or an IOException."

from UsernameTokenProcessor.handleUsernameToken javadoc:
"Check the UsernameToken element. Depending on the password type contained in the element the processing differs. If the password type is password digest (a hashed password) then process the password commpletely here. Use the callback class to get a stored password perform hash algorithm and compare the result with the transmitted password."

Is my understanding correct?

[gregturn]

Tareq Abedrabbo commented

Update:

• Improved the implementation of the interceptor
• Added support for digest passwords
• Added support for signatures
• Supported actions: UsernameToken, Timestamp, Signature

Remarks:
-I'm only working on SimplePasswordValidationCallbackHandler for the moment so AcegiPlainTextPasswordValidationCallbackHandler is out of date

• Signature verification fails with axiom messages

Here's how the configuration looks like:
<bean id="wsSecurityInterceptor" class="org.springframework.ws.soap.security.wss4j.Wss4jSecurityInterceptor">
<property name="action" value="UsernameToken Timestamp Signature"/>
<property name="signatureCryptoProperties">
<props>
<prop key="org.apache.ws.security.crypto.provider">org.apache.ws.security.components.crypto.Merlin</prop>
<prop key="org.apache.ws.security.crypto.merlin.keystore.type">jks</prop>
<prop key="org.apache.ws.security.crypto.merlin.keystore.password">123456</prop>
<prop key="org.apache.ws.security.crypto.merlin.file">c:/keystore</prop>
</props>
</property>
<property name="callbackHandler">
<bean class="org.springframework.ws.soap.security.wss4j.callback.SimplePasswordValidationCallbackHandler">
<property name="passwordDigestRequired" value="true"/>
<property name="users">
<props>
<prop key="bob">hotdog</prop>
</props>
</property>
</bean>
</property>
<property name="secureResponse" value="false"/>
<property name="validateRequest" value="true"/>
</bean>

[gregturn]

Arjen Poutsma commented

Bean config looks good.

One thing I would change - if possible - is to make the crypto props another bean definition, rather than using <props>, which doesn't look very nice.

However, most people will use the Merlin implementation anyway, since that's built into the JDK since 1.4.

[gregturn]

Tareq Abedrabbo commented

you're right, the properties are rather ugly. Are you suggesting replacing signatureCryptoProperties with signatureCrypto so that something like the following could be written?

<property name="signatureCrypto">
<bean class="org.apache.ws.security.components.crypto.CryptoFactory" factory-method="getInstance">
<constructor-arg value="signatureCrypto.properties"/>
</bean>
</property>