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
 74.125.82.44 as permitted sender)
Message-ID: <51C73976.9010603@gmail.com>
Date: Sun, 23 Jun 2013 19:07:50 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: dev@cxf.apache.org
Subject: Re: Some thoughts about the CXF OAuth2 support
References: <51C2E460.1040207@gmail.com> <51C319E4.6040407@redhat.com>
In-Reply-To: <51C319E4.6040407@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi - just spotted a small spring-security-jwt library which depends on 
some of Jackson classes and seems to be pretty standalone, while looking 
for something else, may be worth checking that lib too

Cheers, Sergey
On 20/06/13 16:04, Bill Burke wrote:
> FWIW:
>
> Oauth2 is a framework for a protocol and not actually a full protocol.
> This is why I've taken an approach of providing a solution rather than
> just helper classes.  OAuth from a client perspective is just handling a
> couple of redirects or stuffing a bearer token in a header.  The
> interesting part is the auth-server side and the tight integration with
> the application server to make things easy to use and seemless.
>
> I implemented an extension to JWT which adds user role mappings to the
> token.  The token is then signed by the auth-server using JWS (json web
> signature).  The signed token can then be passed around and used for
> authentication and authorization without having to go back to the
> central server.
>
> We've used this and the OAuth2 browser protocol not only for traditional
> OAuth usecases, but also for Distributed SSO.  Also allowed us to have a
> integrated security model between browser and RESTful web services.
>
> I'd be really interested in collaborating on this OAuth2 and JWT
> extension and creating a spec at IETF.  Doing something small
> lightweight around JWT seemed like a better aproach than using a bloated
> SAML request and what I've done maps quite nicely to Java EE's user/role
> model.
>
> On 6/20/2013 7:15 AM, Sergey Beryozkin wrote:
>> Hi
>>
>> I've already chatted to some of my colleagues about the status of the
>> OAuth2 modules in CXF, why are they there and what is next for them.
>>
>> Given that the fact there are actually many concurrent OAuth2 projects
>> around, such as Apache Oltu, Spring Security OAuth2, plus many other
>> projects (including our friendly RestEasy project :-)) which do
>> something around OAuth2, I thought it would make sense to clarify where
>> do we stand with respect to the OAuth2 work and discuss few things.
>>
>> A bit of history. I worked on getting OAuth2 supported in CXF mainly for
>> the following reason : get the CXF Security story enhanced, we have a
>> lot of WS security service-level support in CXF or sub-projects (Fediz),
>> and it seemed logical to me to do something around OAuth2 too. Most of
>> OAuth2 code is actually a service-level code, example, we have 3-5
>> OAuth2 JAX-RS service coded which gets most of the OAuth2 work done.
>> Coupled with the fact we had some internal requirements open ata time
>> and that permanent wish to do it 'myself' :-) we now get OAuth2 support
>> in place.
>>
>> I think it is actually complete (as far as the support for the core
>> spec, grants and tokens are concerned), quite to the spec letter, with
>> most of various variations covered, we have the evidence users use it,
>> and IMHO it would be right to continue tuning it and adding some core
>> extensions around it , example, I added a support for the client-driven
>> token revocation [1] recently, and I can imagine adding another JAX-RS
>> service for the dynamic client registration support.
>>
>> Where I reckon it may make sense to work with other projects is the
>> support for Json Web Token (JWT) and possibly OpenIdConnect.
>>
>> JWT can be used within OpenIdConnect (which in itself is an OAuth2-aware
>> complex flow_ but also as a standalone grant. The latter presents an
>> immediate interest.
>>
>> For example, we have some requirement to get a server application
>> connected to a Google Big Query server, with a JWT assertion acting as a
>> grant. Google offers a client side library however I wonder if we can
>> get a general support for these kind of interactions in CXF.
>>
>> Note we have a support for SAML Bearer OAuth2 assertion grants,
>> something I'm planning to validate against a provider like Salesforce.
>> Support for JWT assertions would be done similarly, CXF AccessTokenGrant
>> wrapping a JWT so that the clients can use JWT grants.
>>
>> Now, similarly to say OpenSaml which offers a SAML Token model and
>> signature facilities, it may make sense to work with a similar project
>> with respect to support for JWT assertions. This is what I'd like to
>> think about. Apache Oltu team does something about JWT - I'd like to see
>> more into that, and then this project is also very specific about it:
>>
>> https://code.google.com/p/jsoncrypto/
>>
>> I'm not sure exactly what path to take at the moment, as far as the
>> support for JWT is concerned. If JsonCrypto is good enough for getting a
>> JSON sequence signed, should we just add a basic JWT bean, pass it via
>> JSONProvider and get it signed (and encrypted if needed) ? Do we even
>> need an external library given that ultimately this is just about
>> signing and possibly encrypting a (JSONProvider output) *string* ? I
>> wonder what Colm would think about the crypto and signature support in
>> JsonCrypto, I guess we may be have most of those utilities somewhere in
>> WS code :-)...
>>
>> Re OpenIdConnect: I think we may want to consider enhancing Fediz in
>> time to support it, with CXF itself offering a basic filter for users to
>> be able to get CXF connected to OpenIdConnect flows.
>>
>> Thanks, Sergey
>>
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-10
>