[keycloak-dev] getting rid of master realm

[Bill Burke]

On 12/3/2015 2:19 PM, Stian Thorgersen wrote:
> +1000
>
> This would simplify a lot of things. Currently, even though I know the
> code pretty well, I still get confused when it comes to admin roles,
> master admin clients and all that jazz.
>
> It would also simplify the admin endpoints and we can drop "realms" from
> urls. We could also drop "auth" from urls on the standalone Keycloak
> server. That would make URLs nicer. So it would be:
>
> /<realm name>/protocol/openid-connect/
> /<realm name>/admin
>
> Instead of what we have atm:
>
> /auth/realms/<realm name>/protocol/openid-connect/
> /auth/realms/<realm name>/admin
>
> I think we should have a dedicated create-realm role, rather than allow
> admin to do it. We should make it possible to enable/disable realm
> creation from within a specific realm.
>

We do have a create-realm role.

> One question with regards to trust users from one realm to another, how
> would you manage role permissions?

What do you mean?  I was thinking of something *REALLY* simple.  If 
Realm A trusts Realm B and User X in Realm B has "manage-clients" role 
in Realm B, then he can manage clients in Realm A.  That way you don't 
have to deal with actual users, just roles.  Does that make sense?


I think all permissions from one
> realm should be managed within the realm. We should also hide the
> security-admin-console from the clients list.
>




> We also need to figure out how to prevent the admin escalation problem
> we have. It should be possible to configure what roles a specific admin
> is allowed to grant to users.
>

This is a different feature.  This would not be what roles a specific 
admin is allowed to grant, but rather what roles a specific role can 
grant.  Take the user out of the equation.

> One question though. Instead of having many changes in 1.8 would it make
> more sense to just say enough is enough. Let's get started on 2.x and be
> a bit more free with breaking backwards compatibility. Then in 2.x we could:
>

I don't know what the best thing is to do.  I'm worried about having 
enough time to bake stuff in community, but also don't want ugly shit 
sitting in product for the next 10 years.  See what we can get in by end 
of December then release 1.8 mid January and stabilize until March? 
Encourage people to upgrade to 1.8 at least to test drive?


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com