cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Moreń <lukasz.mo...@gmail.com>
Subject OAuth module - what needs to be done
Date Mon, 01 Nov 2010 20:41:05 GMT
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 <sberyozkin@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 <dkulp@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
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message