cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Provide an authentication support through OAuth for Apache CXF
Date Fri, 16 Apr 2010 14:24:54 GMT
Hi Łukasz

Apologies for a delay, I've been very busy this week but I'll get up to
speed by the time the project starts and hopefully will be able to talk the
same OAuth language with you :-).

Here is the main points which I'd appreciate you addressing further, when
working on fine-tuning the proposal/starting with the project :

1. Please consider downgrading from OpenAuth draft to the earlier version
which is actually being used by the real world applications today. The
priority is to ensure CXF can interoperate with existing providers if
needed. I do like the idea of CXF implementing the latest spec but we'd
really like users to have a choice not to have CXF deployed everywhere for
the whole thing to work. In other words, an OpenAuth Consumer of protected
resources should be able to chat to a RestEasy ServiceProvider protected by
OpenAuth authorization filters. You can upgrade to 2.0 once it's been
finalized and deployed.

Are you really keen to pursue implenting OAuth 2.0 as opposed to say 1.0 ?
If yes then let us know why please.

2. Please prioritize such that the basic flow (user logs in to the
ServiceProvider, provides an access to some of its resources and then
vouches for the Consumer and finally Consumer accesses the protected
resources) works well first. The additional enhancements can follow
(implementing all the profiles, etc).

3. Part of 2 (prioritize) : Please consider allocating time on ensuring that
a CXF (programmatic) user can vouch for a consumer automatically. If
Autonomous profile can help then it is fine but I'd appreciate you thinking
abut it more, looks like this issue has not been covered.

Dan may have some more comments too.

More comments inline (see Project Description)

thanks

Sergey

2010/4/14 Łukasz Moreń <lukasz.moren@gmail.com>

> Hi,
>
> Unfortunatelly there is no way to update the GSoC proposal.
> So more explanation here and sorry for such long delay:/.
>
> *Abstract*
>
> OAuth 2.0 provides a method for an application (Client) to access the
> Protected Resource hosted on a server on behalf of a Resource Owner (such
> as
> a different client or an end-user). It provides a process for end-users to
> authorize third-party access to their Protected Resources via a variety of
> Authorization Profiles which generally do not include having to share their
> credentials (typically, a username and password pair). A server can
> additionally delegate authorization to one or more authorities
> (Authorization Server) which issue Access Tokens to Clients.
> In other words, OAuth allows to share private resources stored on one site
> with another site without having to hand out user name and password.
>
> The Apache CXF framework helps to develop web services using standards
> based
> programming model and also provides a flexible deployment model for
> deploying web services. Developing SOAP and RESTful applications can be
> made
> easy by using Apache CXF framework.
>
> Current OAuth 2.0 draft:
> *http://github.com/theRazorBlade/draft-ietf-oauth*
>
>
> *Goal*
> *
> *
> RESTful web services model is currently commonly used as a way to expose
> applications API.
> OAuth support for Apache CXF will allow authenticated access by third party
> applications to our services.
> On the other hand there is a number of web application that expose already
> RESTful API (Flickr, FriendFeed, Yahoo, ...) that use OAuth as
> authentication method.
> OAuth support for Apache CXF will allow ease of consuming such services in
> application we want to built.
>
>
> *Project description*
>
> Mainly OAuth specification involves three parts:
>
>
>   - Getting an Access Token
>
>        Client in "some way" acquires an access token - a unique identifier
> used by the client to make authenticated requests on behalf of resource
> owner.
>        This "some way" is one of the flows specified in OAuth 2.0 draft and
> grouped into:
>
>        User Delegation Flows, End User Credentials Flows and Autonomous
> Client Flows.
>
>        Selection of the flow should be done according to the client
> type(web app, standalone client, mobile device, http-agent, etc.)
>        and individual requirements.
>
>
OK


>
>   - Refreshing an Access Token
>
>        Acquiring new access token to replace expired one without having to
> involve the resource owner
>
> OK

>
>   - Accessing a protected resource
>
>        Client access protected resources by presenting an access token (as
> URI query parameter or form-encoded body parameter) to the resource server.
>
>
OK


> Above services has to be served for clients by OAuth for CXF support in
> case
> Apache CXF works as an authorization server, let's call that
> CXF-OAuth-server
> module.
> Hovewer Apache CXF should be able to work as well as OAuth client. As well
> as serving OAuth endpoints (for acquiring access token, refreshing token,
> validating token)
> CXF should be able to consume those services by, let's call that
> CXF-OAuth-client
> module.
>

OK


> The situation, I think, worth discussing is when authorization server(from
> where tokens are obained) is different than resource server (resources are
> accessed).
> In the early stage of development I assume that authorization server =
> resource server.
>

+1. I guess the resource server can also impersonate the consumer or
redirect him eventually. Agreed it can be done later


>
> Since all requests to the OAuth authorization server result in the
> transmission of plain security credentials required is use of secure
> channel
> mechanism like SSL.
> Every OAuth request for a protected resource should be intercepted to check
> required parameters. The interceptor task is to perform next steps
> according
> to presented parameters i.e. deny access, allow access to resource, perform
> next authorization steps. The request interception can be achieved with
> using servlet filters, cxf interceptors, RequestHandler.
>
>
Sure. Lets have some shared code that filters/interceptors/RequestHandlers
can reuse.


> Configurable elements, can be done through web.xml or CXF configuration
> file. :
> in the server module:
> - Enable/disable OAuth authorization flow;
>

this will be enabled by the fact of registering a servlet filter or CXF
interceptor


> - URI pattern for protected resources.
>
- OAuth endpoint URIs (for obtaining/validating tokens)
>

I'm assuming this is the configuration for the above filter/interceptor


> - used provider to store tokens, client data, credentials, etc.. I think
> should be specified interface implemented by memory provider(want to start
> from this one), database provider,...
>

OK. Again, assuming it will be injected into the above filter/interceptor



>
> in the client module:
> - credentials data (i.e. client_id, client_secret) used for authentication
> with the authorization server
> - selection of used OAuth flow to authenticate with the authorization
> server?
> - additional parameters required in some flows i.e. callback_url
>
>
I'm not quite clear how it will be implemented. This is the consumer which
will try to access protected resources on some other server on behalf of the
owner. So it will need to act as a JAXRS server endpoint too, so that the
ServiceProvider can contact it and tell it that an owner is willing to let
it access and say read and print some photos ?


> To assure code quality unit test should be written.
>
> OK


>
> *Project Schedule*
> *
> April 26 - May 24*
> *
> *Get more knowledge about Apache CXF - architecture guide, reading books,
> articles, tutorials, doing simple CXF applications.
> Get more familiar with development process in Apache CXF project: coding
> guidelines, building project, configuring developer environment.
>
> *May 25 - June 19*
>
> Implementation of CXF-OAuth-server module - User Delegation Flows and
> working with that client module.
>
> *June 20 - July 12*
>
> Implementation of support the End User Credentials Flows and Autonomous
> Client Flows and working with that client module.
>
> *July 13 - July 16*
>
> Review a project progress done so far.
> Documentation of work done.
>
> *July 17 - July 23*
>
> Implementation of *Accessing protected resources *part of OAuth
>  specification.
>
> *July 24 - August 5*
> *
> *Check if implementation fully covers OAuth specification.
>

As I said above please prioritize on the most basic flow first as well as
consider implementing an older version.


> Code adjustment.
>

Perhaps adding demo would be good and help users to start faster.


>
> *August 5 - August 16*
> Final documentation. More tests. More bug fixes
>
>
>
sounds good


>
> *Other obligations:*
> *I do research work at university. (http://tinyurl.com/uma-wg)*<http://tinyurl.com/uma-wg%29*>
> *Hovewer it is strictly connected with OAuth and RESTfull services, so I
> think it's rather beneficial.
> *
>

agreed


By the way, I'm proposing to add all the code to the package
org.apache.cxf.jaxrs.security.oauth.
Some changes may need to go HttpConduit (to do with the user auto vouching
for a consumer)
Also, it will need to be another module. You can start with adding the code
to rt/frontenend/jaxrs  initially but
I think we may need to introduce

rt/jaxrs/security/oauth,

similarly to the way things are done for WS specs such as WS-Security. In
fact rt/ws might have OAuth related module added too when SOAP gest
supported.

thanks, Sergey

>
> Cheers,
> Lukasz
>
> 2010/4/10 Daniel Kulp <dkulp@apache.org>
>
> > Lukasz,
> >
> > I or Sergey may end up being the mentor for this proposal so we need to
> > start
> > looking at how to score and rank the proposal.  Look at:
> >
> > http://community.apache.org/mentee-ranking-process.html
> >
> > Particularly the scoring areas.  One of the things the proposal needs is
> > some
> > additional details around a timeline and goals to be achieved.   For
> > example,
> > at mid terms, what is a good target to have achieved?    When should we
> > start
> > seeing patches or similar as steps along the way?  Etc...
> >
> > Please take a look at the scoring stuff and start working on filling in
> > more
> > details to the proposal. (I THINK you can still edit it, if not, at least
> > respond here)
> >
> > Dan
> >
> > On Friday 09 April 2010 3:08:56 am Łukasz Moreń wrote:
> > > My name is Lukasz Moren and I'm a student looking for an interesting
> > > project for this year Google
> > > Summer of Code.
> > >
> > > I would like to propose a project idea: Provide an authentication
> support
> > > through OAuth for Apache CXF (JAXRS module).
> > > Something similar to: [1], I mean the idea, not execution.
> > >
> > > As I am recently involved in RESTful services (mainly RESTEasy
> framework,
> > > but I've tried also CXF:)) and OAuth protocol,
> > > it's area I feel good.
> > >
> > > The OAuth community works currently on: [2], which appeared after 1.0a.
> > > and planning 2.0 release based on OAuth WRAP:[3].
> > >
> > > I take part in GSoC 2009 in JBoss [4], and project finished
> sucessfully.
> > > I was mainly involved in two tasks: [5], [6], hovewer the second one
> > became
> > > big
> > > and development is continued here: [7].
> > > More info about me can be found: [8]
> > >
> > >
> > > [1]
> > >
> >
> http://www.jboss.org/file-access/default/members/resteasy/freezone/docs/1.2
> > > .GA/userguide/html/Authentication.html [2]
> > http://wiki.oauth.net/OAuth-WRAP
> > > [3] http://hueniverse.com/2009/11/planning-for-oauth-2-0/
> > > [4]
> > >
> >
> http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/redhat
> > > /t124024692589 [5]
> > >
> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-392[6]<http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-392%5B6%5D>
> > >
> http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-307[7]<http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-307%5B7%5D>
> > > https://jira.jboss.org/jira/browse/ISPN/component/12312732
> > > [8]
> > >
> >
> http://www.linkedin.com/profile?viewProfile=&key=32578698&locale=en_US&trk=
> > > tab_pro
> > >
> > > Sorry for so much links, but I would like to exaplain things briefly.
> > >
> > > Please let me know what do you think about that idea.
> > >
> > > Thanks in advance for reply.
> > >
> > > Best Regards,
> > > Lukasz Moren
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> >
>

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