brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: [PROPOSAL] Remove unauthenticated localhost login
Date Thu, 08 Sep 2016 14:42:35 GMT
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.sage@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
>>>
>>>
>


Mime
View raw message