+1 The con mentioned above (first user experience) can be negated by defaulting a username and password in the vagrant getting started
I would propose going one further and forcing HTTPS as basic auth is practically useless without it On 8 September 2016 at 15:35, Aled Sage <[email protected]> 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#contr >>> ol-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 >>> >>> >>> > -- *Mark McKenna* *twitter:* @m4rkmckenna <https://twitter.com/m4rkmckenna> * pgp:* A7A9 24DE 638C 681A 8DEA FAD4 2B5D C759 B1EB 76A7 <https://pgp.mit.edu/pks/lookup?op=get&search=0x2B5DC759B1EB76A7>
