[keycloak-dev] getting rid of master realm

[Marek Posolda]

On 03/12/15 20:19, 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.
>
> 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.
Generally I am not sure if we should hide things from users. Isn't it 
better to add some "system" flag, so people can see that this is special 
builtin client?

Personally I don't like systems, which hide things from users. It 
usually adds confusions. Especially when you are newbie and you try to 
understand things (for example: How is possible that I am seeing 
security-admin-client roles here, when I am not seeing 
security-admin-console in client list? How is possible I am seeing 
client_id=security-admin-console in the URI, but there is not any client 
called security-admin-console in the list? etc. ).

IMO Keycloak admins are usually technical users and want to understand 
things. Also IMO  admin console should allow everything which is 
possible through direct DB updating.

Marek
>
> 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 
> <mailto: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 <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> 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/20151207/c9f8ac0d/attachment.html