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 <[email protected]>wrote: > Hi Łukasz > > On Mon, Nov 1, 2010 at 8:41 PM, Łukasz Moreń <[email protected]>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 >> <[email protected]>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 <[email protected]> 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 >>>> [email protected] >>>> http://dankulp.com/blog >>>> >>> >>> >> >> >
