11:26 a.m.
-----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-----
11:55 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev 
12:29 p.m.
The alternative of a file to be copied over would be used mostly for development, where
after building we would copy it over so that after each rebuild it's not needed to go
through the registrations process.
But, I think if the credentials are preset to admin/admin, needing to be changed on first
login (with whichever strength enforcement we decide and keycloak supports) along with
email address, it would be safe. The only possibility of an attacker logging in with
default credentials would be for a never configured installation.. and for that, even the
keycloak "master" realm is exposed to the same risk.
Actually, thinking of it, the "master" realm situation is dangerous, if a user
never needs to login directly to it, he may leave it in "unconfigured" state,
where it can be accessed later by an attacker.
So I vote for option 1. And we need to figure a solution for also forcing the user to
change the default admin/admin of "master" realm.
Alexandre
----- Original Message -----
From: "Thomas Heute" <theute(a)redhat.com>
To: jpkroehling(a)redhat.com, hawkular-dev(a)lists.jboss.org
Sent: Wednesday, March 11, 2015 4:55:27 PM
Subject: Re: [Hawkular-dev] Default user, or alternative realm file?
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.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
-----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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:23 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/11/2015 06:29 PM, Alexandre Mendonca wrote:
But, I think if the credentials are preset to admin/admin, needing
to be changed on first login (with whichever strength enforcement
we decide and keycloak supports) along with email address, it would
be safe. The only possibility of an attacker logging in with
default credentials would be for a never configured installation..
and for that, even the keycloak "master" realm is exposed to the
same risk.
Right, but it's a risk we don't need, as I see it only as a
convenience rather than a necessity.
Actually, thinking of it, the "master" realm situation is
dangerous, if a user never needs to login directly to it, he may
leave it in "unconfigured" state, where it can be accessed later by
an attacker.
So I vote for option 1. And we need to figure a solution for also
forcing the user to change the default admin/admin of "master"
realm.
Indeed, I'll create a JIRA for myself to look into it.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVAJZAAAoJECKM1e+fkPrXMeUH/iepqADxdFvGZcFM98+8p+x1
DvqkS4DTWO9uL3P9G7ph4AsR98YFfFhEZ39sZ+PNBLzY++t/Gk4onih3I26NvFhB
EpTwIbp6XfECBIhKBuGvijUxcXuPl01/55RjBhI3NySaW9T7UfqJSVCu/m33QgDj
Pc7xgUN9xn/f0ym22EUcg9jwZPgqs+HPZB+IBSVqhHubFYFDAaBnkT5AwWRsP47o
CTBkjT1gEtw2sYSZeI3V15MiLhjZt2/diKu/EUqwexQmhHcjRpbOG+vbWKJ7c9Ds
Llnv5RKpeb7ikMT0FivC2p80YrIXVU58poz7zF3cyivKTQJv1YqzV/XhGpcj9Pg=
=rDM9
-----END PGP SIGNATURE-----
12:08 p.m.
On 11 Mar 2015, at 18:29, Alexandre Mendonca wrote:
The alternative of a file to be copied over would be used mostly for
development, where after building we would copy it over so that after
each rebuild it's not needed to go through the registrations process.
Can we make sure that docker images get a sensible default that does not
requiring ssh-ing into the container and manually copying things around?
12:19 p.m.
Hi *, inline...
On 03/12/2015 06:08 PM, Heiko W.Rupp wrote:
On 11 Mar 2015, at 18:29, Alexandre Mendonca wrote:
> The alternative of a file to be copied over would be used mostly
> for development, where after building we would copy it over so that
> after each rebuild it's not needed to go through the registrations
> process.
Can we make sure that docker images get a sensible default that does
not requiring ssh-ing into the container and manually copying things
around?
Cite from OpenShift docs, Best Practices for writing images:
It is best to avoid setting default passwords. Many people will
extend the image and forget to remove or change the default password.
This can lead to security issues if a user in production is assigned
a well-known password. Passwords should be configurable using an
environment variable instead. See the Using Environment Variables for
Configuration topic for more information.
http://docs.openshift.org/latest/image_writers_guide/guidelines.html
-- P
_______________________________________________ hawkular-dev mailing
list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:04 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So, I'm more and more convinced that we should provide a default user
*only* when building from the developer profile :-)
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVAdUjAAoJECKM1e+fkPrXN9AH/1m7hKvwpf3XasljPu4UQcDM
4bjWyk8S383bXt5d9g0oO/WhmOZx4fk5ZbP4XeslEpTVQbv58JJj1Nfm9cpUfkn7
lcjpiTwJx0GL/dBiS5iDrs5oqUSc/oYXgeBUkujGzDgYeQJ8F7pBY1iGiM1gMAuD
3Vslf3IajU5Z0givpoIZTt9iZkIN/UxCRCVkzrUX5njR1eoIt37TY5rvm33SNXTo
BxZaGUGOj0xOUo/AvsEN47g/2jU/FMcRuUKHyo7BNF1RaczcPacz687MyZPfvZ94
ZrgCWaXKbEzprMlKyyjScLn61VINp5NPMivcbbi5iKJn59RIDti0jknF0r8MXhE=
=Xo8Y
-----END PGP SIGNATURE-----
4:28 p.m.
Hi,
I guess my wording was bad.
On 12 Mar 2015, at 18:19, Peter Palaga wrote:
Hi *, inline...
On 03/12/2015 06:08 PM, Heiko W.Rupp wrote:
> Can we make sure that docker images get a sensible default that does
> not requiring ssh-ing into the container and manually copying things
> a well-known password. Passwords should be configurable using an
> environment variable instead. See the Using Environment Variables
This satisfies my request.
$ docker run -e password=bla hawkular/hawkular
is perfectly fine.
$ docker run -d -p 22:22 hawkular/hawkular
$ ssh <dockerip:22> cp /some/odd/path/pw.json
/some/other/longer/path/realm.json
is not.
12:35 p.m.
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.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:46 a.m.
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.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:35 a.m.
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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:48 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/12/2015 02:35 PM, Matt Wringe wrote:
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).
Note that we don't actually *need* a default user, so, this poll is
about deciding on whether or not to include one. So far, I take it
that most prefer to have a default user for the dev profile.
Your suggestions are actually really good, and I might end up using an
approach similar to that in another part: the default Keycloak admin
password. Our window of attack for the default Keycloak admin's
credentials is far bigger than Keycloak itself: while Keycloak folks
expect admins to install and configure it right away, we don't expect
"admins" to open Keycloak as soon as they install Hawkular. So, the
default username/password for Keycloak might live for hours/days
before the admin realizes that it needs to be changed.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVAZlGAAoJECKM1e+fkPrXRvEIAIOw0zdUuDtg8/DaVVg+o7U8
AAdbbZOOpstYZ2kq4m//Dx9xV89RkBYJYLgjeZcsJ+vYl1ZoU2M+8cqnVodXi8hU
r/quHqiNI5nZdvBN4lYLpXyWh08ljlcMmrCjNBSFvSFpk9l11QavtrXA1mr0t+N9
DYcleENnhs3IlHoX+bR5PtHvhd/+Plln2I4sIFB6EDZvjApvnCXDQjtWcI1gQa+S
zT0tF543BRCtbLiJ5ealmdL13Goid3srsueWt4e69KEvpuT2oL5dHtlWY2KR+c4m
ozIFB8FppN+o3lFe1ZNmJxQKZVYbdC/L4o3FvNL6udHsTaBVYLcNDVWovf/hH2Q=
=QSWJ
-----END PGP SIGNATURE-----
2:20 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/11/2015 05: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).
I don't think we have a "super user" or "root". Do we actually
need one?
- We need to force "complex passwords", this is actually a
product
requirement
That could be enforced on Keycloak, via the same realm configuration
file. I'll take a look at how to configure that and will add. Do you
have a definition of "complex password"?
- 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.
Note that, right now, no file needs to be copied: we ship with a realm
template that does not contain any users. Opening the console when not
logged in presents the user with the login screen. If the user is not
registered yet, said user can self-register. This step (self-register)
is what is being questioned here: it's a PITA to self-register every
time a new build is done locally. So, to prevent self-registration, we
could ship with a default user.
In fact, I think we might have a third option: use the "dev" maven
profile to determine which realm template to use. If the "dev" profile
is active, then we can use the realm with a default user. Otherwise,
no default users.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVAJV+AAoJECKM1e+fkPrX8D4IAJiOU/ZgBhxpacbVW5Fv3CSt
H+ItVQz+qw8oVRNPdD/9LevmKr3wJXlCtzJV+YKvw5O7xVm/KmfWdHdKDpwRKgG8
EC7ETw8LZAN18Du5URMKWzgixZZdMBIcQeFZfzwuEGZjw4rIj66XtK/HXT+jLim+
KPqq3qq5p4nidOJmhO0oODQ7JXBJN/bifyrYvMG+wRTCrFwJdHpjk5RHnOU1DrLV
7TR3H8mtaX3PEjyGKxwmisEPdKgcWdeFuf7JAYybbyxLECpOVcz+tgQJUlxj+9I7
VRlvxE+uXl/sKHDhAay7xwYR5obJ0qXSWDjIQspoEceodOwqCDQYq0tJk74CnEE=
=rlWT
-----END PGP SIGNATURE-----
3:31 a.m.
On 03/11/2015 08:20 PM, Juraci Paixão Kröhling wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/11/2015 05: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).
I don't think we have a "super user" or "root". Do we actually
need one?
Ok, we just discussed that on IRC, for the records as I was afraid that
an admin would lock himself out by removing his own grants accidentally.
There are "owners" of resources, so they can't remove particular
privileges unless they transfer full ownership. (They are superuser of
their resources).
What is not yet defined is what happens when a user is deleted (who gets
control)
> - We need to force "complex passwords", this is
actually a product
> requirement
That could be enforced on Keycloak, via the same realm configuration
file. I'll take a look at how to configure that and will add. Do you
have a definition of "complex password"?
Same as default rules when you
add an admin user in EAP:
Password requirements are listed below. To modify these restrictions
edit the add-user.properties configuration file.
- The password must not be one of the following restricted values
{root, admin, administrator}
- The password must contain at least 8 characters, 1 alphabetic
character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
- The password must be different from the username
> - 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.
Note that, right now, no file needs to be copied: we ship with a realm
template that does not contain any users. Opening the console when not
logged in presents the user with the login screen. If the user is not
registered yet, said user can self-register. This step (self-register)
is what is being questioned here: it's a PITA to self-register every
time a new build is done locally. So, to prevent self-registration, we
could ship with a default user.
In fact, I think we might have a third option: use the "dev" maven
profile to determine which realm template to use. If the "dev" profile
is active, then we can use the realm with a default user. Otherwise,
no default users.
I quite like this idea, I would let developers comment if
that's
satisfactory.
Thomas
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVAJV+AAoJECKM1e+fkPrX8D4IAJiOU/ZgBhxpacbVW5Fv3CSt
H+ItVQz+qw8oVRNPdD/9LevmKr3wJXlCtzJV+YKvw5O7xVm/KmfWdHdKDpwRKgG8
EC7ETw8LZAN18Du5URMKWzgixZZdMBIcQeFZfzwuEGZjw4rIj66XtK/HXT+jLim+
KPqq3qq5p4nidOJmhO0oODQ7JXBJN/bifyrYvMG+wRTCrFwJdHpjk5RHnOU1DrLV
7TR3H8mtaX3PEjyGKxwmisEPdKgcWdeFuf7JAYybbyxLECpOVcz+tgQJUlxj+9I7
VRlvxE+uXl/sKHDhAay7xwYR5obJ0qXSWDjIQspoEceodOwqCDQYq0tJk74CnEE=
=rlWT
-----END PGP SIGNATURE-----
3:37 a.m.
+1 - dev profile to create default user, prod profile no users.
----- Original Message -----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/11/2015 05: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).
I don't think we have a "super user" or "root". Do we actually
need one?
> - We need to force "complex passwords", this is actually a product
> requirement
That could be enforced on Keycloak, via the same realm configuration
file. I'll take a look at how to configure that and will add. Do you
have a definition of "complex password"?
> - 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.
Note that, right now, no file needs to be copied: we ship with a realm
template that does not contain any users. Opening the console when not
logged in presents the user with the login screen. If the user is not
registered yet, said user can self-register. This step (self-register)
is what is being questioned here: it's a PITA to self-register every
time a new build is done locally. So, to prevent self-registration, we
could ship with a default user.
In fact, I think we might have a third option: use the "dev" maven
profile to determine which realm template to use. If the "dev" profile
is active, then we can use the realm with a default user. Otherwise,
no default users.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVAJV+AAoJECKM1e+fkPrX8D4IAJiOU/ZgBhxpacbVW5Fv3CSt
H+ItVQz+qw8oVRNPdD/9LevmKr3wJXlCtzJV+YKvw5O7xVm/KmfWdHdKDpwRKgG8
EC7ETw8LZAN18Du5URMKWzgixZZdMBIcQeFZfzwuEGZjw4rIj66XtK/HXT+jLim+
KPqq3qq5p4nidOJmhO0oODQ7JXBJN/bifyrYvMG+wRTCrFwJdHpjk5RHnOU1DrLV
7TR3H8mtaX3PEjyGKxwmisEPdKgcWdeFuf7JAYybbyxLECpOVcz+tgQJUlxj+9I7
VRlvxE+uXl/sKHDhAay7xwYR5obJ0qXSWDjIQspoEceodOwqCDQYq0tJk74CnEE=
=rlWT
-----END PGP SIGNATURE-----
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3572
days inactive
3573
days old
14 comments
7 participants
participants (7)
-
Alexandre Mendonca -
Gary Brown -
Heiko W.Rupp -
Juraci Paixão Kröhling -
Matt Wringe -
Peter Palaga -
Thomas Heute