<div dir="ltr">We're only providing parts of RBAC now. The complete picture is what Pedro is working on with his AuthZ service.<div><br></div><div><div>From the definitions above we're actually only providing S and R. SE is not a group as a group doesn't provide any permissions.</div></div><div><br></div><div>I'm not 100% sure what the group would be in the above, but I would think it's just part of S. A group is simply a means of assigning a role to a group of users.<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 November 2015 at 20:24, Stan Silvert <span dir="ltr"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>We could do a lot worse than just
following the basic RBAC design described on Wikipedia:<br>
<a href="https://en.wikipedia.org/wiki/Role-based_access_control" target="_blank">https://en.wikipedia.org/wiki/Role-based_access_control</a><br>
<br>
Right now we're arguing over both definitions AND
implementations. It's impossible to design this over email if we
can't even settle on definitions.<br>
<br>
Therefore, I propose we just use the definitions in wikipedia. At
least it's neutral. <br>
<ul>
<li>S = Subject = A person or automated agent</li>
<li>R = Role = Job function or title which defines an authority
level</li>
<li>P = Permissions = An approval of a mode of access to a
resource</li>
<li>SE = Session = A mapping involving S, R and/or P</li>
<li>SA = Subject Assignment</li>
<li>PA = Permission Assignment</li>
<li>RH = Partially ordered Role Hierarchy. RH can also be
written: ≥ (The notation: x ≥ y means that x inherits the
permissions of y.)
<ul>
<li>A subject can have multiple roles.</li>
<li>A role can have multiple subjects.</li>
<li>A role can have many permissions.</li>
<li>A permission can be assigned to many roles.</li>
<li>An operation can be assigned many permissions.</li>
<li>A permission can be assigned to many operations.</li>
</ul>
</li>
</ul>
<br>
Note: In my mind, S = keycloak user, and SE = keycloak group. But
whatever, as long as we agree on definitions we can then decide
what flavor of RBAC to implement.<div><div class="h5"><br>
<br>
On 11/5/2015 1:44 PM, Stian Thorgersen wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 5 November 2015 at 15:01, Bill
Burke <span dir="ltr"><<a 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"><span><br>
<br>
On 11/5/2015 6:23 AM, Stian Thorgersen wrote:<br>
</span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<br>
On 3 November 2015 at 22:20, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
</span><span>
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>>
wrote:<br>
<br>
In my previous email I talked about combining
Groups and Role<br>
Namespaces. Now I want to talk about User Groups
vs. Client Groups.<br>
<br>
User Groups would manage a set of users. Members
would automatically<br>
inherit a set of "permissions": a set of roles.
User Groups would also<br>
provide a set of attributes that the user
inherits.<br>
<br>
<br>
Permission != role<br>
<br>
<br>
I'd like to introduce the concept of a Client
Group. Client Group would<br>
have:<br>
<br>
* Roles - basically a role namespace<br>
<br>
<br>
-1 Having roles tied to a client or client group is
exactly what we<br>
should go away from. IMO role namespaces should be a
completely separate<br>
thing.<br>
<br>
</span></blockquote>
<br>
I don't agree at all. If User Groups and Client Groups
exist, there is no need for role namespaces. It is stupid
to have to create another concept (role namespace) to
define the roles one specific client or a group of clients
expects.<br>
</blockquote>
<div><br>
</div>
<div>I've never the concept of realm and client roles. It's
been difficult to explain and strange to use. I've always
just used realm roles. It's a strange and limiting
concept. Introducing client groups with further places to
define roles just makes matters even worse. Now users have
two go 3 different places to define roles:</div>
<div><br>
</div>
<div>* Realm</div>
<div>* Client Groups</div>
<div>* Clients</div>
<div><br>
</div>
<div>What happens if a client group and a client both have
the same role by the way?</div>
<div><br>
</div>
<div>It's a strange limitation. At least personally if I was
using Keycloak I would simply use realm roles alone and
define my own hierarchy with a delimiter.</div>
<div><br>
</div>
<div>It's much better to have a single place to define
roles, under the roles tab. Then allow users can define
the namespaces/hierarchy they want.</div>
<div><br>
</div>
<div>Role namespaces are easier to deal with and at the same
time more flexible. </div>
<div><br>
</div>
<div>I just don't see any reason why we would have roles
specific to a client or client group.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you combine Role namespace and Groups you can define
things like a group admin role. Roles that mean something
to the group.<span><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Each Client Group would have some default roles
defined. i.e. roles<br>
that allow a user to edit any client in the client
group.<br>
<br>
<br>
I don't understand this<br>
<br>
</blockquote>
<br>
</span>
A Client Group could have a "client group admin" role. If
a user has that role it can manage clients in the group.
Another role might be "client membership admin". This
role allows a user to add or remove clients from the
group.<br>
<br>
Conversely, user groups could have a "user group admin".
When granted, this role allows a user to manage users in
the group. YOu can also do things like define a "Manager"
role for the group. This "Manager" would be granted "user
group admin" privileges and also granted access to other
systems like "HR", "Attendence", "Benefits", etc.<br>
<br>
I think this permission concept should be built into
Keycloak as it is a core feature. I'll write u a separate
email about this.</blockquote>
<div><br>
</div>
<div>This is another reason why we need role namespaces.
With a role namespace we can define internal roles that
then don't end up conflicting with users own roles. For
example as we have a role admin atm users can't define
their own admin role and will have to name it differently.</div>
<div><br>
</div>
<div>I think the fact that we have internal abstract clients
to be able to create a namespace for internal admin roles
speaks for itself. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Each Client would have the same configuration
options. They would be<br>
able to have an additional set of roles,
permissions, scope, and<br>
overridable Protocol Policies.<br>
<br>
<br>
Same comment as above - why would a client have
roles/permissions? I<br>
assume we where moving away from that with role
namespaces<br>
<br>
</blockquote>
<br>
</span>
Again, I think role namespaces are redundant.<br>
<br>
A client can define a set of roles that it offers. A
service account (the client) can have roles associated
with it so it can do certain actions.</blockquote>
<div><br>
</div>
<div>Some will want to have roles associated with a client
(email-user), but others have organizational wide roles
(manager, sales-guy, etc..). Role namespaces can deal with
both, but client roles can't.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div><br>
<br>
<br>
<br>
-- <br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=""><pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>