<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 03/12/15 20:19, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAeWpZhZF+BeuyWxTo1_6E2Mu3JjOe0nU9Q-DUuvz7Q4oQ@mail.gmail.com"
type="cite">
<div dir="ltr">+1000
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>/<realm name>/protocol/openid-connect/</div>
<div>/<realm name>/admin</div>
<div><br>
</div>
<div>Instead of what we have atm:</div>
<div><br>
</div>
<div>
<div>/auth/realms/<realm name>/protocol/openid-connect/</div>
<div>/auth/realms/<realm name>/admin</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
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? <br>
<br>
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. ).<br>
<br>
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.<br>
<br>
Marek<br>
<blockquote
cite="mid:CAJgngAeWpZhZF+BeuyWxTo1_6E2Mu3JjOe0nU9Q-DUuvz7Q4oQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>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.</div>
</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>* Improve SPIs - especially model SPIs and user federation
SPIs</div>
<div>* Remove master realm</div>
<div>* Add role namespaces</div>
<div>* Clean-up URLs</div>
<div>* Clean-up admin endpoints</div>
<div>* Etc...</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 3 December 2015 at 20:06, Bill Burke
<span dir="ltr"><<a moz-do-not-send="true"
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'm
thinking that getting rid of the master realm would allow us
to<br>
clean up some things we've wanted to clean up for some time.
Here's what<br>
I have in mind.<br>
<br>
* There is no master realm<br>
* Realm admins can create other realms<br>
* You can set up trust from one realm to another. Just
realms that are<br>
stored in that keycloak deployment. No remote stuff.<br>
* To keep it simple, the admin console in the realm would
just have a<br>
"Trust" tab somewhere with a list of realms you trust or
want to trust.<br>
When you trust a realm, any users that have admin roles in
that<br>
trusted realm will have the same roles within the current
realm.<br>
* When users log into the admin console, the list of realms
that trust<br>
the logged into realm will be listed as realms the user can
manage.<br>
* When a new realm is created, the new realm automatically
trust the<br>
realm that created it.<br>
* If there is a trust relationship impersonation will work
no matter<br>
what realm it is<br>
* We can remove the realm-management client in each realm
and just merge<br>
the roles into security-admin-console.<br>
* For migration, we just import the master realm and set up
trust<br>
between the master realm and every other realm.<br>
<br>
<br>
Once we do all this we can now look at satisfying the<br>
cannot-have-a-default-password requirement passed down by
the security<br>
audit team. We can have a welcome page that just asks "To
create your<br>
first realm, click here".<br>
<span class="HOEnZb"><font color="#888888">--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a moz-do-not-send="true"
href="http://bill.burkecentral.com" rel="noreferrer"
target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</font></span></blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>