Some thoughts about the CXF OAuth2 support

[Sergey Beryozkin <sb...@gmail.com>]

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

Re: Some thoughts about the CXF OAuth2 support

[Sergey Beryozkin <sb...@gmail.com>]

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
>

Re: Some thoughts about the CXF OAuth2 support

[Bill Burke <bb...@redhat.com>]

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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com