Author: buildbot
Date: Tue May 24 13:47:34 2016
New Revision: 989039
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 24 13:47:34
2016
@@ -119,11 +119,11 @@ Apache CXF -- JAX-RS JOSE
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><p> </p><p> </p><p><style
type="text/css">/*<![CDATA[*/
-div.rbtoc1464094020290 {padding: 0px;}
-div.rbtoc1464094020290 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1464094020290 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1464097621326 {padding: 0px;}
+div.rbtoc1464097621326 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1464097621326 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1464094020290">
+/*]]>*/</style></p><div class="toc-macro rbtoc1464097621326">
<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 </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>
@@ -271,7 +271,7 @@ String nextJwsJson = consumer.validateAn
// use WebClient to post nextJwsJson to the next consumer, with nextJwsJson
being nearly identical to the original
// double-signed JWS JSON signature, minus the signature which was already
validated, in this case nextJwsJson will
// only have a single signature </pre>
-</div></div><p>The above code produces a JWS JSON sequence containing two
signatures, similarly to <a shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7515#appendix-A.6.4"; rel="nofollow">this
example</a>. If the sequence contains a single signature only then the JWS JSON
'signatures' array will contain a single 'signature' element, or the whole
sequence can be <a shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7515#appendix-A.6.4";
rel="nofollow">flattened</a> instead with the actual 'signatures' array
dropped. JwsJsonProducer  does not produce the flattened sequence when
only a single signature is used by default because 3rd party JWS JSON consumers
may only be able to process the sequences with the 'signatures' array, so pass
a 'supportFlattened' flag to JwsJsonProducer if needed. </p><p>Does it
make sense to use JWS JSON if you do not plan to do multiple signatures ?
Indeed, if it is only a single signature then using JWS Co
mpact is a good alternative, likely to be used most often.</p><p>However, even
if you do a single signature, you may still want to try JWS JSON because is is
easier to observe the individual JWS JSON structure parts when, example,
checking the logs or TCP-tracing HTTP requests/responses. This is especially
true when we start talking about an unencoded payload option, see below.</p><h3
id="JAX-RSJOSE-JWSwithDetachedContent">JWS with Detached Content</h3><p><a
shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7515#appendix-F"; rel="nofollow">JWS with a
Detached Content</a> provides a way to integrity-protect some data without
actually having these data included in the resulting JWS sequence.</p><p>For
example, if the producer and consumer can both access the same shared piece of
data, then the producer can sign these data, post the JWS sequence (without the
data) to the consumer. The consumer will validate this JWS sequence and assert
the data have not been modifi
ed by the time it has received and started validating the sequence. JWS
Compact and JWS JSON Producer and Consumer provider constructors accept an
optional 'detached' flag in cases were it is required.    
 </p><h3 id="JAX-RSJOSE-JWSwithUnencodedPayload">JWS with Unencoded
Payload</h3><p>By default, JWS Compact and JWS JSON sequences have the data
first Base64Url encoded and then inlined in the resulting sequence. This is
useful especially for JWS Compact which is used in OAuth2/OIDC  flows to
represent the signed access or id tokens. </p><p>One concern around the
data being inlined is that it takes an extra time to Base64Url encode them
which may become noticeable with large payloads, and another one is that one
can not see the data while looking at JWS sequences in the logs or trace
screens.</p><p>Thus a <a shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7797"; rel="nofollow">JWS with Unencoded
Payload</a> option (JWS header 'b64' pr
operty set to false) has been introduced to let users configure JWS Signature
providers not to encode the actual data payload. As it happens it appears to be
most useful when JWS JSON sequences are produced, see <a shape="rect"
class="external-link" href="https://tools.ietf.org/html/rfc7797#page-7";
rel="nofollow">this example</a>.</p><p>Note that JWS Compact also
supports 'b64' property but only with the detached payloads. It is easier
to appreciate the value of disabling Base64Url encoding with JWS JSON as seen
in the example.</p><p>In CXF you can apply this option to both JWS Compact and
JWS JSON sequences, here is a JWS JSON code fragment:</p><p> </p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeHeader
panelHeader pdl" style="border-bottom-width: 1px;"><b>JWS JSON
Unencoded</b></div><div class="codeContent panelContent pdl">
+</div></div><p>The above code produces a JWS JSON sequence containing two
signatures, similarly to <a shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7515#appendix-A.6.4"; rel="nofollow">this
example</a>. If the sequence contains a single signature only then the JWS JSON
'signatures' array will contain a single 'signature' element, or the whole
sequence can be <a shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7515#appendix-A.6.4";
rel="nofollow">flattened</a> instead with the actual 'signatures' array
dropped. JwsJsonProducer  does not produce the flattened sequence when
only a single signature is used by default because 3rd party JWS JSON consumers
may only be able to process the sequences with the 'signatures' array, so pass
a 'supportFlattened' flag to JwsJsonProducer if needed. </p><p>Does it
make sense to use JWS JSON if you do not plan to do multiple signatures ?
Indeed, if it is only a single signature then using JWS Co
mpact is a good alternative, likely to be used most often.</p><p>However, even
if you do a single signature, you may still want to try JWS JSON because is is
easier to observe the individual JWS JSON structure parts when, example,
checking the logs or TCP-tracing HTTP requests/responses. This is especially
true when we start talking about an unencoded payload option, see below.</p><h3
id="JAX-RSJOSE-JWSwithDetachedContent">JWS with Detached Content</h3><p><a
shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7515#appendix-F"; rel="nofollow">JWS with a
Detached Content</a> provides a way to integrity-protect some data without
actually having these data included in the resulting JWS sequence.</p><p>For
example, if the producer and consumer can both access the same shared piece of
data, then the producer can sign these data, post the JWS sequence (without the
data) to the consumer. The consumer will validate this JWS sequence and assert
the data have not been modifi
ed by the time it has received and started validating the sequence. JWS
Compact and JWS JSON Producer and Consumer provider constructors accept an
optional 'detached' flag in cases were it is required.    
 </p><h3 id="JAX-RSJOSE-JWSwithUnencodedPayload">JWS with Unencoded
Payload</h3><p>By default, JWS Compact and JWS JSON sequences have the data
first Base64Url encoded and then inlined in the resulting sequence. This is
useful especially for JWS Compact which is used in OAuth2/OIDC  flows to
represent the signed access or id tokens. </p><p>One concern around the
data being inlined is that it takes an extra time to Base64Url encode them
which may become noticeable with large payloads, and another one is that one
can not see the data while looking at JWS sequences in the logs or trace
screens.</p><p>Thus a <a shape="rect" class="external-link"
href="https://tools.ietf.org/html/rfc7797"; rel="nofollow">JWS with Unencoded
Payload</a> option (JWS header 'b64' pr
operty set to false) has been introduced to let users configure JWS Signature
providers not to encode the actual data payload, see <a shape="rect"
class="external-link" href="https://tools.ietf.org/html/rfc7797#page-7";
rel="nofollow">this example</a>.</p><p>Both JWS JSON and JWS Compact support
'b64' property.</p><p>In CXF you can apply this option to both JWS Compact
(only for detached payloads at the moment) and JWS JSON sequences, here is a
JWS JSON code fragment:</p><p> </p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeHeader panelHeader pdl"
style="border-bottom-width: 1px;"><b>JWS JSON Unencoded</b></div><div
class="codeContent panelContent pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">JwsJsonProducer producer = new
JwsJsonProducer(UNSIGNED_PLAIN_JSON_DOCUMENT, true);
JwsHeaders headers = new JwsHeaders(SignatureAlgorithm.HS256);
headers.setPayloadEncodingStatus(false);
