Hi
On 06/01/12 20:40, VirtuallyReal wrote:
Can you explain please a bit how do you attach an entity signature in
case of files and POJOs; I'm presuming that in the former case it is
another (multi)part but what about the latter ?
The reason I ask is that in CXF 2.5.0 we offer some initial support for
signing XML payloads, see:
http://cxf.apache.org/docs/jax-rs-xml-security.html#JAX-RSXMLSecurity-XMLSignature
Sure thing. Actually there were a few changes since I sent the earlier message.
I am able to extract the response and add headers to it, but I am getting some
other issues, which I will come to later.
I put two outgoing message interceptors. The first one is (similar to
org.apache.cxf.interceptor.LoggingOutInterceptor), puts a specialized (pass
through and cache) OutputStream and stores its address in the message with a
special key. This is done at a really early phase, I chose PREPARE_SEND.
The second interceptor comes into the picture in POST_MARSHAL. It first signs
the headers in a specific order and format, and puts the signature as a new
header in to the *RESPONSE*. Then it picks the stashed stream, extract its
content signing it, and that signature as well in the response. I am
highlighting the response, because at that point the headers are already
flushed to the response, and unless the new headers are put in there, they will
not be picked.
Finally, the closure of the stream added by the PREPARE_SEND interceptor
restores the original stream to its location.
Note that a POJO and a stream appear the same to the POST_MARSHAL interceptor.
As an optimization, I will store the signature of a file along with the file,
but that is just an optimization.
So, this way, I can put two signatures in headers (not multiparts). One for the
body, one for the headers itself.
I can see the advantage of putting the signatures into headers, it is
probably simpler for a client to deal with them this way.
The solution looks neat to me.
However I'd still consider providing some support for the enveloped
signatures on the server side, for POJOs...
What I can see from XML Sig or from the JWT effort or even Magic
signatures, the data payloads typically have the signatures enveloped.
Likewise, making it easy to get the signature shipped as a sibling
multipart would be of interest, for binary payloads.
The issue I am facing has changed since. I realized that when the POJO (not
that I have any), or the stream is larger than 64K (just because this is the
number I picked for my specialized stream), a portion of the message gets
flushed, the headers first (I.e., headers get committed). In that case,
attaching a signature for the content becomes impossible, since the headers are
gone before the signature is ready. I do not know what to do about it yet. I
have been looking into returning multipart, but could not find any example of
this. If I do find that, I can send the signature as another part of the
message. Any help there will be appreciated.
When you deal with file payloads, can you calculate the signature inside
the application code itself, given that the stream is cached anyway by
the custom interceptors and then use JAX-RS Response to set headers and
the InputStream or may be StreamingOutput as an entity ?
You can also consider returning a multipart, see this page for more info:
http://cxf.apache.org/docs/jax-rs-multiparts.html
Let me know how it goes please
Cheers, Sergey
As for the link you sent, I have not looked at it yet, but will do so right
after I send this message.
Thanks.
________________________________
From: Sergey Beryozkin-5 [via CXF]<[email protected]>
To: VirtuallyReal<[email protected]>
Sent: Thursday, January 5, 2012 12:35 AM
Subject: Re: Attaching digital signature to a server response
Hi,
On 05/01/12 01:44, VirtuallyReal wrote:
I am working on a system which will repond to client queries in clear-text,
to allow caching by proxies, CDNs, ISP and anyone who wishes to do so.
However, it is important for me to provide a way for end users to be able to
validate that the message content was not modified. So, I would like to sign
every response coming from the server.
The system is RESTful, so I am trying to use HTTP headers to communicate the
signature back. I am using tomcat 7.0.21 with CXF 2.4.1.
A response may have a erstream (file download), or a POJO (a serialized
object) as an entity, or may have no entity at all (redirection, or HEAD, or
...). In all these cases, I want to sign the headers in a certain order and
insert one header, and sign the entity (if there is one) and insert another
entity.
Can you explain please a bit how do you attach an entity signature in
case of files and POJOs; I'm presuming that in the former case it is
another (multi)part but what about the latter ?
The reason I ask is that in CXF 2.5.0 we offer some initial support for
signing XML payloads, see:
http://cxf.apache.org/docs/jax-rs-xml-security.html#JAX-RSXMLSecurity-XMLSignature
This works one way at the moment (from the client to the server), as
opposed to the encryption support. So I'd like to see what can we offer
at the CXF level to make the outbound signatures work too, for XML but
also for other payloads.
Actually, reading further, did you mean to say 'insert another header'
above ? Probably yes, still would be interested in your opinion as to
what can be generalized at the CXF level
In terms of implementation, I got it partially working. The implementation
injects a POST_MARSHAL out-interceptor generates the signatures and inserts
the headers of interest.
When the response does not include an entity, it works great. When there is
any body it does not work. Even though I add the signature, it is never sent
out.
After spending sometime debugging, I found the cause to be in the
org.apache.cxf.transport.http.AbstractHTTPDestination class. Even a POJO is
serialized into a stream, and when the first write happens the
onFirstWrite() method calls flushHeaders() which copies the headers as they
are prior to the marshalling. Since the signature is added in post_marshal,
it is never picked up.
For the case where there is no entity, since there is no first-write, the
headers are copied much later, and hence they make it out.
So, essentially the problem is boiled down to having the ability to re-flush
the headers, in the post_marshal phase, or at least to update the flushed
headers.
Couple questions:
- Is what I am doing reasonable? I would think this is a faced and solved
problem, but could not find any documentation to help me.
- Is there a (clean) way of extracting the coyoteResponse from a given
message and add headers to it.
This is how I handle this case in JAXRSOutInterceptor:
private boolean isResponseHeadersCopied(Message message) {
return
MessageUtils.isTrue(message.get(AbstractHTTPDestination.RESPONSE_HEADERS_COPIED));
}
and then
if (isResponseHeadersCopied) {
HttpServletResponse response =
(HttpServletResponse)message.get(AbstractHTTPDestination.HTTP_RESPONSE);
response.setStatus(status);
// or in your case, add some header
}
HTH, Sergey
Any help will be greatly appreciated.
--
View this message in context:
http://cxf.547215.n5.nabble.com/Attaching-digital-signature-to-a-server-response-tp5121287p5121287.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
