[keycloak-dev] getting rid of master realm

[Stian Thorgersen]

+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.

One question with regards to trust users from one realm to another, how
would you manage role permissions? 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.

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:

* Improve SPIs - especially model SPIs and user federation SPIs
* Remove master realm
* Add role namespaces
* Clean-up URLs
* Clean-up admin endpoints
* Etc...

On 3 December 2015 at 20:06, Bill Burke <bburke at redhat.com> wrote:

> I'm thinking that getting rid of the master realm would allow us to
> clean up some things we've wanted to clean up for some time. Here's what
> I have in mind.
>
> * There is no master realm
> * Realm admins can create other realms
> * You can set up trust from one realm to another.  Just realms that are
> stored in that keycloak deployment.  No remote stuff.
> * To keep it simple, the admin console in the realm would just have a
> "Trust" tab somewhere with a list of realms you trust or want to trust.
>   When you trust a realm, any users that have admin roles in that
> trusted realm will have the same roles within the current realm.
> * When users log into the admin console, the list of realms that trust
> the logged into realm will be listed as realms the user can manage.
> * When a new realm is created, the new realm automatically trust the
> realm that created it.
> * If there is a trust relationship impersonation will work no matter
> what realm it is
> * We can remove the realm-management client in each realm and just merge
> the roles into security-admin-console.
> * For migration, we just import the master realm and set up trust
> between the master realm and every other realm.
>
>
> Once we do all this we can now look at satisfying the
> cannot-have-a-default-password requirement passed down by the security
> audit team.  We can have a welcome page that just asks "To create your
> first realm, click here".
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151203/c0985b25/attachment.html