[keycloak-dev] getting rid of master realm

[Bill Burke]

I would do this in 2 phases:

Phase 1 keeps the master realm, but makes all the other changes we've 
talked about.

Phase 2 ditches the master realm if we decide to do that.  This might be 
problematic as I'm worried that our testsuite depends heavily on the 
master realm existing.

On 12/3/2015 3:33 PM, Bill Burke wrote:
>
>
> 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