cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r989039 - in /websites/production/cxf/content: cache/docs.pageCache docs/jax-rs-jose.html
Date Tue, 24 May 2016 13:47:34 GMT
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>&#160;</p><p>&#160;</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&#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>
@@ -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 &#160;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.&#160;</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. &#160; &#160; &#160;</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 &#160;flows to represent the signed
access or id tokens.&#160;</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&#160;'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>&#160;</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 &#160;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.&#160;</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. &#160; &#160; &#160;</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 &#160;flows to represent the signed
access or id tokens.&#160;</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>&#160;</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);



Mime
View raw message