<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">&lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>&gt;</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&#39;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&#39;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&#39;re actually only providing
            S and R. SE is not a group as a group doesn&#39;t provide any
            permissions.</div>
        </div>
      </div>
    </blockquote></span>
    Maybe that&#39;s a good reason to stick with the definitions below.  I
    see &quot;Group&quot; as a way to implement the mapping called for in SE.  But
    it doesn&#39;t have to be that way.</div></blockquote><div><br></div><div>Group is not SE, I&#39;m pretty sure of that. A group is just an &quot;attribute&quot; of the subject. It doesn&#39;t &quot;provide&quot; any permissions or any mapping between subjects and permissions.</div><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&#39;m not 100% sure what the group would be in the above, but
          I would think it&#39;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">&lt;<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>&gt;</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&#39;re arguing over both definitions AND
                implementations.  It&#39;s impossible to design this over
                email if we can&#39;t even settle on definitions.<br>
                <br>
                Therefore, I propose we just use the definitions in
                wikipedia.  At least it&#39;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">&lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;</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
                                &lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
                              </span><span> &lt;mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;&gt;

                                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 &quot;permissions&quot;: 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&#39;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&#39;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&#39;ve never the concept of realm and
                            client roles. It&#39;s been difficult to explain
                            and strange to use. I&#39;ve always just used
                            realm roles. It&#39;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&#39;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&#39;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&#39;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&#39;t understand this<br>
                                <br>
                              </blockquote>
                              <br>
                            </span> A Client Group could have a &quot;client
                            group admin&quot; role.  If a user has that role
                            it can manage clients in the group.  Another
                            role might be &quot;client membership admin&quot;. 
                            This role allows a user to add or remove
                            clients from the group.<br>
                            <br>
                            Conversely, user groups could have a &quot;user
                            group admin&quot;.  When granted, this role
                            allows a user to manage users in the group. 
                            YOu can also do things like define a
                            &quot;Manager&quot; role for the group.  This
                            &quot;Manager&quot; would be granted &quot;user group
                            admin&quot; privileges and also granted access to
                            other systems like &quot;HR&quot;, &quot;Attendence&quot;,
                            &quot;Benefits&quot;, etc.<br>
                            <br>
                            I think this permission concept should be
                            built into Keycloak as it is a core
                            feature.  I&#39;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&#39;t end up
                            conflicting with users own roles. For
                            example as we have a role admin atm users
                            can&#39;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&#39;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>
                  <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" target="_blank">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>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div></div>