Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.214.41 as permitted sender)
Message-ID: <4F61BC5E.8080809@gmail.com>
Date: Thu, 15 Mar 2012 09:54:38 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: CXF Dev <dev@cxf.apache.org>
Subject: Re: Initial OAuth 2.0 support for CXF 2.6.0
References: <4F428876.6090104@gmail.com> <4F452AF0.8040300@gmail.com>
 <4F4D1315.6040201@gmail.com>
In-Reply-To: <4F4D1315.6040201@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Here is what we have at the moment:
- support for the authorization code and implicit flows, the former is 
tested in a demo (to be highlighted later on), the latter is not yet - 
but it's very closely related to the former, it's redirection based so 
should be quite close to being supported well...
- client_credentials,

Things to do for 2.6.0:
- fix java docs
- documentation on the wiki
- refresh token flow support - should be really simple, it's not really 
a flow, just a request to refresh, not a problem if postponed till later 
2.6.x versions
- few other minor fixes

After 2.6.0 a go at the saml2 grants would need to be taken, we have a 
lot of supporting code in place already, but the challenge is to see how 
the OAuth2 data provider interface copes with such complex grant 
processors, I think once we do it then JWT, etc will be just supported 
really easy.
The other enhancement which may be considered is support for 
OpenId-Connect - which is mostly about supporting so called code+token 
flows, OpenId itself will be managed by the 3rd party lib, and the 
support in CXF would be mostly about redirecting to the right endpoints :-)


Sergey


On 28/02/12 17:47, Sergey Beryozkin wrote:
> I've changed the package segment from "oauth" to "oauth2"
> in the OAuth20 module to avoid the collision with the classes in OAuth
> 1.0 one, I was a bit nervous about "2" in oauth2 but at the then I
> thought it would be quite a few years (5-10 ?) before we start talking
> about OAuth 3.0 :-) so hopefully it will go okay...The other thing is
> that OAuth 2.0 is a new protocol completely though some similarities
> with OAuth 1.0 do remain, thus the scope for sharing the 'oauth' segment
> is pretty limited, possibly to very few support classes only
>
> Cheers, Sergey
>
> On 22/02/12 17:50, Sergey Beryozkin wrote:
>> Hi,
>>
>> I added some initial code here:
>> http://svn.apache.org/viewvc?rev=1292416&view=rev
>>
>> now, the actual refactoring will start next :-). I think this code is
>> not optimal mildly speaking :-), but I think we will tune it pretty
>> quickly by building an authorization code flow demo against it...
>>
>> Cheers, Sergey
>>
>> On 20/02/12 17:52, Sergey Beryozkin wrote:
>>> Hi
>>>
>>> I've started working on the initial OAuth 2.0 support to be available in
>>> CXF 2.6.0 [1].
>>>
>>> We already provide OAuth 1.0 support starting from CXF 2.5.0 [2] - this
>>> has been continuously enhanced during the last few months and I think it
>>> is capable enough for users seeking to write OAuth 1.0 applications with
>>> CXF to be able to rely upon it.
>>>
>>> However OAuth 2.0 [3], is really going to hit the mainstream IMHO soon
>>> enough and we are already seeing some demand for the OAuth 2.0 support.
>>> Thus I've started prototyping the initial code to do with supporting the
>>> OAuth 2.0 Authorization Code Grant [3] and the simple bearer token [4];
>>> this combination is the closest to the OAuth 1.0 3-leg flow, further
>>> optimized by dropping the requirement to get a request token round trip.
>>>
>>> I'd like to keep the OAuth 1.0 code in 2.6.0 - there are quite a few
>>> OAuth 1.0 deployments out there and it would not surprise me if some
>>> users wanted to start with OAuth 1.0 gievn that it's well understood.
>>> Besides, despite OAuth 2.0 offering arguably a simpler alternative to
>>> the complete OAuth 1.0 flow, IMHO it is much more complex
>>> specification-wise. So I think we can see OAuth 1.0 being around for
>>> some time...
>>>
>>> The other thing I'd like to mention is the possibility of relying on the
>>> other OAuth 2.0 libraries such as Amber[5]. At the moment Amber has not
>>> been released yet. Personally I'll be open to reusing some of Amber's
>>> code or who knows even contributing back to the project, but at the
>>> moment I think it is simpler to prototype some base support within the
>>> CXF as opposed to trying to build it from the get go on the project code
>>> that has not been released yet. What is also important is that as far as
>>> CXF OAuth is concerned it is all about providing utility JAX-RS OAuth
>>> services with some additional utility support. The main complexity over
>>> time will come from the optional support for MAC or JWT tokens or say
>>> OpenId-Connect profiles. This is where we'd likely need some 'help' from
>>> the 3rd-party libraries.
>>>
>>>
>>> So for now I'm prototyping some code and hope to make the initial bits
>>> contributed in a week or so, may be earlier...
>>>
>>> Comments are welcome
>>>
>>> Sergey
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/CXF-4112
>>> [2] http://cxf.apache.org/docs/jax-rs-oauth.html
>>> [3] http://tools.ietf.org/html/draft-ietf-oauth-v2-23
>>> [4] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17
>>> [5] http://incubator.apache.org/amber/
>>
>>