Re: CXF v3.2.7 and WS-SecurityPolicy API clarification
Thank you for the quick response!
I'm still a novice when it comes to Java, so please forgive this newbie
question. Do I convert the .properties file to a String, or can I just
reference the file? If I can just do a reference, do I just include the
file in the class path? Thank you!
> Thank you for the quick response!
> I'm still a novice when it comes to Java, so please forgive this newbie
> question. Do I convert the .properties file to a String, or can I just
> reference the file? If I can just do a reference, do I just include the
> file in the class path? Thank you!
> Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html >
Den fre. 8. feb. 2019 kl. 15:59 skrev Anders Rundgren <
> On 2019-02-08 15:27, David Karlsen wrote:
> > Cxf 3.3 included support for
> > https://tools.ietf.org/html/draft-cavage-http-signatures-09 >
> Thanx! I got that from Colm's answer as well.
> Personally I find HTTP Signatures as a rather strange mix between
> signed messaging and authentication.
> Amazon use a similar scheme but without authentication requests:
> https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html >
> In a REST context I do not really see the need for signing header
> data with the exception of HTTP Method and URI. If you need (signed)
> x-headers you might as well declare such data at the JSON level.
> Anyway, none of the Cxf methods support "Signed JSON", only JSON
> embedded in packages of varying obscurity. But that is not due
> to any shortcomings in Cxf, but to a lack of standards.
> That's at least what I'm claiming and trying to fix :-)
> The core signature scheme (without specific REST bindings) can be
> tried out online if you want: https://mobilepki.org/jws-jcs/home >
> > Den fre. 8. feb. 2019, 08:27 skrev Anders Rundgren <
> > [hidden email]>:
> >> Since there is no IETF standard for signing REST requests and no
> >> such activity in progress either, I took the liberty outlining
> >> a minimalist proposal:
> https://github.com/cyberphone/json-canonicalization/blob/master/REST.signatures.md > >>
> >> Comments are as always welcome!
> >> Anders
Right, current systems supporting "signed JSON" do that by embedding the JSON data in Base64Url or feature it in clear in a HTTP body with a detached signature in an HTTP header.
The stuff I'm and a few other people are working on makes signatures a part of a JSON object itself allowing you to
- serialize the object into a database
- transfer/proxy the object using any kind of mechanism
- embed the object in another JSON object (counter signing)
- use the object in an HTML page
while keeping the signature and the JSON object intact.