Alex, Nice work - this seems to be a regular feature request, I have a couple of questions.
I think you're missing a link to the PR (ref[1]). When I try the latest Brooklyn snapshot it basic auth is not enabled. How would I re-enable it? Or do we now need to write a basicauth security provider? Regards Duncan On Wed, 16 Jan 2019 at 11:20, Alex Heneveld <[email protected]> wrote: > > Hi All- > > We've had quite a few requests to support OAuth, and I'm pleased to say > we can now support it via plugins. > > Folks are still working on sample plugins for Google and/or GitHub, but > enough is there already for people to write their own to integrate with > their choice of OAuth servers. > > It is a bigger change than probably anyone expected however. It is in > [1], which has been merged with the help of Juan Cabrerizo (thanks > Juan!). This is not expected to break any APIs, but it does have > implications for people using the code directly or developing extensions > (REST endpoints and UI modules). > > Firstly background -- JAAS is geared around Basic auth, which is > incompatible with OAuth and other modern auth schemes, so we've had to > rip out the LoginModule and replace it with Filters. Jersey (REST > bundles) and resources (WAR bundles) need different filters so there's a > bit of extra complexity, but we've refactored to share code. Then it > needed a few version bumps to make it all work as expected -- CXF, > javax.ws.rs, Resteasy, and a point bump to karaf itself. All of which > are good things, though there was quite a bit of pain in getting them > all aligned and playing nicely. > > They all wrap the Brooklyn SecurityProvider class, so configuring > security providers (what users do) is unchanged. There is a new method > on the interface to say whether it needs basic auth or not, so custom > SecurityProviders will need a minor update. But you now have a lot more > flexibility in writing the provider: you can for instance throw a > SecurityProviderDeniedAuthentication exception containing a Response to > have that Response returned to the HTTP caller. This allows us to > handle the redirects needed for OAuth. > > We've also enabled auth for all the static resouces modules (WARs). This > is so the redirect happens for the user's browser request, rather than > loading html and JS, and the 302 redirect only occurring within angular > which is unhelpful. It also is a bit more secure, as now nothing is > available if you aren't logged in. > > Changes to downstream REST projects are pretty simple, see the > `blueprint.xml` change; and WAR bundles also, an update to `web.xml` and > the `pom.xml`. > > Any questions just let us know. > > Best > Alex > (with a lot of work by Juan!) >
