Hi,
On 26/04/12 22:35, Sergey Beryozkin wrote:
On 18/04/12 11:35, semecxf wrote:
Sergey,
useReqSigCert works fine ws security, it is pretty cool feature.
I guess sgining and encryption are kind of useless if it can't support
useReqSigCert because it can't handle multiple clients(users).
Yes, I can see the encryption on the server out-bound channel does not
work really well when the signature & encryption is expected to work
both ways. What happens is that the server out signature interceptor
will sign the out payload using the same certs that were used to
validate the in signature - that is using the client certs, and then
encrypt the data using the server cert.
Actually, that was a test configuration issue
With "useReqSigCert" we have something like this:
<entry key="ws-security.encryption.properties"
value="serviceKeystore.properties"/>
<entry key="ws-security.signature.properties"
value="serviceKeystore.properties"/>
<entry key="ws-security.encryption.username" value="useReqSigCert"/>
I've got a bit confused today how having these properties can be
sufficient on the server side to do:
1. decrypt the encryption key with the receiver cert (+ decrypt the
payload)
2. validate the in signature
3. create the out signature
4. Encrypt the out encryption key with the client cert
4 is easy - the client cert is available from the inbound signature.
In WS case, which properties are used to complete 1, 2, 3 ?
I'm assuming that "ws-security.encryption.properties" will help with 1.
"ws-security.signature.properties" - with 2.
Then on the out side, it must be "ws-security.encryption.properties"
(which will point to the server cert) that will have to be used to
create the out signature, right ?
The way it works for WS endpoints (on the server side) is as follows,
WSS4J uses encryption properties to validate the in signature and create
the out signature and either the signature properties or the client
certificate in the in signature (useReqSigCert) to encrypt the payload;
signature properties are also used to decrypt the in payload.
This is confusing but technically it makes a perfect sense, given that
the client uses a receiver cert to encrypt and this receiver cert needs
to be used to sign the data on the response...Similarly for the client
acting as a receiver, its certificate is expected to used to encrypt the
response...
I updated the rs security code to support the same more for 2 way
requests [1]
Sergey
[1] https://issues.apache.org/jira/browse/CXF-4274
Cheers, Sergey
--
View this message in context:
http://cxf.547215.n5.nabble.com/Rest-Service-Signing-and-Encryption-tp5644617p5648765.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
