What are the downsides of having a "shared" admin realm?
We can fine-grained access control, so individual admins/users can be limited to only
manage certain realms (or none at all).
Another related thing is I wonder if we could share users (and maybe even do sso) cross
realms? I can imagine situations where people wants multiple realms to manage token
settings, social settings, applications, etc, but still want to let users have a single
account, instead of one per-realm. We already support authenticating users with a
different realm, but I was wondering if we could make it a more integrated feature, as
well as support sso.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 1 May, 2014 3:37:46 AM
Subject: [keycloak-dev] management problems
Our current "master realm" structure/design is deficient. Consider an
application like UPS that wants to use Keycloak to manage users. This
application would also have its own management console whose security is
also managed by keycloak.
My first thought is that you could define the application's management
console as an application in the "master" keycloak realm. This solution
isn't a great one if the keycloak server is managing multiple realms.
So, IMO not something we should recommend.
Another option is to define admin roles within the application's realm
itself. These roles are assignable to users within the realm. This
would require rethinking of the Angular JS admin console and how things
are authenticated and how people log-in. We should probably treat this
as SSO and have individual applications within the application realm,
for example:
UPS Realm registered applications:
realm-management (keycloak admin console)
aerogear-ups-management (ups admin console)
--
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