CXF-RS OAuth2 for Client Credentials

[Lekkie <le...@gmail.com>]

Hi,

I was wondering if anyone can show me or point me where I can see a sample
implementation of OAuth2 Client Credentails.

Thanks.



--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-RS-OAuth2-for-Client-Credentials-tp5719212.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF-RS OAuth2 for Client Credentials

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

Hi
On 28/11/12 08:39, Lekkie wrote:
> Thank you for the quick response.
>
> I am quite new to the OAuth2 concept, so forgive me if I ask dumb questions.
> I have gone through the Talend sample code and the readme file.

No problems - thanks for checking the demo

>
> I am actually trying to understand the codes for the manager (The
> Authentication&  Resource Provider part). ThirdPartyAccessService is pretty
> much clear. It retrieves the OAuthContext and check it current user has some
> required permission (Update calendar or Hour is open).
>
> However, what is not clear to me is, if the process of getting the
> OAuthContext is responsible for authenticating (in the case of Client
> Credentials) the client id&  client secret.
>
> Also, how do I implement a Client ClientCredentialsGrantHandler for my
> OAuthDataProvider? How more appropriately, what will my OAuthDataProvider
> look like? PLease, if you can illustrate with snippets, I will be most
> grateful.
As far as ClientCredentialsGrantHandler is concerned, it is already 
available, please follow the link to the wiki page and then to 
ClientCredentialsGrantHandler and get it registered with AccessTokenService.

One does not write a grant handler for OAuthDataProvider but rather for 
AccessTokenService to find a handler which can handle a current grant 
request. The idea is that grant handler will do some validation of the 
request and then delegate to OAuthDataProvider and ask to create a token.

The main job of base OAuthDataProvider is to persist the data really. 
Its exposure to OAuth2 (flows, grants) needs to be as minimal as 
possible, all it has to do is to persist the info about Clients and 
tokens and their permissions.

The demo has a custom OAuthDataProvider and it is expected to look the 
same no matter which grants have been used. The only complication in the 
demo is that it implements AuthorizationCodeDataProvider - which is 
OAuthDataProvider but has the additional responsibility to temporarily 
keep the info relevant to the redirection-based flows.

Now, if you look at the CXF ClientCredentialsGrantHandler, it says that 
Client UserSubject will be used by OAuthRequestFilter. This is the 
subject which is supposed to represent the authenticated client which 
uses the client credentials flow.

Right now the assumption is made that Client UserSubject is created at 
the time Client has registered itself before starting an actual flow.

I think technically it may've been more correct to capture the current 
authenticated client's subject, at the moment the client creds grant is 
actually presented. However, after reviewing the code and given that 
irrespectively of how the client has actually got authenticated with 
AccessTokenService, this authentication is supposed to be mapped to the 
client registration id & secret, hence reusing Client UserSubject which 
was created during the registration seems correct - though this 
definitely can be reviewed again if needed.

So to sum up, simply initialize Client UserSubject at a time the client 
has been created and this will most likely work well.

Next, OAuthContext will also provide a 'clientId' property - I think it 
is been added on the trunk only, CXF 2.7.1 will be released next week...
OAuthContext returns the user/resource owner subject. In the client cred 
case this is supposed to be the same as Client UserSubject - but I've 
updated OAuthContext to return both ResourceOwner & Client Subject which 
might help with other flows where these two subjects can be different.

Finally, by default, OAuthRequestfilter will set up SecurityContext 
wrapping a client subject, though the owner can be optionally 
impersonated. So at the moment what will definitely work is injection

JAX-RS SecurityContext and checking Principal - this will return 
"client_id"...

Hope this helps
Sergey









>
> Thanks.
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-RS-OAuth2-for-Client-Credentials-tp5719212p5719276.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: CXF-RS OAuth2 for Client Credentials

[Lekkie <le...@gmail.com>]

Thank you for the quick response.

I am quite new to the OAuth2 concept, so forgive me if I ask dumb questions.
I have gone through the Talend sample code and the readme file.

I am actually trying to understand the codes for the manager (The
Authentication & Resource Provider part). ThirdPartyAccessService is pretty
much clear. It retrieves the OAuthContext and check it current user has some
required permission (Update calendar or Hour is open).

However, what is not clear to me is, if the process of getting the
OAuthContext is responsible for authenticating (in the case of Client
Credentials) the client id & client secret.

Also, how do I implement a Client ClientCredentialsGrantHandler for my
OAuthDataProvider? How more appropriately, what will my OAuthDataProvider
look like? PLease, if you can illustrate with snippets, I will be most
grateful.

Thanks.




--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-RS-OAuth2-for-Client-Credentials-tp5719212p5719276.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF-RS OAuth2 for Client Credentials

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

Hi

On 27/11/12 14:01, Lekkie wrote:
> Hi,
>
> I was wondering if anyone can show me or point me where I can see a sample
> implementation of OAuth2 Client Credentails.
>
I've updated the documentation recently a bit:

http://cxf.apache.org/docs/jax-rs-oauth2.html#JAX-RSOAuth2-ClientCredentials, 
please also check the info on the use of refresh token grant

Given that this should work end to end the same way as with the 
authorization code flow, except that the redirection part required to 
get the code grant is not needed in this case, probably the simplest way 
to 'demo' it is to modify the demo at

https://github.com/Talend/tesb-rt-se/tree/master/examples/cxf/jaxrs-oauth2 
a bit, and specifically RestaurantReservationService code where it 
redirects the user and then gets back the code and exchanges it for the 
access token, instead, instead of doing all the redirection, immediately 
use AccesstokenService WebClient and OAuthClientUtils to request an 
access token based on the client credentials grant, and that should do it...

One more thing, ClientCredentialsGrant helper has been added to the 
trunk recently so in meantime you can create a basic custom 
AccessTokenGrant impl to be used with OAuthClientUtils

Let me know please if if you have more questions

HTH, Sergey


> Thanks.
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-RS-OAuth2-for-Client-Credentials-tp5719212.html
> Sent from the cxf-user mailing list archive at Nabble.com.