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
