+1 for "New Proposal"
Svet. > On 13.09.2016 г., at 17:56, John McCabe <j...@johnmccabe.net> wrote: > > +1 on the prompt for user creation if none-exists > > On Tue, 13 Sep 2016, 15:32 Aled Sage, <aled.s...@gmail.com> 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 < >>> svetoslav.ney...@cloudsoftcorp.com> 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 <j...@johnmccabe.net> 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 <j...@johnmccabe.net> 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 < >>>>>> geoff.macart...@cloudsoftcorp.com> 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 < >>>> alex.henev...@cloudsoftcorp.com> >>>>>>> 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 <aled.s...@gmail.com >>> >>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >> >>
