cross-realm user doesn't solve the problem of having an integrated admin
experience for apps like Aerogear UPS.
On 5/1/2014 5:23 AM, Stian Thorgersen wrote:
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
>