cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: OAuth module - what needs to be done
Date Sat, 30 Oct 2010 16:02:30 GMT
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 <> 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

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