2.5 and OAuth

[Jeff Wang <je...@plutom.com>]

With great anticipation, I am looking through the OAuth 1.0
implementation in CXF.  I have some questions:
In AuthorizationRequestService

1) This is just authorization, right?  So we actually need to have
secured the (in the example) /forms/oauthAuthorize.jsp so that before
they go there, they are authenticated as a user of myapp?

In Protecting resources with OAuth filters,
Bullet point 2, "It will check if Client and AccessToken have a "uris"
property set and if yes then it will validate the current request URI
against it."

1) the list of URIs with the client is the client's app, right?
(www.clientapp.com/clientapp - the javadoc says it could be used to
check the callback URL) So the current URI
(www.myapp.com/myapp/protectedresource) will always fail? (the Token's
scope and uri is fine, because it is set at the time /initiate is
called.)
2) Is matching a wildcard match?  for example (myapp/user/*/profile
myapp/user/{userId}/contacts) if I want to allow a user to see the
profile of all their contacts, but not their contacts' contacts.

the bullet point 4, "Finally, it will create a SecurityContext using
this list of OAuthPermissions and the Client loginName property."

1) Since we're talking about SecurityContext, that means this is
Spring Security, right?

2) Since the client (which is a representation of the consumer,
right?) is authenticated on behalf of the end user, shouldn't the
Authentication object represent the user detail of the end user?

3) Speaking of which, could we configure a custom UserDetailService?

4) Is there a way to protect different endpoints on the same
jaxrs:server declaration with different scopes? for example, different
scopes for GET /myapp/user/{userId}/profile and GET
/myapp/user/{userId}/contact?

5) If I want to make sure that only {userId} have access to their
/user/{userId}/super-secret-information, is it possible to make sure
that the end-user being authenticated is the same one that is
authorized? or do I have to check it in the getSuperSecretInformation
method via the SecurityContextHolder?

Thanks, and I look forward to using this new feature!
Jeff

Re: 2.5 and OAuth

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

Hi, thank for your interest, I'm documenting it all right now, comments 
inline,

On 09/11/11 02:16, Jeff Wang wrote:
> With great anticipation, I am looking through the OAuth 1.0
> implementation in CXF.  I have some questions:
> In AuthorizationRequestService
>
> 1) This is just authorization, right?

Yes, this service is where the consumer will redirect the user to and 
this service will post the user's decision back to the consumer...

> So we actually need to have
> secured the (in the example) /forms/oauthAuthorize.jsp so that before
> they go there, they are authenticated as a user of myapp?

The authentication will be required after the user has been redirected 
to the service, that is why it's better to get this service set up 
alongside other myapp endpoints protected by the myApp security filter.
The support for SSO is quite important - on the map...
>
> In Protecting resources with OAuth filters,
> Bullet point 2, "It will check if Client and AccessToken have a "uris"
> property set and if yes then it will validate the current request URI
> against it."
>
> 1) the list of URIs with the client is the client's app, right?
> (www.clientapp.com/clientapp - the javadoc says it could be used to
> check the callback URL) So the current URI
> (www.myapp.com/myapp/protectedresource) will always fail? (the Token's
> scope and uri is fine, because it is set at the time /initiate is
> called.)

callbackURI will be provided by a consumer during the initial request 
token request and it will be validation against the application URI the 
consumer should've provided during its own out-of-band registration...

the 'uris' property is an extension and it may be handy when the same 
access path is shared by both end users and OAuth consumers, in cases 
when we have a JAX-RS resource class with say /getBook and 
/getBook/chapter, and we don't want the consumers to go beyond /getBook, 
it's quite specific and perhaps may not be needed we have an application 
hosting user accounts, etc..

> 2) Is matching a wildcard match?  for example (myapp/user/*/profile
> myapp/user/{userId}/contacts) if I want to allow a user to see the
> profile of all their contacts, but not their contacts' contacts.
>
It's a wildcard match, I'll need to double check how it's implemented

> the bullet point 4, "Finally, it will create a SecurityContext using
> this list of OAuthPermissions and the Client loginName property."
>
> 1) Since we're talking about SecurityContext, that means this is
> Spring Security, right?
>
Not at all, it's a CXF SecurityContext, will update the docs, and it may 
not be needed for many cases, might be needed if you have the sane 
shared code for processing consumers and end users - but it does not 
have to be implemented that way, you can just direct the consumers via a 
different path altogether

> 2) Since the client (which is a representation of the consumer,
> right?) is authenticated on behalf of the end user, shouldn't the
> Authentication object represent the user detail of the end user?
>
Not really, the client is actually 'authenticated' using the combination 
of its own key/secret and the access token key & secret which kind of 
'captures' a bit the end user identity - because it must've got 
authenticated when authorizing the consumer

> 3) Speaking of which, could we configure a custom UserDetailService?
>
Not sure I understand

> 4) Is there a way to protect different endpoints on the same
> jaxrs:server declaration with different scopes? for example, different
> scopes for GET /myapp/user/{userId}/profile and GET
> /myapp/user/{userId}/contact?
>

The custom OAuthDataProvider will translate opaque scopes into 
OAuthPermissions which may also have a uri property, so perhaps in this 
case, one consumer can be allocated a "readProfiles" scope and the one - 
"readContacts"

> 5) If I want to make sure that only {userId} have access to their
> /user/{userId}/super-secret-information, is it possible to make sure
> that the end-user being authenticated is the same one that is
> authorized? or do I have to check it in the getSuperSecretInformation
> method via the SecurityContextHolder?

I guess you are thinking of SecurityContext as Spring one, it's not. 
(CXF) SecurityContext populated as described on the wiki is only ever 
needed if you have the same resource class and URI path shared between 
all the parties and even then the validation at the filter level might 
be sufficient, this SecurityContext is there to let users to 
additionally utilize RBAC rules...

>
> Thanks, and I look forward to using this new feature!

Thanks for your comments. I guess this feature may not necessarily be 
production-ready from the get-go :-), so we will work on fine-tuning it, 
please keep the comments coming

Cheers, Sergey
> Jeff