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 <[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
>>
>
>
