<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 7:52 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAeU6zO2uW9yAhOu1CV5oyA9HJruCQnRdgWCqBds7sUpUA@mail.gmail.com"
type="cite">
<div dir="ltr">I disagree. Firstly we're not adding Permissions
now. Secondly the Group is either part of the Subject or it's
the equivalent of a Role, that depends on policies (which are
SE), not the mapping of Permissions to the Subject.</div>
</blockquote>
We have a completely different idea of what a Group is. That's OK.
At least we are finally using the same vocabulary.<br>
<br>
For the sake of this discussion, does it matter that we're not
adding Permissions now? We are planning this, right?<br>
<br>
There are several implementations of NIST RBAC out there. I wonder
if there is a good open source one we could just plug in.<br>
<blockquote
cite="mid:CAJgngAeU6zO2uW9yAhOu1CV5oyA9HJruCQnRdgWCqBds7sUpUA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Following your argument if you had allowed assigning
permissions based on dob then the dob of a user would be an
SE.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 6 November 2015 at 13:31, 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/6/2015 1:48 AM, Stian Thorgersen wrote:<br>
</div>
<blockquote 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>
<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><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>
</span> 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.
<div>
<div class="h5"><br>
<blockquote 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><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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>