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
