@Geoff, you echo my sentiments exactly. The super-easy first touch is a big win and enabling security during 'productionization' is a common pattern
Cheers M On 13 September 2016 at 16:25, Geoff Macartney < [email protected]> wrote: > hi Aled, > > Have been mulling this over since this debate started, and I actually like > your ‘Alternative Proposal 2’ - out-of-the-box there is no authentication. > > That would be a super-easy experience for first-time users. For admins > installing a production machine, they’ll always expect to have to do some > step to configure their own credentials, so we document how to do that (and > make it easy to do). > > As John said, by way of comparison, Jenkins takes this approach. > > This seems to me to be simpler and clearer than the first proposal. > > Just my two cents. > > Geoff > > > ———————————————————— > Gnu PGP key - http://is.gd/TTTTuI > > > > On 13 Sep 2016, at 15:32, Aled Sage <[email protected]> wrote: > > > > Hi all, > > > > I still think we really need to change the status quo. For me, there are > two very compelling arguments: > > > > 1. In karaf, it will always prompt for a username and password. > > If running in localhost, you can enter any text and it will accept > > it. But you do have to "log in". > > 2. If running on a server, you need to find the auto-generated > > username:password from the log or from stdout. > > > > (1) is a bad user experience - the user doesn't know what to type, and > then it turns out that it is a pointless login dialog! It happens because > the login is controlled by the jaas configuration, which then delegates to > Brooklyn code for checking the given username and password. > > > > For (2), I'd expect a fair number of users to go down this route. > Currently the Brooklyn docs are not good at telling you how to find this > username and password (partly because we have entirely different login > behaviour for localhost, vagrant and remote-server). We are also all in > agreement (I think) that it's a poor user experience. > > > > --- > > I'd like a consistent way for us to handle initial login on both > localhost and server (and vagrant) - one that we are happy for users to > experience, and for us to document well. > > > > --- > > _*New Proposal*_ > > > > On initial connection via the web-console, it asks the server if there > is any security configuration options set. If there is not, the web-console > immediately re-directs the user to a page for creating the initial > user:password. Once submitted, the username and hash of the password are > written to $KARAF_HOME/etc/brooklyn.cfg for subsequent use. > > > > Over time, we'd further improve this to allow someone to set up the > initial security configuration via this page (e.g. giving LDAP details, > etc). > > > > _Implementation Considerations_ > > Not sure of the details. It would be a bit fiddly, but hopefully not too > hard. > > > > The web-console would need to do some initial requests to find out if a > new user needs to be created. It would then redirect, POST the > user-creation request, and automatically login with the new credentials. > > > > Server-side, we'd need some way for an unauthenticated user to submit > the is-security-configured request and the initial-login-user-creation > request. If we continue to use the existing Karaf jaas configuration, then > the web-console could have submitted some garbage credentials so we get > into the Brooklyn code (perhaps with default entitlements ensuring that all > other access is forbidden); or we could have an unauthenticated REST > endpoint that would handle its own security checks - always rejecting > requests if any security configuration exists (which sounds scary). > > > > We'd need to extend the Brooklyn REST api for login-user-creation. > > > > For now, it would write to the $KARAF_HOME/etc/brooklyn.cfg file. Longer > term, we could store the security config in the Brooklyn persisted state. > > > > We could also extend the Brooklyn CLI to support doing the > initial-login-user-creation. > > > > --- > > _*Alternative Proposal 1*_ > > If consensus is that folk really love the default of > > localhost-has-no-authentication, > then we could look more into how to configure Karaf jaas so that it doesn't > prompt for a login. I personally haven't been involved in that, so not sure > how feasible/hard it is. > > > > --- > > _*Alternative Proposal 2*_ > > We could make the default be unauthenticated (including disabling jaas > in the default config files). > > > > Aled > > > > > > On 08/09/2016 22:05, John McCabe wrote: > >> By way of comparison, Jenkins deploys out of the box with no auth. > >> > >> On Thu, 8 Sep 2016 at 21:11 Svetoslav Neykov < > >> [email protected]> wrote: > >> > >>> Letsencrypt (or any other certification) is a no go on localhost or on > >>> remotes where you don't know the domain name used to access it. > >>> Browsers are moving slowly to a place where even plain http will > trigger > >>> security warnings so self-signed won't be such a bad alternative at > that > >>> point. > >>> > >>> +1 for removing unauthenticated localhost access > >>> > >>>>> Are you strongly against the status quo as well (given that the > >>> password may be "buried" when installing on a server)? > >>>> It has always been ugly but has struck me as the least ugly option. > >>> Here's an alternative which has a better user experience with the same > >>> level of security. > >>> When Brooklyn starts it sees that no password is configured so > generates > >>> one (as it does currently) and puts it in brooklyn.properties or > >>> etc/brooklyn.cfg (btw straightforward to implement in Karaf). The > >>> documentation points the user to look for the password in that file > which > >>> is very easy to do as the file is minimally populated at this point - > way > >>> easier than sorting through a log file - always at the same line. This > has > >>> the possitive effect that the password remains the same between > restarts. > >>> It's been discussed already - don't remember what the cons were? > >>> > >>>> Is there a way to pass metadata to rpm/deb? That would be nice, we > >>> recommend running "yum install brooklyn -d admin.password=s3cr3t" > >>> That's no different from telling the user in docs to do "yum install > >>> brooklyn && echo admin.password=s3cr3t >> /etc/brooklyn.cfg". The > former > >>> feels like magic, the latter self-documents how to change the password > at > >>> any point. > >>> As for the question itself - won't be surprised if passing an > environment > >>> variable will let the postinstall script access it and do whatever it > needs > >>> to (as a subshell to the current session). > >>> > >>> > >>> Svet. > >>> > >>> > >>>> On 8.09.2016 г., at 22:18, John McCabe <[email protected]> wrote: > >>>> > >>>> re: letsencrypt, their flow requires the node requesting the cert be > >>>> publicly accessible, a problem for getting started, but super useful > in > >>>> most other cases. > >>>> > >>>> On Thu, 8 Sep 2016 at 20:17 John McCabe <[email protected]> wrote: > >>>> > >>>>> -1 on removing it unless it can be reproduced in some form for the > >>> getting > >>>>> started envs, the vagrant envs for example are local to the users > system > >>>>> and don't need to be secured as they are *not* intended for use in a > >>>>> production capacity (perhaps worth adding a note pointing the user to > >>> the > >>>>> section on securing a deploy (users/ssl etc)). The getting started > ask > >>> on > >>>>> the user should be absolutely minimal, even default passwords aren't > >>> great > >>>>> UX in this context. > >>>>> > >>>>> Alternatively I've seen flows where on a fresh install/first startup > you > >>>>> are prompted to create an admin account when first accessing the UI. > I > >>>>> would personally prefer that to default passwords (which is just as > >>>>> insecure as no password, maybe even less so). > >>>>> > >>>>> ps. hello ::) > >>>>> > >>>>> On Thu, 8 Sep 2016 at 17:19 Geoff Macartney < > >>>>> [email protected]> wrote: > >>>>> > >>>>>>> Is there a way to pass metadata to rpm/deb? That would be nice, we > >>>>>> recommend running "yum install brooklyn -d admin.password=s3cr3t" > >>>>>> > >>>>>> as far as I understand that’s not possible. I think there are > >>>>>> workarounds but they go against the intent of RPM. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ———————————————————— > >>>>>> Gnu PGP key - http://is.gd/TTTTuI > >>>>>> > >>>>>> > >>>>>>> On 8 Sep 2016, at 17:11, Alex Heneveld < > >>> [email protected]> > >>>>>> wrote: > >>>>>>> > >>>>>>>> Are you strongly against the status quo as well (given that the > >>>>>> password may be "buried" when installing on a server)? > >>>>>>> It has always been ugly but has struck me as the least ugly option. > >>>>>>> > >>>>>>> Is there a way to pass metadata to rpm/deb? That would be nice, we > >>>>>> recommend running "yum install brooklyn -d admin.password=s3cr3t" > >>>>>>> > >>>>>>> In general though I think this area of the product is good. > >>>>>>> > >>>>>>> > >>>>>>>> HTTPS > >>>>>>> This has also been mentioned and while I would like it in an ideal > >>>>>> world, the scare-the-daylights splash screen that browsers show if > you > >>> have > >>>>>> a self-signed cert is a compelling reason in my mind to adopt the > same > >>>>>> philosophy, start easy and document security, rather than start > secure > >>> but > >>>>>> hard-to-use. > >>>>>>> > >>>>>>> --A > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 08/09/2016 16:58, Aled Sage wrote: > >>>>>>>> Hi Alex, > >>>>>>>> > >>>>>>>> Good points. > >>>>>>>> > >>>>>>>> Are you strongly against the status quo as well (given that the > >>>>>> password may be "buried" when installing on a server)? > >>>>>>>> --- > >>>>>>>> It feels like your objections are mostly about the auto-generated > >>>>>> password, rather than about whether we have unauthenticating > localhost. > >>>>>>>> Do you think we should change the behavior so that it sets up an > >>>>>> initial default well-known credential of admin:password (which we > log > >>> and > >>>>>> document), and have localhost login require the same authentication? > >>>>>>>> (I'd be hesitant about that, given the server may be publicly > >>>>>> reachable and is opening an easily guessable password on a > predictable > >>>>>> port.) > >>>>>>>> However, that would give consistency for all ways of launching > >>>>>> Brooklyn. There are several use-cases to consider: > >>>>>>>> * Vagrant (we already auto-populate brooklyn.properties with > >>>>>>>> admin:password, I believe). > >>>>>>>> * Install on a server > >>>>>>>> o using RPM/DEB > >>>>>>>> o manually running karaf (with `./bin/start`) > >>>>>>>> o manually running `./bin/brooklyn launch` > >>>>>>>> * Install on localhost (using any of the three ways listed above) > >>>>>>>> > >>>>>>>> --- > >>>>>>>> I was hoping to separate the work into two parts: making localhost > >>> and > >>>>>> server behaviour consistent; and proper user/credential management. > >>>>>>>> Longer term, options include: > >>>>>>>> > >>>>>>>> * Installing the rpm/deb doesn't start the service (giving the > user a > >>>>>>>> chance to configure security first) > >>>>>>>> * Force the user to change the initial password on first login, > etc. > >>>>>>>> > >>>>>>>> Aled > >>>>>>>> > >>>>>>>> > >>>>>>>> On 08/09/2016 16:09, Alex Heneveld wrote: > >>>>>>>>> Aled- > >>>>>>>>> > >>>>>>>>> I'm strongly against this. Nearly all OSS software puts a > priority > >>>>>> of making it easy to get started, at the expense of pre-configured > >>> password > >>>>>> (karaf's admin:admin) or no auth (most nosql datastores). The good > OSS > >>>>>> software then describes clearly what's needed to make it secure. I > >>> think > >>>>>> we do a pretty good job of both. > >>>>>>>>> I'd welcome any install process tweak which encourages setting a > >>>>>> password in an easy way (and this would help vagrant) But I think > it's > >>>>>> unacceptable for the default to be a password buried in a log file > ... > >>> or > >>>>>> anything which makes it significantly harder to get started. > >>>>>>>>> (And do people really evaluate software on a shared server, in > this > >>>>>> day and age???) > >>>>>>>>> Best > >>>>>>>>> Alex > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 08/09/2016 15:42, Aled Sage wrote: > >>>>>>>>>> I'd expect a lot of folk evaluating Brooklyn for real use-cases > to > >>>>>> install Brooklyn on a server, rather than their laptop owned by > their > >>>>>> employer. Or for them to use Vagrant. > >>>>>>>>>> For Vagrant, we can auto-populate it with an initial > >>>>>> username:password in the brooklyn.properties file. > >>>>>>>>>> And for Brooklyn on a server, I think we should taking security > >>>>>> seriously so not allow unauthenticated access from any user who > does a > >>> curl > >>>>>> command from that server! > >>>>>>>>>> Aled > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 08/09/2016 15:35, Aled Sage wrote: > >>>>>>>>>>> Hi Mike, > >>>>>>>>>>> > >>>>>>>>>>> That touches on a bigger piece of work: to look at the runtime > >>>>>> management of user logins (e.g. if using HA, how are the user > >>> credentials > >>>>>> shared with the other HA servers; where do we write to for changes > in > >>>>>> credentials; etc). > >>>>>>>>>>> We don't support changing user passwords on-the-fly (one has to > >>>>>> modify the brooklyn.properties file, and then trigger a reload via > the > >>> rest > >>>>>> api or ui). > >>>>>>>>>>> Currently, for production use-cases we'd recommend use of > >>> something > >>>>>> like LDAP for that. We don't want to re-implement a lot of what LDAP > >>> does, > >>>>>> but we do want a reasonable out-of-the-box experience. > >>>>>>>>>>> Aled > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 08/09/2016 15:15, Mike Zaccardo wrote: > >>>>>>>>>>>> +0. My hesitation is the con of more difficult first user > >>>>>> experience. > >>>>>>>>>>>> Could a compromise be that localhost login works > unauthenticated > >>>>>> the first > >>>>>>>>>>>> time but immediately prompts the user to set a username and > >>>>>> password? > >>>>>>>>>>>> On Thu, Sep 8, 2016 at 10:12 AM Aled Sage < > [email protected]> > >>>>>> wrote: > >>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'd like to remove from Brooklyn the feature where you can > login > >>>>>>>>>>>>> authenticated from localhost. > >>>>>>>>>>>>> _* > >>>>>>>>>>>>> Current Situation*_ > >>>>>>>>>>>>> When you first start Brooklyn on a new machine (so no > >>>>>>>>>>>>> brooklyn.properties etc), it will auto-generate an initial > >>>>>> username + > >>>>>>>>>>>>> password and log that. For example: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2016-09-08 15:03:48,631 INFO No security provider options > >>>>>>>>>>>>> specified. Define a security provider or users to prevent > a > >>>>>> random > >>>>>>>>>>>>> password being created and logged. > >>>>>>>>>>>>> 2016-09-08 15:03:48,632 INFO Starting Brooklyn > web-console > >>>>>> with > >>>>>>>>>>>>> passwordless access on localhost and protected access from > >>>>>> any other > >>>>>>>>>>>>> interfaces (no bind address specified) > >>>>>>>>>>>>> 2016-09-08 15:03:48,633 INFO Allowing access to web > console > >>>>>> from > >>>>>>>>>>>>> localhost or with brooklyn:sgZZL9qqBd > >>>>>>>>>>>>> 2016-09-08 15:03:50,572 INFO Started Brooklyn console at > >>>>>>>>>>>>> http://127.0.0.1:8083/, running classpath://brooklyn.war@ > >>>>>>>>>>>>> > >>>>>>>>>>>>> If you connect from localhost, you can login without any > >>>>>> credentials. > >>>>>>>>>>>>> If you connect from an external IP, you will need to use > those > >>>>>> credentials. > >>>>>>>>>>>>> _*Pros and Cons*_ > >>>>>>>>>>>>> This is convenient for first-time users (they don't need to > >>> worry > >>>>>> about > >>>>>>>>>>>>> setting up a username/password if running Brooklyn on their > >>> local > >>>>>>>>>>>>> machine). We have to explain a little less before they can > try > >>>>>> out AMP. > >>>>>>>>>>>>> But it will also feel like a security hole. > >>>>>>>>>>>>> > >>>>>>>>>>>>> It will makes the experience of installing Brooklyn on a > server > >>>>>> very > >>>>>>>>>>>>> different from the localhost experience. This is particularly > >>>>>> true as we > >>>>>>>>>>>>> encourage the use of RPM/DEB for installing Brooklyn. > >>>>>>>>>>>>> > >>>>>>>>>>>>> _*Proposal*_ > >>>>>>>>>>>>> I propose removing this, so localhost logins also require > >>>>>> credentials. > >>>>>>>>>>>>> We'd also ensure the docs point at the username:password for > >>>>>> accessing > >>>>>>>>>>>>> the web-console. It is a problem that we don't already call > this > >>>>>> out > >>>>>>>>>>>>> (e.g. at > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>> http://brooklyn.apache.org/v/latest/start/running.html# > control-apache-brooklyn > >>>>>>>>>>>>> and http://brooklyn.apache.org/v/latest/ops/gui/running.html > ) > >>>>>> because > >>>>>>>>>>>>> users installing on a server will not know what to do. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Aled > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>> > >>>>>> > >>> > > > > -- Martin Harris Lead Software Engineer Cloudsoft Corporation Ltd www.cloudsoftcorp.com Mobile: +44 (0)7989 047-855
