You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Łukasz Moreń <lu...@gmail.com> on 2010/09/22 20:50:17 UTC
OAuth module - what needs to be done
Hi all,
There are still "few" things to do with OAuth module before it can be easy
usable for users.
>From what I see:
- integration with java role based access control (@RolesAllowed, @Secured
annotations). At least show how to configure that in demo.
- simplified configuration i.e. by registering OAuth endpoints
programmatically
- some refactorings, i.e. OAuthFilter does not need to have access to this
same interface like OAuth endpoints
- javadocs, wiki at least for most critical areas
I will try to implement them in this order.
Please let me know if you have any other ideas/suggestions for that.
Cheers,
Lukasz
Re: OAuth module - what needs to be done
Posted by Łukasz Moreń <lu...@gmail.com>.
Thanks for the reply.
I think I will focus on the most important things to have closed scope ready
to merge with trunk:
- leave the current @Secured and @RolesAllowed annotations support based on
spring
- add a single root resource with 3 dedicated (JAXRS) methods
- add support for permissions and scopes (urls) like you described in
previous email:
> consumer may request a permission to "doSomething" at http://bar. If
> authorized it can access http://bar, http://bar/1,
http://bar/2)
About explicit URI. The client needs to know anyway the resource URI it is
> about to access. Perhaps with Facebook the client worl with the facebook
> client library/frontend which knows the URI behind 'read_mailbox' ?
Yes, client needs to know the 'mailbox' URI to know how to access this
resource.
Cheers,
Lukasz
On Mon, Nov 1, 2010 at 3:48 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi Łukasz
>
> On Mon, Nov 1, 2010 at 8:41 PM, Łukasz Moreń <lu...@gmail.com>wrote:
>
>> Hi Sergey,
>>
>> Yes, I was doing some commits recently and I have some work uncommitted.
>> It was mainly support for @Secured and @RolesAllowed annotations and few
>> simplifications.
>> Support for @RolesAllowed is done with using spring configuration:
>>
>> <global-method-security secured-annotations="enabled"
>> jsr250-annotations="enabled"/>
>>
>>
> ok
>
>
>> I need to look how it can be done without spring.
>>
>>
> I have an interceptor sitting in my local snapshot which is able to
> introspect the secure annotations. It's not critical having this done right
> now, you may want to look into it as part of the overall no-Spring OAuth
> solution at some later stage.
>
>
>> The next thing I was thinking to do is to simplify server configuration.
>> Now, user needs to define 3 oauth endpoints and one jaxrs provider. Then
>> have to register them into jaxrs server, i.e.:
>>
>> <jaxrs:server id="oauthServer" address="/oauth/" >
>> <jaxrs:serviceBeans>
>> <ref bean="temporaryCredentialService"/>
>> <ref bean="resourceOwnerAuthorizationEndpoint"/>
>> <ref bean="tokenService"/>
>> </jaxrs:serviceBeans>
>> <jaxrs:providers>
>> <ref bean="dispatchProvider"/>
>> </jaxrs:providers>
>> </jaxrs:server>
>>
>>
> This approach of having 3 root resources, with each one dealing with a
> specific OAuth task, is a valid one, but the obvious simplification is to
> have a single root resource with 3 dedicated (JAXRS) methods delegating to
> relevant utility classes.
>
>
>> Maybe it would be good to use cxf <http:authorization> tag with value
>> 'oauth' to automatically define and register oauth endpoints. Hovewer, I am
>> not sure how important it is.
>>
>>
> I'd not go there at this stage. I'm not entirely comfortable because OAuth
> is many things : authenticating the client in the first place plus enforcing
> that the token is valid and using it for making the authorization decisions.
> For the same reason I'm not very keen on supporting the container-managed
> 'OAuth' authentication...
>
>
>> Saying scope I mean something like permission and requested URI. I've
>> added scopes handling, similarly to facebook's extended permissions:
>> http://developers.facebook.com/docs/authentication/permissions.
>> For example client asks authorization server for the scope: 'read_mailbox',
>> which hides information about permission ('read') and requested URI (mailbox
>> URI).
>> I am not sure if it has any advantages over specifying permission
>> (print/read/etc) and URI explicitly .
>>
>> "read_mailbox" is a custom permission, and similarly, "print" or even
> "read" can be a custom permission; so the first thing, I'd really prefer to
> call the "permission" what you call "scope" now. IMHO, "client requesting a
> 'read_mailbox permission" sounds ok...
>
> About explicit URI. The client needs to know anyway the resource URI it is
> about to access. Perhaps with Facebook the client worl with the facebook
> client library/frontend which knows the URI behind 'read_mailbox' ? See
>
> http://code.google.com/apis/accounts/docs/OAuth.html#prepScope.
>
> See sometimes we have end user and the client accessing the same resource
> and we do not want the client accessing exactly the same space that the end
> user can do. If it is possible to avoid for the client to specifying the URI
> during the OAuth flow then it is fine, otherwise it should be optionally
> supported.
>
>
>> I think if above issues are addressed code is ready to be used in a sample
>> project as a basic implementation.
>> I agree that there is many options to add new improvements, and add most
>> important at first.
>>
>> Sounds good.
>
> thanks, Sergey
>
>>
>> Cheers,
>> Lukasz
>>
>>
>> On Sat, Oct 30, 2010 at 9:02 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
>>
>>> Hi Lukasz
>>>
>>> You've done some merges recently to the sandbox OAuth project, thanks.
>>> I haven't had time to run the latest code yet, so can you please
>>> elaborate a bit on what do you
>>> think remains to be done before we can start working on preparing a move
>>> to the trunk ?
>>>
>>> I'm not sure about the support for @Secured annotations. I suspect that
>>> many users, even when relying on Spring, and when choosing to use
>>> security-related annotations, would probably use @RolesAllowed instead.
>>> Well, it would be good if both annotations were allowed (vis reflection may
>>> be) but @RolesAllowed is the one we need to support.
>>>
>>> About the scopes. Do you mean "permissions" ("print"/"read"/etc) ? To me
>>> the scope means the URI space which a client is trying to access. So if the
>>> client requests "http://bar" scope then "http://bar", "http://bar/y",
>>> etc should be open, provided the authorization succeeds. I'd defintely like
>>> us supporting this restriction (does not have to be 'scope').
>>>
>>> I agree this is a complex and potentially a long term project so I don't
>>> expect you merging forever :-). I think the test on whether is good to go to
>>> the trunk or not is this : can a CXF user come in and read the demo ReadMe
>>> and adapt it, without being an OAuth expert, to a basic sample project ?
>>> Once we are there I'd really consider that it is a time for the next stage,
>>> moving to the trunk, HTTPConduit redirection handlers support, etc...
>>>
>>> let us know please what you think
>>> thanks, Sergey
>>>
>>>
>>> On Thu, Sep 23, 2010 at 3:09 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>> On Wednesday 22 September 2010 2:50:17 pm Łukasz Moreń wrote:
>>>> > Hi all,
>>>> >
>>>> > There are still "few" things to do with OAuth module before it can be
>>>> easy
>>>> > usable for users.
>>>> >
>>>> > From what I see:
>>>> >
>>>> > - integration with java role based access control (@RolesAllowed,
>>>> @Secured
>>>> > annotations). At least show how to configure that in demo.
>>>>
>>>> Yea. That would definitely be a good example/demo thing. I'd like to
>>>> see
>>>> it. :-)
>>>>
>>>> > - simplified configuration i.e. by registering OAuth endpoints
>>>> > programmatically
>>>> > - some refactorings, i.e. OAuthFilter does not need to have access to
>>>> this
>>>> > same interface like OAuth endpoints
>>>> > - javadocs, wiki at least for most critical areas
>>>>
>>>> I don't remember, did we get an confluence account setup for you? If
>>>> not,
>>>> just let me know your user id there and I'll make sure you are setup to
>>>> edit
>>>> the wiki.
>>>>
>>>> > I will try to implement them in this order.
>>>> >
>>>> > Please let me know if you have any other ideas/suggestions for that.
>>>>
>>>> That all sounds great to me. :-)
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>>>>
>>>
>>>
>>
>>
>
Re: OAuth module - what needs to be done
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Łukasz
On Mon, Nov 1, 2010 at 8:41 PM, Łukasz Moreń <lu...@gmail.com> wrote:
> Hi Sergey,
>
> Yes, I was doing some commits recently and I have some work uncommitted. It
> was mainly support for @Secured and @RolesAllowed annotations and few
> simplifications.
> Support for @RolesAllowed is done with using spring configuration:
>
> <global-method-security secured-annotations="enabled"
> jsr250-annotations="enabled"/>
>
>
ok
> I need to look how it can be done without spring.
>
>
I have an interceptor sitting in my local snapshot which is able to
introspect the secure annotations. It's not critical having this done right
now, you may want to look into it as part of the overall no-Spring OAuth
solution at some later stage.
> The next thing I was thinking to do is to simplify server configuration.
> Now, user needs to define 3 oauth endpoints and one jaxrs provider. Then
> have to register them into jaxrs server, i.e.:
>
> <jaxrs:server id="oauthServer" address="/oauth/" >
> <jaxrs:serviceBeans>
> <ref bean="temporaryCredentialService"/>
> <ref bean="resourceOwnerAuthorizationEndpoint"/>
> <ref bean="tokenService"/>
> </jaxrs:serviceBeans>
> <jaxrs:providers>
> <ref bean="dispatchProvider"/>
> </jaxrs:providers>
> </jaxrs:server>
>
>
This approach of having 3 root resources, with each one dealing with a
specific OAuth task, is a valid one, but the obvious simplification is to
have a single root resource with 3 dedicated (JAXRS) methods delegating to
relevant utility classes.
> Maybe it would be good to use cxf <http:authorization> tag with value
> 'oauth' to automatically define and register oauth endpoints. Hovewer, I am
> not sure how important it is.
>
>
I'd not go there at this stage. I'm not entirely comfortable because OAuth
is many things : authenticating the client in the first place plus enforcing
that the token is valid and using it for making the authorization decisions.
For the same reason I'm not very keen on supporting the container-managed
'OAuth' authentication...
> Saying scope I mean something like permission and requested URI. I've added
> scopes handling, similarly to facebook's extended permissions:
> http://developers.facebook.com/docs/authentication/permissions.
> For example client asks authorization server for the scope: 'read_mailbox',
> which hides information about permission ('read') and requested URI (mailbox
> URI).
> I am not sure if it has any advantages over specifying permission
> (print/read/etc) and URI explicitly .
>
> "read_mailbox" is a custom permission, and similarly, "print" or even
"read" can be a custom permission; so the first thing, I'd really prefer to
call the "permission" what you call "scope" now. IMHO, "client requesting a
'read_mailbox permission" sounds ok...
About explicit URI. The client needs to know anyway the resource URI it is
about to access. Perhaps with Facebook the client worl with the facebook
client library/frontend which knows the URI behind 'read_mailbox' ? See
http://code.google.com/apis/accounts/docs/OAuth.html#prepScope.
See sometimes we have end user and the client accessing the same resource
and we do not want the client accessing exactly the same space that the end
user can do. If it is possible to avoid for the client to specifying the URI
during the OAuth flow then it is fine, otherwise it should be optionally
supported.
> I think if above issues are addressed code is ready to be used in a sample
> project as a basic implementation.
> I agree that there is many options to add new improvements, and add most
> important at first.
>
> Sounds good.
thanks, Sergey
>
> Cheers,
> Lukasz
>
>
> On Sat, Oct 30, 2010 at 9:02 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
>
>> Hi Lukasz
>>
>> You've done some merges recently to the sandbox OAuth project, thanks.
>> I haven't had time to run the latest code yet, so can you please elaborate
>> a bit on what do you
>> think remains to be done before we can start working on preparing a move
>> to the trunk ?
>>
>> I'm not sure about the support for @Secured annotations. I suspect that
>> many users, even when relying on Spring, and when choosing to use
>> security-related annotations, would probably use @RolesAllowed instead.
>> Well, it would be good if both annotations were allowed (vis reflection may
>> be) but @RolesAllowed is the one we need to support.
>>
>> About the scopes. Do you mean "permissions" ("print"/"read"/etc) ? To me
>> the scope means the URI space which a client is trying to access. So if the
>> client requests "http://bar" scope then "http://bar", "http://bar/y", etc
>> should be open, provided the authorization succeeds. I'd defintely like us
>> supporting this restriction (does not have to be 'scope').
>>
>> I agree this is a complex and potentially a long term project so I don't
>> expect you merging forever :-). I think the test on whether is good to go to
>> the trunk or not is this : can a CXF user come in and read the demo ReadMe
>> and adapt it, without being an OAuth expert, to a basic sample project ?
>> Once we are there I'd really consider that it is a time for the next stage,
>> moving to the trunk, HTTPConduit redirection handlers support, etc...
>>
>> let us know please what you think
>> thanks, Sergey
>>
>>
>> On Thu, Sep 23, 2010 at 3:09 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>> On Wednesday 22 September 2010 2:50:17 pm Łukasz Moreń wrote:
>>> > Hi all,
>>> >
>>> > There are still "few" things to do with OAuth module before it can be
>>> easy
>>> > usable for users.
>>> >
>>> > From what I see:
>>> >
>>> > - integration with java role based access control (@RolesAllowed,
>>> @Secured
>>> > annotations). At least show how to configure that in demo.
>>>
>>> Yea. That would definitely be a good example/demo thing. I'd like to
>>> see
>>> it. :-)
>>>
>>> > - simplified configuration i.e. by registering OAuth endpoints
>>> > programmatically
>>> > - some refactorings, i.e. OAuthFilter does not need to have access to
>>> this
>>> > same interface like OAuth endpoints
>>> > - javadocs, wiki at least for most critical areas
>>>
>>> I don't remember, did we get an confluence account setup for you? If
>>> not,
>>> just let me know your user id there and I'll make sure you are setup to
>>> edit
>>> the wiki.
>>>
>>> > I will try to implement them in this order.
>>> >
>>> > Please let me know if you have any other ideas/suggestions for that.
>>>
>>> That all sounds great to me. :-)
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>>
>>
>>
>
>
OAuth module - what needs to be done
Posted by Łukasz Moreń <lu...@gmail.com>.
Hi Sergey,
Yes, I was doing some commits recently and I have some work uncommitted. It
was mainly support for @Secured and @RolesAllowed annotations and few
simplifications.
Support for @RolesAllowed is done with using spring configuration:
<global-method-security secured-annotations="enabled"
jsr250-annotations="enabled"/>
I need to look how it can be done without spring.
The next thing I was thinking to do is to simplify server configuration.
Now, user needs to define 3 oauth endpoints and one jaxrs provider. Then
have to register them into jaxrs server, i.e.:
<jaxrs:server id="oauthServer" address="/oauth/" >
<jaxrs:serviceBeans>
<ref bean="temporaryCredentialService"/>
<ref bean="resourceOwnerAuthorizationEndpoint"/>
<ref bean="tokenService"/>
</jaxrs:serviceBeans>
<jaxrs:providers>
<ref bean="dispatchProvider"/>
</jaxrs:providers>
</jaxrs:server>
Maybe it would be good to use cxf <http:authorization> tag with value
'oauth' to automatically define and register oauth endpoints. Hovewer, I am
not sure how important it is.
Saying scope I mean something like permission and requested URI. I've added
scopes handling, similarly to facebook's extended permissions:
http://developers.facebook.com/docs/authentication/permissions.
For example client asks authorization server for the scope: 'read_mailbox',
which hides information about permission ('read') and requested URI (mailbox
URI).
I am not sure if it has any advantages over specifying permission
(print/read/etc) and URI explicitly .
I think if above issues are addressed code is ready to be used in a sample
project as a basic implementation.
I agree that there is many options to add new improvements, and add most
important at first.
Cheers,
Lukasz
On Sat, Oct 30, 2010 at 9:02 AM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi Lukasz
>
> You've done some merges recently to the sandbox OAuth project, thanks.
> I haven't had time to run the latest code yet, so can you please elaborate
> a bit on what do you
> think remains to be done before we can start working on preparing a move to
> the trunk ?
>
> I'm not sure about the support for @Secured annotations. I suspect that
> many users, even when relying on Spring, and when choosing to use
> security-related annotations, would probably use @RolesAllowed instead.
> Well, it would be good if both annotations were allowed (vis reflection may
> be) but @RolesAllowed is the one we need to support.
>
> About the scopes. Do you mean "permissions" ("print"/"read"/etc) ? To me
> the scope means the URI space which a client is trying to access. So if the
> client requests "http://bar" scope then "http://bar", "http://bar/y", etc
> should be open, provided the authorization succeeds. I'd defintely like us
> supporting this restriction (does not have to be 'scope').
>
> I agree this is a complex and potentially a long term project so I don't
> expect you merging forever :-). I think the test on whether is good to go to
> the trunk or not is this : can a CXF user come in and read the demo ReadMe
> and adapt it, without being an OAuth expert, to a basic sample project ?
> Once we are there I'd really consider that it is a time for the next stage,
> moving to the trunk, HTTPConduit redirection handlers support, etc...
>
> let us know please what you think
> thanks, Sergey
>
>
> On Thu, Sep 23, 2010 at 3:09 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Wednesday 22 September 2010 2:50:17 pm Łukasz Moreń wrote:
>> > Hi all,
>> >
>> > There are still "few" things to do with OAuth module before it can be
>> easy
>> > usable for users.
>> >
>> > From what I see:
>> >
>> > - integration with java role based access control (@RolesAllowed,
>> @Secured
>> > annotations). At least show how to configure that in demo.
>>
>> Yea. That would definitely be a good example/demo thing. I'd like to
>> see
>> it. :-)
>>
>> > - simplified configuration i.e. by registering OAuth endpoints
>> > programmatically
>> > - some refactorings, i.e. OAuthFilter does not need to have access to
>> this
>> > same interface like OAuth endpoints
>> > - javadocs, wiki at least for most critical areas
>>
>> I don't remember, did we get an confluence account setup for you? If
>> not,
>> just let me know your user id there and I'll make sure you are setup to
>> edit
>> the wiki.
>>
>> > I will try to implement them in this order.
>> >
>> > Please let me know if you have any other ideas/suggestions for that.
>>
>> That all sounds great to me. :-)
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>
Re: OAuth module - what needs to be done
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Lukasz
You've done some merges recently to the sandbox OAuth project, thanks.
I haven't had time to run the latest code yet, so can you please elaborate a
bit on what do you
think remains to be done before we can start working on preparing a move to
the trunk ?
I'm not sure about the support for @Secured annotations. I suspect that many
users, even when relying on Spring, and when choosing to use
security-related annotations, would probably use @RolesAllowed instead.
Well, it would be good if both annotations were allowed (vis reflection may
be) but @RolesAllowed is the one we need to support.
About the scopes. Do you mean "permissions" ("print"/"read"/etc) ? To me the
scope means the URI space which a client is trying to access. So if the
client requests "http://bar" scope then "http://bar", "http://bar/y", etc
should be open, provided the authorization succeeds. I'd defintely like us
supporting this restriction (does not have to be 'scope').
I agree this is a complex and potentially a long term project so I don't
expect you merging forever :-). I think the test on whether is good to go to
the trunk or not is this : can a CXF user come in and read the demo ReadMe
and adapt it, without being an OAuth expert, to a basic sample project ?
Once we are there I'd really consider that it is a time for the next stage,
moving to the trunk, HTTPConduit redirection handlers support, etc...
let us know please what you think
thanks, Sergey
On Thu, Sep 23, 2010 at 3:09 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Wednesday 22 September 2010 2:50:17 pm Łukasz Moreń wrote:
> > Hi all,
> >
> > There are still "few" things to do with OAuth module before it can be
> easy
> > usable for users.
> >
> > From what I see:
> >
> > - integration with java role based access control (@RolesAllowed,
> @Secured
> > annotations). At least show how to configure that in demo.
>
> Yea. That would definitely be a good example/demo thing. I'd like to
> see
> it. :-)
>
> > - simplified configuration i.e. by registering OAuth endpoints
> > programmatically
> > - some refactorings, i.e. OAuthFilter does not need to have access to
> this
> > same interface like OAuth endpoints
> > - javadocs, wiki at least for most critical areas
>
> I don't remember, did we get an confluence account setup for you? If
> not,
> just let me know your user id there and I'll make sure you are setup to
> edit
> the wiki.
>
> > I will try to implement them in this order.
> >
> > Please let me know if you have any other ideas/suggestions for that.
>
> That all sounds great to me. :-)
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: OAuth module - what needs to be done
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 22 September 2010 2:50:17 pm Łukasz Moreń wrote:
> Hi all,
>
> There are still "few" things to do with OAuth module before it can be easy
> usable for users.
>
> From what I see:
>
> - integration with java role based access control (@RolesAllowed, @Secured
> annotations). At least show how to configure that in demo.
Yea. That would definitely be a good example/demo thing. I'd like to see
it. :-)
> - simplified configuration i.e. by registering OAuth endpoints
> programmatically
> - some refactorings, i.e. OAuthFilter does not need to have access to this
> same interface like OAuth endpoints
> - javadocs, wiki at least for most critical areas
I don't remember, did we get an confluence account setup for you? If not,
just let me know your user id there and I'll make sure you are setup to edit
the wiki.
> I will try to implement them in this order.
>
> Please let me know if you have any other ideas/suggestions for that.
That all sounds great to me. :-)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog