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 firsttime 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 optionsspecified. Define a security provider or users to prevent a randompassword being created and logged. 2016-09-08 15:03:48,632 INFO Starting Brooklyn web-console withpasswordless access on localhost and protected access from any otherinterfaces (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 aboutsetting up a username/password if running Brooklyn on their localmachine). 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 verydifferent from the localhost experience. This is particularly true as weencourage 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. athttp://brooklyn.apache.org/v/latest/start/running.html#control-apache-brooklynand http://brooklyn.apache.org/v/latest/ops/gui/running.html) because users installing on a server will not know what to do. Aled
