Thanks very much for that explanation Juan. Do I understand it right that there will be one authenticator in the security provider? Or will there be the opportunity to "Log in with Google", "Log in with Facebook", "Log in with Github" etc? I was wondering about the possibility of plugging in auth providers as Karaf bundles that would register themselves as providers of authentication services, and having a single "auth provider manager" that would present an auth option for each registered provider.
For the config above, I would have thought the scope would not be included. Does the scope not relate more to what the user is trying to do? E.g. you could have one scope for Applications, and a different one for Catalog, and different users would get directed to the security provider with the appropriate scope for the part of the app they were trying to access; although perhaps a more realistic example might be "developer" and "administrator" scopes? I wonder if the authorisation could be separated from the authentication? E.g. rather than the Google oauth security provider defining which users are authorised, we could have a separate list of authorised users, [email protected], [email protected], etc. Just some random thoughts! Geoff On Tue, 29 Jan 2019 at 09:24 Juan Cabrerizo <[email protected]> wrote: > Hello Geoff -and all Brooklyners- > I'm working on a Google based implementation of our Security Provider > interface that allow is to use Google's Identity Platform as authentication > server. Of course I'm writing some documentation (most of it on comments > and inside the configuration files). > The basic idea is use the `Brooklyn.cfg` fie to choose which Security > Provider you want to use, by default it's `AnyoneSecurityProvider` > currently. Once you set up the Oauth implementation, you need set up the > different properties you need if you choose other, in this case, for oauth, > you must config oauth server endpoints, callback url, clientId, etc. > This is the same pattern we use if you use > `ExplicitUsersSecurityProvider`, in this file you have to set up the user > and password. > > Once solved the *authentication*, in this file you also can define a > static list of emails and email domains *authorized *using other > properties. > > It is a work in progress, but for the moment the properties are these: > > # Disabling auth by default. > brooklyn.webconsole.security.provider = > org.apache.brooklyn.rest.security.provider.OauthSecurityProvider > # brooklyn.webconsole.security.oauth.users = > brooklyn.webconsole.security.oauth.domains = apache.org > # Callback URL after authentication > brooklyn.webconsole.security.oauth.callback = http://localhost.io:8081 > > # Google authentication > # URL to get the user token > brooklyn.webconsole.security.oauth.tokenUrl = > https://accounts.google.com/o/oauth2/token > # URL to authorize the user > brooklyn.webconsole.security.oauth.authorizeUrl = > https://accounts.google.com/o/oauth2/auth > # URL to validate the token > brooklyn.webconsole.security.oauth.validateUrl = > https://www.googleapis.com/oauth2/v2/userinfo > # Client ID registered in the authentication server > brooklyn.webconsole.security.oauth.clientId = {your client id} > # Client Secret to validate the token > brooklyn.webconsole.security.oauth.clientSecret = {your client secret} > # Oauth scope requested > brooklyn.webconsole.security.oauth.scope = > https://www.googleapis.com/auth/userinfo.email+https://www.googleapis.com/auth/userinfo.profile > > All if under test now. In next few days I'll open a new PR > > Thank you for you interest Geoff, I'll be happy answering any questions. > > Juan > > On Mon, 28 Jan 2019 at 23:09, Geoff Macartney <[email protected]> > wrote: > >> Hi all, >> >> I missed this email when it came out, but I'm excited to hear about OAuth >> support in Brooklyn. You've all clearly put a tremendous amount of work >> into it. Are there any docs anywhere about how this works? e.g. maybe >> more >> email threads I missed? :-) I don't suppose any of you folks who were >> involved would like to write up a short blog post or how-to email about >> the >> changes that have been made? Or is it best to just review the PR? >> >> Cheers >> Geoff >> >> >> >> On Tue, 22 Jan 2019 at 14:37 Alex Heneveld < >> [email protected]> >> wrote: >> >> > >> > Thanks Duncan. >> > >> > The PR [1] is on this email now (sorry!). >> > >> > The brooklyn.cfg that ships with karaf sets up AnyoneSecurityProvider I >> > believe, not requiring login, rather than basic (this PR hasn't changed >> > that). The docs to configure basic are at [2], but they need a minor >> > update to reflect the change in the default or the default should be >> > changed back to ExplicitUser or RandomUser. We should also review the >> > docs at [3] and [4] as some parts of those are no longer current with >> 1.0. >> > >> > Best >> > Alex >> > >> > [1] https://github.com/apache/brooklyn-server/pull/1024 >> > [2] >> > >> > >> http://brooklyn.apache.org/v/latest/ops/configuration/brooklyn_cfg.html#authentication >> > [3] http://brooklyn.apache.org/v/latest/ops/security-guidelines.html >> > [4] http://brooklyn.apache.org/v/latest/ops/configuration/index.html >> > >> > >> > >> > On 22/01/2019 11:32, Duncan Grant wrote: >> > > 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!) >> > >> >> > >> > >> > > > -- > Juan Cabrerizo > Software Engineer > > *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud > E: [email protected] > L: https://www.linkedin.com/in/juancabrerizo/ > > Need a hand with AWS? Get a Free Consultation. >
