Hi,
On 23/07/14 10:55, Richard Snowden wrote:
The idea is that a developer focuses only on persisting the token and grant
details. Check "CXF OAUth2" in Google, you will get a link to the demo
shipped with Talend distro. We have plans to ship few more demos directly
in CXF in time.
Thank you Sergey. I found the Talend demo. It helps understanding the
principles of OAuth 2.0. But, from what I can see, most of the demo is
hand-coded.
I had hoped for a little bit more frameworky stuff, like for example in the
Spring Security OAuth2 Module.
I'm interested to hear what do you think can be pushed down to the
framework level to get the demo question even more minimized as far as
the OAuth2 related code the user has to do is concerned.
The demo shows that the only thing the user has to do is to ship a
custom OAuth data provider and the only thing the provider does it
persists the data (in memory), the real providers would still want to do
some extra validation in addition to what the framework does but the
idea is the providers do not deal with OAuth2 flow specifics unless
really really needed.
So, what do you think may need to be optimized ?
Are there plans to improve OAuth 2.0 support in CXF?
Yes. IMHO it represents the main open development space for the secure
CXF JAX-RS services going forward, so yes.
Short-term enhancement plans:
- support OpendConnect SP for CXF endpoints interact with OpendidConnect
IDPs. CXF won't implement OpenidConnect IDP, Fediz will hopefully will,
and we will interoperate with KeyCloak, Google/etc
- introduce boilerplate JAX-RS services for managing client
registrations and the existing tokens (for the end user to directly
revoke them if needed).
- Ship default OAuthDataProviders (Ehcache, encryption, etc)
Sergey