WS-Security docs in progress

[Arjen Poutsma]

Hi,

Obviously, you all want to try out the new WS-Security support that was added to Spring-WS in release 1.0 M1. However, security is no simple beast, and WS-Security is not different at that.

So I've started working on a chapter in the reference documentation which tries to explain WS-Security, and how to use it within Spring-WS. It only covers plain text passwords now, but I will try and fill in more topics later this week.

I've uploaded new versions of the reference docs, which can be found here: HTML version, PDF version. It's chapter four.

Enjoy!

[res1st]

That's great Arjen.

Ingo

[Arjen Poutsma]

I've updated the docs once again. They now cover authenticatiton & signatures. Still to do: encryption and decryption, but that shouldn't take too long.

[res1st]

Very nice.

4.4.2. Digest Username Authentication
[...] The difference is that the password is not sent as plain text, but as a digest.The recipient compares this digest to the digest he calculated from the known password of the user, and if they are the same, the user is authenticated

My CallbackHandler on the client returns the plain password. I assume the processor will generate the digest and add it to the soap message. That's ok.

But on the server, the UserDetails object contains also the plain password(airline example). I think an ACEGI class will generate the digest for the password stored in the UserDetails object.

But i think it is very uncommon, because the database will only store the digest of the password and not the password itself. That's why the DAO returns already the digest and the UserDetails object will contain the digest. But if i an ACEGI class generate a digest of a digest it won't be equal to the digest which was send by the client.
I hope you understand my problem.

Cheers,

Ingo

[Arjen Poutsma]

Very nice.

Thanks!

But on the server, the UserDetails object contains also the plain password(airline example). I think an ACEGI class will generate the digest for the password stored in the UserDetails object.

But i think it is very uncommon, because the database will only store the digest of the password and not the password itself. That's why the DAO returns already the digest and the UserDetails object will contain the digest. But if i an ACEGI class generate a digest of a digest it won't be equal to the digest which was send by the client.
I hope you understand my problem.

If you look at the documentation for the Acegi HTTP DigestProcessingFilter, you will read that:

The configured UserDetailsService is needed because DigestProcessingFilter must have direct access to the clear text password of a user. Digest Authentication will NOT work if you are using encoded passwords in your DAO.

So the behavior for digest passwords in Spring-WS is pretty much the same as when using the HTTP Acegi DigestProcessingFilter.

Cheers,

[res1st]

I just read in wss-v1.1-spec-os-UsernameTokenProfile.pdf.

Note that PasswordDigest can only be used if the plain text password equivalent) is available to both the requestor and the recipient.

If i understand it right, that PasswordText can also include a digest value.

It's also possible to use the PasswordDigest for passwords which are already stored as a hash value. But it make sense to create a digest of the hash value, because the digest includes the nonce+created value.

Cheers,

Ingo

[Arjen Poutsma]

The security docs are now finished. If you find an error or improvement, let me know.