CXF v3.2.7 and WS-SecurityPolicy API clarification

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

CXF v3.2.7 and WS-SecurityPolicy API clarification

G.Dab
At the end of http://cxf.apache.org/docs/ws-securitypolicy.html it shows
using the API to configure the client properties when a WSDL uses
WS-SecurityPolicy.  What I'm not understanding is the following:

ctx.put("security.encryption.properties", properties);

How is the 'properties' value configured?  Is it referencing say a
client_sign.properties file as described on
http://cxf.apache.org/docs/ws-security.html ?  Any example would be
appreciated!  Thanks :)



--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Reply | Threaded
Open this post in threaded view
|

Re: CXF v3.2.7 and WS-SecurityPolicy API clarification

coheigea
Administrator
Yes it's a WSS4J Crypto properties file as in the ws-security page. See for
example:

https://github.com/apache/cxf/blob/master/systests/ws-security-examples/src/test/resources/alice.properties

Colm.

On Fri, Jan 25, 2019 at 5:36 PM G.Dab <[hidden email]> wrote:

> At the end of http://cxf.apache.org/docs/ws-securitypolicy.html it shows
> using the API to configure the client properties when a WSDL uses
> WS-SecurityPolicy.  What I'm not understanding is the following:
>
> ctx.put("security.encryption.properties", properties);
>
> How is the 'properties' value configured?  Is it referencing say a
> client_sign.properties file as described on
> http://cxf.apache.org/docs/ws-security.html ?  Any example would be
> appreciated!  Thanks :)
>
>
>
> --
> Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: CXF v3.2.7 and WS-SecurityPolicy API clarification

G.Dab
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
Reply | Threaded
Open this post in threaded view
|

Re: CXF v3.2.7 and WS-SecurityPolicy API clarification

coheigea
Administrator
Just the filename will do, so long as the properties file is on the
classpath. For example from the tests:

https://github.com/apache/cxf/blob/687dd36db702dd8a013d49c71fc4d3afe4323a0c/systests/ws-security-examples/src/test/resources/org/apache/cxf/systest/wssec/examples/x509/client.xml#L39

Colm.

On Fri, Jan 25, 2019 at 9:10 PM G.Dab <[hidden email]> wrote:

> 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
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: CXF v3.2.7 and WS-SecurityPolicy API clarification

G.Dab
Reply | Threaded
Open this post in threaded view
|

Signed REST Requests

Anders Rundgren
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
Reply | Threaded
Open this post in threaded view
|

Re: Signed REST Requests

coheigea
Administrator
Note that in CXF we support signing REST requests using XML Signature (
http://cxf.apache.org/docs/jax-rs-xml-security.html), JWS (
http://cxf.apache.org/docs/jax-rs-jose.html) + HTTP Signature.

Colm.

On Fri, Feb 8, 2019 at 7:27 AM Anders Rundgren <
[hidden email]> wrote:

> 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
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Signed REST Requests

Anders Rundgren
On 2019-02-08 10:57, Colm O hEigeartaigh wrote:
> Note that in CXF we support signing REST requests using XML Signature (
> http://cxf.apache.org/docs/jax-rs-xml-security.html), JWS (
> http://cxf.apache.org/docs/jax-rs-jose.html) + HTTP Signature.
Thanx!

The closest existing solution would then be:
http://cxf.apache.org/docs/jax-rs-jose.html#JAX-RSJOSE-JWSJSONwithUnencodedPayload

   {
     "payload" : "book",
     "signatures":
       [
         {
          "protected" : "eyJhbGciOiJIUzI1NiIsImN0eSI6InRleHQvcGxhaW4iLCJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdfQ",
          "signature" : "fM7O2IVO3NsQeTGrFiMeLf_TKTsMSqnqmjnK40PwQ88"
         }
      ]
   }

This is not entirely comparable to

   {
     "@rest.uri": "https://example.com/transact/pay",
     "@rest.verb": "POST",
     "something": "data",

        Additional properties

     "@rest.signature": "eyJhbGciOiJIUzI1NiJ9..VHVItCBCb8Q5CI-49imarDtJeSxH2uLU0DhqQP5Zjw4"
   }

since the unencoded solution is not supporting arbitrary JSON data, only a [pretty lame] "payload" element.
There seems to be no support for the other qualifiers of a REST request.

Anders.

>
> Colm.
>
> On Fri, Feb 8, 2019 at 7:27 AM Anders Rundgren <
> [hidden email]> wrote:
>
>> 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
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Signed REST Requests

David Karlsen
In reply to this post by Anders Rundgren
Cxf 3.3 included support for
https://tools.ietf.org/html/draft-cavage-http-signatures-09

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
>
Reply | Threaded
Open this post in threaded view
|

Re: Signed REST Requests

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

Cheers,
Anders


>
> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Signed REST Requests

David Karlsen
Signing headers is optional and . you can select which ones, see:
https://tools.ietf.org/html/draft-cavage-http-signatures-09#section-2.1.3
See section 3.1 where a digest is created from the body, to essentially
form a signature of the body and any other headers - this allows to sign
json - or any other mediatype.

Den fre. 8. feb. 2019 kl. 15:59 skrev Anders Rundgren <
[hidden email]>:

> 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
>
> Cheers,
> Anders
>
>
> >
> > 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
> >>
> >
>
>

--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Reply | Threaded
Open this post in threaded view
|

Re: Signed REST Requests

Anders Rundgren
On 2019-02-08 23:01, David Karlsen wrote:
> Signing headers is optional and . you can select which ones, see: https://tools.ietf.org/html/draft-cavage-http-signatures-09#section-2.1.3
> See section 3.1 where a digest is created from the body, to essentially form a signature of the body and any other headers - this allows to sign json - or any other mediatype.

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.

The signature scheme is not tied to HTTP.

May I ask what you think of https://github.com/cyberphone/json-canonicalization/blob/master/REST.signatures.md as a REST solution?

Anders



>
> Den fre. 8. feb. 2019 kl. 15:59 skrev Anders Rundgren <[hidden email] <mailto:[hidden email]>>:
>
>     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
>
>     Cheers,
>     Anders
>
>
>      >
>      > Den fre. 8. feb. 2019, 08:27 skrev Anders Rundgren <
>      > [hidden email] <mailto:[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
>      >>
>      >
>
>
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

Reply | Threaded
Open this post in threaded view
|

Failed building CXF

Anders Rundgren
In reply to this post by David Karlsen
Using the 3.3.0 version as well as the master mvn terminates with:

[ERROR] Errors:
[ERROR]   JCacheJWTOAuthDataProviderTest.testAddGetDeleteAccessToken:23->AbstractOAuthDataProviderTest.testAddGetDeleteAccessToken:148->AbstractOAuthDataProvide
rTest.validateAccessToken:370 » Jws
[ERROR]   JCacheJWTOAuthDataProviderTest.testAddGetDeleteAccessToken2:23->AbstractOAuthDataProviderTest.testAddGetDeleteAccessToken2:199->AbstractOAuthDataProvi
derTest.validateAccessToken:370 » Jws
[ERROR]   JCacheJWTOAuthDataProviderTest.testAddGetDeleteAccessTokenWithNullSubject:23->AbstractOAuthDataProviderTest.testAddGetDeleteAccessTokenWithNullSubject
:221->AbstractOAuthDataProviderTest.validateAccessToken:370 » Jws
[ERROR]   JCacheJWTOAuthDataProviderTest.testAddGetDeleteMultipleAccessToken:23->AbstractOAuthDataProviderTest.testAddGetDeleteMultipleAccessToken:243->Abstract
OAuthDataProviderTest.validateAccessToken:370 » Jws
[ERROR]   JCacheJWTOAuthDataProviderTest.testAddGetDeleteRefreshToken:23->AbstractOAuthDataProviderTest.testAddGetDeleteRefreshToken:274->AbstractOAuthDataProvi
derTest.validateAccessToken:370 » Jws
[INFO]
[ERROR] Tests run: 93, Failures: 0, Errors: 5, Skipped: 2

Anders
Reply | Threaded
Open this post in threaded view
|

Re: Failed building CXF

coheigea
Administrator
What versions of Java + Maven are you using?

Colm.

On Mon, Feb 11, 2019 at 10:46 AM Anders Rundgren <
[hidden email]> wrote:

> Using the 3.3.0 version as well as the master mvn terminates with:
>
> [ERROR] Errors:
> [ERROR]
>  JCacheJWTOAuthDataProviderTest.testAddGetDeleteAccessToken:23->AbstractOAuthDataProviderTest.testAddGetDeleteAccessToken:148->AbstractOAuthDataProvide
> rTest.validateAccessToken:370 » Jws
> [ERROR]
>  JCacheJWTOAuthDataProviderTest.testAddGetDeleteAccessToken2:23->AbstractOAuthDataProviderTest.testAddGetDeleteAccessToken2:199->AbstractOAuthDataProvi
> derTest.validateAccessToken:370 » Jws
> [ERROR]
>  JCacheJWTOAuthDataProviderTest.testAddGetDeleteAccessTokenWithNullSubject:23->AbstractOAuthDataProviderTest.testAddGetDeleteAccessTokenWithNullSubject
> :221->AbstractOAuthDataProviderTest.validateAccessToken:370 » Jws
> [ERROR]
>  JCacheJWTOAuthDataProviderTest.testAddGetDeleteMultipleAccessToken:23->AbstractOAuthDataProviderTest.testAddGetDeleteMultipleAccessToken:243->Abstract
> OAuthDataProviderTest.validateAccessToken:370 » Jws
> [ERROR]
>  JCacheJWTOAuthDataProviderTest.testAddGetDeleteRefreshToken:23->AbstractOAuthDataProviderTest.testAddGetDeleteRefreshToken:274->AbstractOAuthDataProvi
> derTest.validateAccessToken:370 » Jws
> [INFO]
> [ERROR] Tests run: 93, Failures: 0, Errors: 5, Skipped: 2
>
> Anders
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com