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