<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/6/2015 1:48 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAeh6wZ6BE=1ADEUiSAJDfCZepZz_4ANfHPFLCgwVT_g=A@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 5 November 2015 at 21:40, Stan
Silvert <span dir="ltr"><<a moz-do-not-send="true"
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"><span class="">
<div>On 11/5/2015 2:36 PM, Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<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>
</blockquote>
</span> Yea, as I understand it, Pedro is doing P. (P
for Pedro!) And also, he's filling in the rest of the
gaps surrounding P.<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<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>
</blockquote>
</span> Maybe that's a good reason to stick with the
definitions below. I see "Group" as a way to implement
the mapping called for in SE. But it doesn't have to be
that way.</div>
</blockquote>
<div><br>
</div>
<div>Group is not SE, I'm pretty sure of that. A group is
just an "attribute" of the subject. It doesn't "provide"
any permissions or any mapping between subjects and
permissions.</div>
</div>
</div>
</div>
</blockquote>
Let's say you allow Permissions and Roles to be assigned to a
Group. And you also design it such that any Subject who becomes a
member of the group also gets the assigned Permissions and Roles.
In that case, you have implemented a Group that acts as the SE.<br>
<blockquote
cite="mid:CAJgngAeh6wZ6BE=1ADEUiSAJDfCZepZz_4ANfHPFLCgwVT_g=A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<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
moz-do-not-send="true"
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 moz-do-not-send="true"
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><br>
<br>
On 11/5/2015 1:44 PM, Stian
Thorgersen wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<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
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"><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
moz-do-not-send="true"
href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
</span><span> <mailto:<a
moz-do-not-send="true"
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
moz-do-not-send="true"
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>
<pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
target="_blank">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>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>