SOAP OAuth in CXF 2.7

[matteo <ma...@gmail.com>]

I would like to integrate OAuth into Apache CXF 2.7 SOAP API endpoints. Is it
possible? 

The question has been already asked in 2010
(http://cxf.547215.n5.nabble.com/CXF-and-OAuth-td566443.html) and the answer
was somehow "work in progress". 

Two options were presented as possible future implementations: 
1. HttpConduit redirection customization
2. Disable the redirection at the HttpConduit level and deal with it at the
CXF interceptor level

In case no off-the-shelf solution in cxf for SOAP OAuth is available, could
you please point me out a couple of examples how to deal with scenario 1 and
2 above? Or at least a hint where I could start implementing these
approaches?

Thanks



-----
matteo
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-OAuth-in-CXF-2-7-tp5723286.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: SOAP OAuth in CXF 2.7

[Sergey Beryozkin <sb...@gmail.com>]

Hi,
On 18/02/13 16:39, matteo wrote:
> Hi Sergey,
> Actually I'm referring to OAuth 2. Requirements are the following:
>
> I have a client application C that must invoke remote WS "on behalf of" a
> specific user (the resource owner). The remote WS endpoints are served by
> the resource server (powered by CXF). I would like to apply the OAuth flow
> to let C consume the remote WS on behalf of User:
>
>
> here I would use "user/C" key material to establish interaction 1 and "C/WS
> Server" key material to establish interaction 2. ACTION in interaction 1
> could be a selection in a Graphic User Interface.
>
> C should present the WS Server with an appropriate access token that grants
> him access to the requested resource. I'm still defining the nature of this
> access token: as far as I understand, a bearer token would be perfectly ok.
>
Thanks for the above info, sure, using a bearer token should do well for 
this scenario, 1 to 1 mapping with the WS Sec Binary token.

IMHO, when we talk about using OAuth2 in context of WS client-server 
invocations, we do not talk about the grants and the exchange of grants 
for access tokens. It is really about using access tokens as 
authentication/and authorization tokens for the purpose of WS Clients 
accessing WS servers.

The actual token is obtained out of band and in this case we can 
probably assume RO uses GUI, for example, to get an access token with a 
resource owner credential grant.

> The points for me to understand here are:
> - To what extent CXF can help me when dealing with access token management
> and authorization grants (access token generation, access token expiration,
> renewal, withdrawal of authorization grants, etc)

This is supported with CXF OAuth2 Access Token Service and, when needed, 
Authorization service:

http://cxf.apache.org/docs/jax-rs-oauth2.html

> - How to interact with CXF during grants and tokens validation (something
> like interceptors)

Please check the documentation - I guess GUI can invoke directly on 
Access token service and request a token

> - The Authorization Code flow as described at the paragraph 1.3.1 in rfc6749
> seems hard to implement in SOAP world: what is the best way to establish an
> Authorization Code for C and generate access tokens in SOAP paradigm? I
> understand that this latter point has nothing to do with CXF and for sure
> requires some further investigation on my side. Nevertheless, it would be
> very interesting to know how CXF team is planning to implement this aspect
> :)
>
Well, I'm not sure it needs to be, the authorization grant is well 
supported now in CXF (and other grants too), as well as the process of 
the grant to token exchange, IMHO, it's out of WS path,

What we can do, at least this is what I can think of, is to provide a 
simple WS server filter, which will read WS-Security binary token and 
will use CXF OAuth2 AccessTokenValidator to connect to OAuth2 server and 
validate the token, this should really be it, on the client side this 
token will be embedded into WS-Sec payload the usual WS way

> I hope this clarify the context.
>
> By the way, the reason why I want to use OAuth here is that I have also
> restful endpoints and I would like to adopt a sort of "uniform authorization
> scheme" across all e.p. (both SOAP and REST).
>
Sounds like an interesting plan
thanks, Sergey

> Thank you
>
>
>
> -----
> matteo
> --
> View this message in context: http://cxf.547215.n5.nabble.com/SOAP-OAuth-in-CXF-2-7-tp5723286p5723330.html
> Sent from the cxf-user mailing list archive at Nabble.com.


-- 
Sergey Beryozkin

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

Blog: http://sberyozkin.blogspot.com

Re: SOAP OAuth in CXF 2.7

[matteo <ma...@gmail.com>]

Hi Sergey,
Actually I'm referring to OAuth 2. Requirements are the following:

I have a client application C that must invoke remote WS "on behalf of" a
specific user (the resource owner). The remote WS endpoints are served by
the resource server (powered by CXF). I would like to apply the OAuth flow
to let C consume the remote WS on behalf of User:


here I would use "user/C" key material to establish interaction 1 and "C/WS
Server" key material to establish interaction 2. ACTION in interaction 1
could be a selection in a Graphic User Interface.

C should present the WS Server with an appropriate access token that grants
him access to the requested resource. I'm still defining the nature of this
access token: as far as I understand, a bearer token would be perfectly ok. 

The points for me to understand here are: 
- To what extent CXF can help me when dealing with access token management
and authorization grants (access token generation, access token expiration,
renewal, withdrawal of authorization grants, etc)
- How to interact with CXF during grants and tokens validation (something
like interceptors)
- The Authorization Code flow as described at the paragraph 1.3.1 in rfc6749
seems hard to implement in SOAP world: what is the best way to establish an
Authorization Code for C and generate access tokens in SOAP paradigm? I
understand that this latter point has nothing to do with CXF and for sure
requires some further investigation on my side. Nevertheless, it would be
very interesting to know how CXF team is planning to implement this aspect
:)

I hope this clarify the context.

By the way, the reason why I want to use OAuth here is that I have also
restful endpoints and I would like to adopt a sort of "uniform authorization
scheme" across all e.p. (both SOAP and REST).

Thank you



-----
matteo
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-OAuth-in-CXF-2-7-tp5723286p5723330.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: SOAP OAuth in CXF 2.7

[Sergey Beryozkin <sb...@gmail.com>]

On 17/02/13 21:28, matteo wrote:
> I would like to integrate OAuth into Apache CXF 2.7 SOAP API endpoints. Is it
> possible?
>
> The question has been already asked in 2010
> (http://cxf.547215.n5.nabble.com/CXF-and-OAuth-td566443.html) and the answer
> was somehow "work in progress".
>
> Two options were presented as possible future implementations:
> 1. HttpConduit redirection customization
> 2. Disable the redirection at the HttpConduit level and deal with it at the
> CXF interceptor level
>
> In case no off-the-shelf solution in cxf for SOAP OAuth is available, could
> you please point me out a couple of examples how to deal with scenario 1 and
> 2 above? Or at least a hint where I could start implementing these
> approaches?
>

As far as OAuth2 is concerned, it is indeed planned to have an oauth2-ws 
module which will treat WS-Security binary tokens as OAuth2 bearer 
access tokens, and later will also handle SAML Assertions as token 
grants. This will affect the server side only.

What exactly are your requirements ? And are you referring to OAuth1.0 
or 2.0 ?

Thanks, Sergey

> Thanks
>
>
>
> -----
> matteo
> --
> View this message in context: http://cxf.547215.n5.nabble.com/SOAP-OAuth-in-CXF-2-7-tp5723286.html
> Sent from the cxf-user mailing list archive at Nabble.com.


-- 
Sergey Beryozkin

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

Blog: http://sberyozkin.blogspot.com