cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r1012318 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs-jose.html
Date Tue, 16 May 2017 14:47:41 GMT
Author: buildbot
Date: Tue May 16 14:47:41 2017
New Revision: 1012318

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/jax-rs-jose.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/jax-rs-jose.html
==============================================================================
--- websites/production/cxf/content/docs/jax-rs-jose.html (original)
+++ websites/production/cxf/content/docs/jax-rs-jose.html Tue May 16 14:47:41 2017
@@ -119,11 +119,11 @@ Apache CXF -- JAX-RS JOSE
            <!-- Content -->
            <div class="wiki-content">
 <div id="ConfluenceContent"><p>&#160;</p><p>&#160;</p><p><style
type="text/css">/*<![CDATA[*/
-div.rbtoc1494928023912 {padding: 0px;}
-div.rbtoc1494928023912 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1494928023912 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1494946025536 {padding: 0px;}
+div.rbtoc1494946025536 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1494946025536 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1494928023912">
+/*]]>*/</style></p><div class="toc-macro rbtoc1494946025536">
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSJOSE-Introduction">Introduction</a></li><li><a
shape="rect" href="#JAX-RSJOSE-MavenDependencies">Maven Dependencies</a></li><li><a
shape="rect" href="#JAX-RSJOSE-JavaandJCEPolicy">Java and JCE Policy&#160;</a></li><li><a
shape="rect" href="#JAX-RSJOSE-JOSEOverviewandImplementation">JOSE Overview and Implementation</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSJOSE-JWAAlgorithms">JWA
Algorithms</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWKKeys">JWK
Keys</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSSignature">JWS
Signature</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAX-RSJOSE-SignatureandVerificationProviders">Signature
and Verification Providers</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSCompact">JWS
Compact</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSJSON">JWS
JSON</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSwithDetachedContent">JWS
with Detached Content</a></li><li><a shape="rect" href="#JAX-RSJOSE-JWSwithUnencodedPayload">JWS
with Unencoded Payload</a></li></ul>
@@ -492,7 +492,7 @@ Payload:
       }
    ]
 }</pre>
-</div></div><p>The client code and server configuration is nearly identical
to a code/configuration needed to set up JWS Compact filters as shown above, simply replace
JwsWriterInterceptor/JwsClientResponseFilter with JwsJsonWriterInterceptor/JwsJsonClientResponseFilter
in the client code, and JwsContainerRequestFilter/JwsContainerResponseFilter with JwsJsonContainerRequestFilter/JwsJsonContainerResponseFilter</p><h2
id="JAX-RSJOSE-SigningandVerificationofHTTPAttachments">Signing and Verification of HTTP
Attachments</h2><p>The signing and verification of HTTP request and response attachments
is supported starting from CXF 3.1.12.</p><p>This feature does not buffer the
request and response attachment data and is completely streaming-'friendly'.</p><p>It
depends on&#160;<a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7515#appendix-F"
rel="nofollow">JWS with Detached Content</a> and&#160; <a shape="rect" class="external-link"
href="https://tools.ietf.org/html
 /rfc7797" rel="nofollow">JWS with Unencoded Payload</a> options as well as on the
newly introduced CXF <a shape="rect" href="http://cxf.apache.org/docs/jax-rs-multiparts.html#JAX-RSMultiparts-MultipartFilters">multipart
filters</a> and works as follows.</p><p>When request or response attachment
parts are about to be submitted to the Multipart serialization provider, JWS Multipart Output
Filter (<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartClientRequestFilter.java"
rel="nofollow">JwsMultipartClientRequestFilter</a> and/or <a shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartContainerResponseFilter.java"
rel="nofollow">JwsMultipartContainerResponseFilter</a>) initializes a <a shape="rect"
cla
 ss="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jws/JwsSignature.java"
rel="nofollow">JWSSignature</a> object. Next every parts's output stream is replaced
with the filtering output stream which updates the signature object on every write operation.
Finally this multipart filter adds one more attachment part to the list of the attachments
to be written - this part holds a reference to JWS Signature. When this last part is written,
JWSSignature produces the signature bytes which are encoded using either JWS Compact or JWS
JSON format, with the detached and unencoded content already being pushed to the output stream.</p><p>When
the attachment parts are about to be read by the Multipart deserialization provider, their
signature carried over in the last part will need to be verified. Just before the parts are
about to be read in order to be made available to the application code, JWS Multipa
 rt Input Filter (<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartContainerRequestFilter.java"
rel="nofollow">JwsMultipartContainerRequestFilter</a> and/or <a shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartClientResponseFilter.java"
rel="nofollow">JwsMultipartClientResponseFilter</a>) checks the last part and initializes
a <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jws/JwsVerificationSignature.java"
rel="nofollow">JWSVerificationSignature</a> object. Next for every attachment but
the last one it replaces the input stream with the filtering input stream which updates the
si
 gnature verification object on every read operation. Once all the data have been read it
compares the calculated signature with the received signature.</p><p>Note when
the attachments are accessed by the receiving application code, the read process will fail
to complete if the validation fails. For example, if the application code copies a given part's
InputStream to the disk then this copy operation will fail. For example:</p><p>&#160;</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+</div></div><p>The client code and server configuration is nearly identical
to a code/configuration needed to set up JWS Compact filters as shown above, simply replace
JwsWriterInterceptor/JwsClientResponseFilter with JwsJsonWriterInterceptor/JwsJsonClientResponseFilter
in the client code, and JwsContainerRequestFilter/JwsContainerResponseFilter with JwsJsonContainerRequestFilter/JwsJsonContainerResponseFilter</p><h2
id="JAX-RSJOSE-SigningandVerificationofHTTPAttachments">Signing and Verification of HTTP
Attachments</h2><p>The signing and verification of HTTP request and response attachments
is supported starting from CXF 3.1.12.</p><p>This feature does not buffer the
request and response attachment data and is completely streaming-'friendly'.</p><p>Note
that in some cases the data may need to be buffered on the receiver end.</p><p>It
depends on&#160;<a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7515#appendix-F"
rel="nofollow">JWS with Detached Content</
 a> and&#160; <a shape="rect" class="external-link" href="https://tools.ietf.org/html/rfc7797"
rel="nofollow">JWS with Unencoded Payload</a> options as well as on the newly introduced
CXF <a shape="rect" href="http://cxf.apache.org/docs/jax-rs-multiparts.html#JAX-RSMultiparts-MultipartFilters">multipart
filters</a> and works as follows.</p><p>When request or response attachment
parts are about to be submitted to the Multipart serialization provider, JWS Multipart Output
Filter (<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartClientRequestFilter.java"
rel="nofollow">JwsMultipartClientRequestFilter</a> and/or <a shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartContainerResponseFilter.java"
rel="
 nofollow">JwsMultipartContainerResponseFilter</a>) initializes a <a shape="rect"
class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jws/JwsSignature.java"
rel="nofollow">JWSSignature</a> object. Next every parts's output stream is replaced
with the filtering output stream which updates the signature object on every write operation.
Finally this multipart filter adds one more attachment part to the list of the attachments
to be written - this part holds a reference to JWS Signature. When this last part is written,
JWSSignature produces the signature bytes which are encoded using either JWS Compact or JWS
JSON format, with the detached and unencoded content already being pushed to the output stream.</p><p>When
the attachment parts are about to be read by the Multipart deserialization provider, their
signature carried over in the last part will need to be verified. Just before the parts are
  about to be read in order to be made available to the application code, JWS Multipart Input
Filter (<a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartContainerRequestFilter.java"
rel="nofollow">JwsMultipartContainerRequestFilter</a> and/or <a shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartClientResponseFilter.java"
rel="nofollow">JwsMultipartClientResponseFilter</a>) checks the last part and initializes
a <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jws/JwsVerificationSignature.java"
rel="nofollow">JWSVerificationSignature</a> object. Next for every attachment but
the last o
 ne it replaces the input stream with the filtering input stream which updates the signature
verification object on every read operation. Once all the data have been read it compares
the calculated signature with the received signature.</p><p>Note when the attachments
are accessed by the receiving application code, the read process will fail to complete if
the validation fails. For example, if the application code copies a given part's InputStream
to the disk then this copy operation will fail. For example:</p><p>&#160;</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">@POST
 @Path("/books")
 @Consumes("multipart/related")
@@ -512,7 +512,7 @@ public void uploadStreamMultipart(@Multi
 }
 
 </pre>
-</div></div><p>&#160;</p><p>Note that besides the signature
verification process, CXF offers some other indirect support for ensuring the attachment data
have not been affected. For example, <a shape="rect" href="http://cxf.apache.org/docs/jax-rs-multiparts.html#JAX-RSMultiparts-Readinglargeattachments">the
size of the attachments can be restricted</a>, and if the data stream is converted from
XML then the conversion process will be controlled by the secure XML parser.&#160;</p><p>However,
if the receiver starts acting immediately on the attachment's InputStream, for example, the
attachment data returned from the service to the client are streamed to a UI display which
can activate a script then it is important that a '<strong>bufferPayload</strong>'
property is enabled on either <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartContaine
 rRequestFilter.java" rel="nofollow">JwsMultipartContainerRequestFilter</a> or <a
shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartClientResponseFilter.java"
rel="nofollow">JwsMultipartClientResponseFilter</a>. It will ensure that the data
streams are validated first before the application gets an access to them. This property should
also be enabled if the multipart payload contains many attachment parts.</p><p>Here
is an example showing how a Book object (represented as an XML attachment on the wire) can
be secured.</p><p>Given this client code:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>&#160;</p><p>Note that besides the signature
verification process, CXF offers some other indirect support for ensuring the attachment data
have not been affected. For example, <a shape="rect" href="http://cxf.apache.org/docs/jax-rs-multiparts.html#JAX-RSMultiparts-Readinglargeattachments">the
size of the attachments can be restricted</a>, and if the data stream is converted from
XML then the conversion process will be controlled by the secure XML parser.&#160;</p><p>However,
if the receiver starts acting immediately on the attachment's InputStream, for example, the
attachment data returned from the service to the client are streamed to a UI display which
can activate a script then it is important that a '<strong>bufferPayload</strong>'
property is enabled on either <a shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartContaine
 rRequestFilter.java" rel="nofollow">JwsMultipartContainerRequestFilter</a> or <a
shape="rect" class="external-link" href="https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose-jaxrs/src/main/java/org/apache/cxf/rs/security/jose/jaxrs/multipart/JwsMultipartClientResponseFilter.java"
rel="nofollow">JwsMultipartClientResponseFilter</a>. It will ensure that the data
streams are validated first before the application gets an access to them.</p><p>The
'<strong>bufferPayload</strong>' property may also need be enabled if the multipart
payload contains many attachment parts. In this case, if the receiving code is written to
consume all the parts in the order different to the one the parts have been ordered in the
multipart payload or if the receiver code may optionally skip reading some of the parts, then
the '<strong>bufferPayload</strong>' property must be enabled.</p><p>Here
is an example showing how a Book object (represented as an XML attachment on the wire) can
be 
 secured.</p><p>Given this client code:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <pre class="brush: java; gutter: false; theme: Default" style="font-size:12px;">@Test
 public void testJwsJwkBookHMacMultipart() throws Exception {
     String address = "https://localhost:" + PORT + "/jwsjwkhmacSinglePart";



Mime
View raw message