I strongly feel this is a mistake. We need to find a way to make the admin console use
Keycloak without any hacks. In my opinion the admin console should use keycloak.js as
it's a client-side application. For client-side applications the credentials should be
public so can just be pre-configured to a well-known string.
Safety of client-side applications are provided by two things: firstly the application
credentials themselves don't give you any privileges, secondly the redirect uri should
be verified by Keycloak preventing unauthorized use of the credentials.
If we can't come up with a good and safe approach to using Keycloak with HTML5 and
mobile applications the project is a huge fail! If we're not using it directly
ourselves for our HTML5 console that doesn't sound right to me.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 16 October, 2013 2:22:10 PM
Subject: [keycloak-dev] changes to admin ui login/bootstrap
There are some changes on how Keycloak Admin UI is bootstrapped:
* There is no longer a registration page for the admin ui.
* There is a built in user
username: admin
password: admin
* There is a built in realm "Keycloak Adminstration"
* This realm has a built in application "Admin Console" with one role:
"admin"
* You can add additional users to the "Keycloak Adminstration" realm.
They must add an Admin Consle "admin" role to be able to log into the
admin UI.
Eventually, the bootstrap will require a "password update" for this
built-in "admin" user. There's a bug in the admin UI login on the
server side that I haven't figured out yet. I'll ping the list when this
is ready.
Going forward, the admin REST interfaces/admin UI will *NOT* use the
token service. We can't use the token service out of the box for the
admin UI/REST interfaces because this would require specifying the
Application password for the "Admin Console" and enabling it through the
UI. For usability, IMO, it is best that the user doesn't have to do this.
You will still be able to use the Token Service's OAuth flow to obtain
an access token. The admin REST interface should support bearer token
access, although I haven't written any tests for it yet.
BTW, the "Admin Console" application has a random, large, password
generated for it at bootstrap. A side effect is that this password is
never known. We need to generate a random, unknown password for this to
avoid a security hole and to keep the nice usability. Hope I make sense
here. :)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev