I was thinking a bit more about trust between realms and I think that should be limited to authentication only. An admin with certain roles in one realm shouldn't necessarily have the same roles in another realm. So I think we need either a user that can exist in multiple realms or utilize identity brokering to get "linked" users. I'm worried if we allow roles from one realm to give admin permissions in another it will be hard to get a full picture of who has access to the realm. It may also give unintentional permissions. Also, if we introduce admins that can only manage a "group" of users or roles that specify what roles an admin can grant that would require users in the specific realm to manage. 

On 4 December 2015 at 17:17, Bill Burke <bburke@redhat.com> wrote:
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev