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

[Alexandre Mendonca]

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 at redhat.com>
To: jpkroehling at redhat.com, hawkular-dev at 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.
> -----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