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
