<div dir="ltr">I don't think the testsuite will be to hard. The old integration testsuite relies mostly on "demo" realm. The new have limited places that rely on the admin realm, but there's one abstract class everything inherits from so we can create the equivalent realm there.</div><div class="gmail_extra"><br><div class="gmail_quote">On 7 December 2015 at 08:40, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. </div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 4 December 2015 at 17:17, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would do this in 2 phases:<br>
<br>
Phase 1 keeps the master realm, but makes all the other changes we've<br>
talked about.<br>
<br>
Phase 2 ditches the master realm if we decide to do that. This might be<br>
problematic as I'm worried that our testsuite depends heavily on the<br>
master realm existing.<br>
<div><div><br>
On 12/3/2015 3:33 PM, Bill Burke wrote:<br>
><br>
><br>
> On 12/3/2015 2:19 PM, Stian Thorgersen wrote:<br>
>> +1000<br>
>><br>
>> This would simplify a lot of things. Currently, even though I know the<br>
>> code pretty well, I still get confused when it comes to admin roles,<br>
>> master admin clients and all that jazz.<br>
>><br>
>> It would also simplify the admin endpoints and we can drop "realms" from<br>
>> urls. We could also drop "auth" from urls on the standalone Keycloak<br>
>> server. That would make URLs nicer. So it would be:<br>
>><br>
>> /<realm name>/protocol/openid-connect/<br>
>> /<realm name>/admin<br>
>><br>
>> Instead of what we have atm:<br>
>><br>
>> /auth/realms/<realm name>/protocol/openid-connect/<br>
>> /auth/realms/<realm name>/admin<br>
>><br>
>> I think we should have a dedicated create-realm role, rather than allow<br>
>> admin to do it. We should make it possible to enable/disable realm<br>
>> creation from within a specific realm.<br>
>><br>
><br>
> We do have a create-realm role.<br>
><br>
>> One question with regards to trust users from one realm to another, how<br>
>> would you manage role permissions?<br>
><br>
> What do you mean? I was thinking of something *REALLY* simple. If<br>
> Realm A trusts Realm B and User X in Realm B has "manage-clients" role<br>
> in Realm B, then he can manage clients in Realm A. That way you don't<br>
> have to deal with actual users, just roles. Does that make sense?<br>
><br>
><br>
> I think all permissions from one<br>
>> realm should be managed within the realm. We should also hide the<br>
>> security-admin-console from the clients list.<br>
>><br>
><br>
><br>
><br>
><br>
>> We also need to figure out how to prevent the admin escalation problem<br>
>> we have. It should be possible to configure what roles a specific admin<br>
>> is allowed to grant to users.<br>
>><br>
><br>
> This is a different feature. This would not be what roles a specific<br>
> admin is allowed to grant, but rather what roles a specific role can<br>
> grant. Take the user out of the equation.<br>
><br>
>> One question though. Instead of having many changes in 1.8 would it make<br>
>> more sense to just say enough is enough. Let's get started on 2.x and be<br>
>> a bit more free with breaking backwards compatibility. Then in 2.x we could:<br>
>><br>
><br>
> I don't know what the best thing is to do. I'm worried about having<br>
> enough time to bake stuff in community, but also don't want ugly shit<br>
> sitting in product for the next 10 years. See what we can get in by end<br>
> of December then release 1.8 mid January and stabilize until March?<br>
> Encourage people to upgrade to 1.8 at least to test drive?<br>
><br>
><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
</div></div><div><div>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>