[SWS-426] Allow Wss4jSecurityInterceptor to accept arbitrary client certificate in validation phase Created: 05/Sep/08  Updated: 04/May/12  Resolved: 22/Sep/08

Status: Closed
Project: Spring Web Services
Component/s: Security
Affects Version/s: 1.5.4
Fix Version/s: 1.5.5

Type: New Feature Priority: Trivial
Reporter: Robert Novotny Assignee: Tareq Abedrabbo
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Wss4j 1.5.4



 Description   

Imagine a webservice which uses encrypted request and response message. Client can sign the message by its private key and attach its certificate which will be used on the server side to encrypt a response message. (This correspons to the Binary Security tokens or DirectReference option and can be achieved by setting "useReqSigCert" for securementEncryption user). However, Wss4j interceptor tries to validate the incoming client certificate against the Crypto specified in validationSignatureCrypto. Consequently, this requires a keystore which contains the client certificate, thus complicating client certificate management.

Wss4j could introduce an option which would accept arbitrary client certificate on validation.



 Comments   
Comment by Tareq Abedrabbo [ 14/Sep/08 ]

The problem is that Wss4j seems to be overzealous in its processing of ws-security headers. I'm not aware of a simple way of instructing it to ignore certificates.
However there seems to be a (rather complicated) workaround. You can write your own Wss4j signature processor. Then you can subclass Wss4jSecurityInetceptor, redefine the validateMessage method and pass your signature processor to the WSSecurityEngine instance (via an appropriate WSSConfig).
I'd be glad to know if there's a simpler solution.

Comment by Aleksander Adamowski [ 26/May/09 ]

As far as I've observed, it's enough to have the CA certificate present in server's keystore. It's not necessary to impoert all possible client certificates. That's what PKI is for.

So if you set up proper PKI, the issue is non existent.

On the other hand, if you don't have PKI and use self-signed client certificates, what good is such security?

If the server would trust any arbitrary certificate that the client would send in, then that wouldn't prove the identity od the sender in any way and beat the purpose of the whole signing mechanism.

The encryption mechanism's purpose would be beaten too, as a consequence of the fact that if you accept any certificate without validation, an attacker can mount man-in-the middle attacks against the encryption securement, so then the encryption doesn't offer any added security either.

So Robert, what you propose would effectively be not more secure than simply using no WS-Security whatsoever at all.

But it would be much more complex and require much more work to develop and maintain for a security layer which doesn't do its job.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sun Dec 17 15:47:52 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.