+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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev