+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 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> > >>>>> > >> > >
