cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Moreń <>
Subject Re: Provide an authentication support through OAuth for Apache CXF
Date Wed, 14 Apr 2010 02:42:55 GMT

Unfortunatelly there is no way to update the GSoC proposal.
So more explanation here and sorry for such long delay:/.


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:

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

   - Refreshing an Access Token

        Acquiring new access token to replace expired one without having to
involve the resource owner

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

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

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.

Configurable elements, can be done through web.xml or CXF configuration
file. :
in the server module:
- Enable/disable OAuth authorization flow;
- URI pattern for protected resources.
- OAuth endpoint URIs (for obtaining/validating tokens)
- 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,...

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
- additional parameters required in some flows i.e. callback_url

To assure code quality unit test should be written.

*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

*July 24 - August 5*
*Check if implementation fully covers OAuth specification.
Code adjustment.

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

*Other obligations:*
*I do research work at university. (*
*Hovewer it is strictly connected with OAuth and RESTfull services, so I
think it's rather beneficial.


2010/4/10 Daniel Kulp <>

> 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:
> 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]
> >
> > .GA/userguide/html/Authentication.html [2]
> > [3]
> > [4]
> >
> > /t124024692589 [5]
> >[6]
> >[7]
> >
> > [8]
> >
> > 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

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