Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 770D3200B31 for ; Tue, 24 May 2016 15:47:41 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 75E71160A35; Tue, 24 May 2016 13:47:41 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 90F9316098E for ; Tue, 24 May 2016 15:47:40 +0200 (CEST) Received: (qmail 21986 invoked by uid 500); 24 May 2016 13:47:39 -0000 Mailing-List: contact commits-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list commits@cxf.apache.org Received: (qmail 21977 invoked by uid 99); 24 May 2016 13:47:39 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 May 2016 13:47:39 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 5E094C0BBB for ; Tue, 24 May 2016 13:47:39 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 2AaPIwqh-dTF for ; Tue, 24 May 2016 13:47:37 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id F307E5FAF2 for ; Tue, 24 May 2016 13:47:36 +0000 (UTC) Received: from svn01-us-west.apache.org (svn.apache.org [10.41.0.6]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 0F653E009C for ; Tue, 24 May 2016 13:47:35 +0000 (UTC) Received: from svn01-us-west.apache.org (localhost [127.0.0.1]) by svn01-us-west.apache.org (ASF Mail Server at svn01-us-west.apache.org) with ESMTP id 1E61E3A01DD for ; Tue, 24 May 2016 13:47:35 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 -0000 To: commits@cxf.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20160524134735.1E61E3A01DD@svn01-us-west.apache.org> archived-at: Tue, 24 May 2016 13:47:41 -0000 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

 

 

+/*]]>*/

The above code produces a JWS JSON sequence containing two signatures, similarly to this example. 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 flattened 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. 

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.

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.

JWS with Detached Content

JWS with a Detached Content provides a way to integrity-protect some data without actually having these data included in the resulting JWS sequence.

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.      

JWS with Unencoded Payload

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. 

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.

Thus a JWS with Unencoded Payload 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 this example.

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.

In CXF you can apply this option to both JWS Compact and JWS JSON sequences, here is a JWS JSON code fragment:

 

JWS JSON Unencoded
+

The above code produces a JWS JSON sequence containing two signatures, similarly to this example. 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 flattened 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. 

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.

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.

JWS with Detached Content

JWS with a Detached Content provides a way to integrity-protect some data without actually having these data included in the resulting JWS sequence.

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.      

JWS with Unencoded Payload

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. 

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.

Thus a JWS with Unencoded Payload 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 this example.

Both JWS JSON and JWS Compact support 'b64' property.

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:

 

JWS JSON Unencoded
JwsJsonProducer producer = new JwsJsonProducer(UNSIGNED_PLAIN_JSON_DOCUMENT, true);
 JwsHeaders headers = new JwsHeaders(SignatureAlgorithm.HS256);
 headers.setPayloadEncodingStatus(false);