[Hawkular-dev] Default user, or alternative realm file?

[Matt Wringe]

On 12/03/15 08:46 AM, Thomas Heute wrote:
>
> On 03/11/2015 06:35 PM, Matt Wringe wrote:
>> In LiveOak for the OpenShift cartridge, we had the system generate an
>> initial default password. So on first login you would have to know the
>> randomized initial password, and also be forced to set a new password on
>> the first login. It wasn't too bad on OpenShift since the password was
>> set it to the Mongodb cartridge's password which was visible in the
>> OpenShift console. It solved the problem of first-to-access-hijacking
>> (which in my opinion is a bad situation, things should be secure by
>> default).
>>
>> We could have something setup so that when the server is first started
>> we look for a property to use for the initial credentials (eg
>> -Dhawkular.initial.password=foo). If that property is not set, then
>> generate a password and display it in the logs or in a file somewhere.
>> When the user would login for the first time, they would need to enter
>> this password and then be forced to set a real password. If they don't
>> set the property it could be a bit annoying as they might have to ssh
>> into a machine to read the file/logs to get the initial password.
>
> I thought of that password generation, but finding the password seems 
> like a steep barrier. With docker/VM, it's even worse IMO.

If we were to set it as an environment variable, then its really not 
that bad on docker. You just need to run inspect on your container and 
it will show up. But ideally you would set the password as an option 
when starting your docker image so you don't need to look it up :)

For OpenShift, I would assume they would do something similar to what 
they had before with the password showing up somewhere in the console. 
So I think randomized passwords are probably something we will want to 
support for this.

But, yeah, its a bit of a pain to have to go searching for your password 
somewhere in certain situations. And its a bit strange to have to set 
one password and then immediately set another when you go to login.

I think the user configuration file is probably a more clean and better 
solution (and also matches what users are used to for other application 
servers). So +1 for a user configuration file (assuming in production 
the user file has to be created by the admin so that we don't have the 
first-to-access-wins situation).

>
> Thomas
>
>>
>>
>> On 11/03/15 12:55 PM, Thomas Heute wrote:
>>> Not sure to understand the alternatives but I have comments:
>>>        - Having 'admin' or 'root' for a super user IMO simplifies
>>> documentation/usage. (I can imagine that a user could forget what
>>> username he chose as superadmin for instance).
>>>        - We need to force "complex passwords", this is actually a 
>>> product
>>> requirement
>>>        - Copying a file is a step that needs to be documented and is
>>> unfriendly + either you need to encode the password (some tool like for
>>> Wildfly) or worse have the password in clear in a file for import.
>>>
>>> So I am a +1 on setting up the superuser password on first request as
>>> default. An alternative with a preset file (if present) would be 
>>> welcome
>>> for those who are afraid of first request hijacking.
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>> On 03/11/2015 05:26 PM, Juraci Paixão Kröhling wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> All,
>>>>
>>>> Alexandre (and others) asked about the possibility of adding a default
>>>> user on Keycloak for the Hawkular realm.
>>>>
>>>> While adding a default user with the requirement of changing the
>>>> password on the first login is a possibility, I'd rather have an
>>>> alternative realm file to import during first boot.
>>>>
>>>> This means: a dev (or user) have to actively copy this JSON file into
>>>> standalone/configuration in order to have a default user.
>>>>
>>>> The idea is that we wouldn't ship with a default username/password on
>>>> the main distribution. Having a default username is usually not
>>>> recommended from the security perspective, as it's half of the
>>>> information required to login with super power rights (and you would
>>>> be surprised to know how many admins set their passwords to "admin").
>>>>
>>>> Given these two alternatives, which one would you prefer? Voting is
>>>> open and I'll take the results on Monday 9am CET (08:00 UTC).
>>>>
>>>> [ ] Default user on the main realm JSON file that will ship with 
>>>> Kettle
>>>> [ ] Alternate JSON realm file with a default user, which can be copied
>>>> over the default JSON realm file.
>>>>
>>>> - - Juca.
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>
>>>> iQEcBAEBAgAGBQJVAGy2AAoJECKM1e+fkPrXIkMH/jyS4BIJCpcIntF12G6+Ofai
>>>> IaxuopgbS6rDqNnemABBQhb14Kd1mJelAz8/xnyFQsjHtzV3BZr4cqJqgC4vMpkX
>>>> cuCQWqmz5v3nTFsoxYjFXNMK2FR/K6srG/N95eg0/vO+pXVOmC5Fy8FSE1h2cUmh
>>>> 9yL1Zd8hR28xV8JDQgnRulmAsE4INY3QhpzaBpVnJczZKSsM54Hq4mDEQx5Wmr+i
>>>> k1PE9sdcysoWXmjqHSpR4cG4HNHKZXkbaBWubpaFzrI40ZkGiYVg5Vg//LqPtvQe
>>>> G16+/HNo4cgUw0HBbiVUvcXTRE3k2y/UFWVw9laQxZrAadl9Byr/7B4PnRcZxEw=
>>>> =G8QS
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>