<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 17/10/12 03:43, Boleslaw Dawidowicz
      wrote:<br>
    </div>
    <blockquote
      cite="mid:CA1BC6D8-FEBE-415B-8741-3AC6E570D621@redhat.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      I like this. One of biggest mistakes I made in the original model
      was to define separate notion of user-group relationship. &nbsp;Design
      where direct relationship is just another type of role (either
      'member' or null) is much more elegant.&nbsp;
      <div><br>
      </div>
      <div>The only concern is to keep Group tree and LDAP use case in
        mind.</div>
      <div><br>
      </div>
      <div><a moz-do-not-send="true"
href="https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/model/Group.java">https://github.com/picketlink/picketlink/blob/master/idm/api/src/main/java/org/picketlink/idm/model/Group.java</a></div>
      <div><br>
      </div>
      <div>Path id is in place to ensure name uniqueness in the tree.
        You can have a/b/a/b/a - which result in 3 groups with name "a"
        and 2 groups with name "b". Then question is if this path should
        be resolved on the fly from IdentityMembership (huge performance
        cost and implementation nightmare) or stored as an id in
        IdentityObject table during object creation. Second option is
        better however name also persists relationships between groups
        from the start. I have chosen first approach in PLIDM 1.x and
        this was my second biggest regret - mostly because of
        performance cost.</div>
    </blockquote>
    <br>
    The LDAP use case is a good point - I'll need to think about it some
    more, but I think we can make the path validation an implementation
    detail.&nbsp; I agree we should go with the second option for the LDAP
    implementation (because of it's strict tree structure), however I'm
    thinking for JPA (in which we don't have the same restrictions) we
    should possibly allow a Group to be a member of more than one parent
    group.&nbsp; It's conceivable that there's use cases that require this,
    however I'm not totally sold on the idea and would like to hear some
    feedback.<br>
    <br>
    <blockquote
      cite="mid:CA1BC6D8-FEBE-415B-8741-3AC6E570D621@redhat.com"
      type="cite">
      <div><br>
      </div>
      <div>Bolek.&nbsp;<br>
        <div>
          <div><br>
            <div>
              <div>On Oct 15, 2012, at 10:27 AM, Shane Bryzak &lt;<a
                  moz-do-not-send="true"
                  href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>&gt;
                wrote:</div>
              <br class="Apple-interchange-newline">
              <blockquote type="cite">
                <meta content="text/html; charset=ISO-8859-1"
                  http-equiv="Content-Type">
                <div bgcolor="#FFFFFF" text="#000000">
                  <div class="moz-cite-prefix">I should clarify
                    something.&nbsp; It is entirely possible for a user to
                    have a role in a group without being a member of
                    that group.&nbsp; One of the good use cases that someone
                    from the team informed me about previously is an
                    administrator for a group of doctors.&nbsp; The
                    membership scenario would look like this:<br>
                    <br>
                    IdentityMembership<br>
                    -------------------------<br>
                    MEMBER = Bill (User)<br>
                    GROUP = Doctors<br>
                    ROLE = Admin<br>
                    <br>
                    In this case, Bill (the user) would not be a member
                    of the Doctors group himself, he would simply be an
                    administrator for the group.&nbsp; If he were to be a
                    member of the group (as well as an Administrator)
                    then that would require the following additional
                    record:<br>
                    <br>
                    IdentityMembership<br>
                    -------------------------<br>
                    MEMBER = Bill (User)<br>
                    GROUP = Doctors<br>
                    ROLE = null<br>
                    <br>
                    So, in a nutshell - if a Role is specified, it means
                    the member has that role for the specified group,
                    however the member is not an actual member of the
                    group themselves.&nbsp; Hope that makes sense!<br>
                    <br>
                    <br>
                    On 15/10/12 18:19, Shane Bryzak wrote:<br>
                  </div>
                  <blockquote cite="mid:507BC72E.8020105@redhat.com"
                    type="cite">
                    <meta http-equiv="content-type" content="text/html;
                      charset=ISO-8859-1">
                    No, not that kind.&nbsp; I'm currently reviewing the
                    database schema for the identity management module -
                    in the previous version of PicketLink we had quite a
                    good design [1] that was a little abstract, but met
                    all the requirements well.&nbsp; Here's a summary of the
                    key tables:<br>
                    <br>
                    IdentityObject - this table would contain both User
                    and Group records<br>
                    IdentityObjectRelationship - models the relationship
                    between User and Group, i.e. Group memberships<br>
                    IdentityObjectRelationshipName - this table is a
                    special one that contained the names for "named
                    relationships".&nbsp; A named relationship can
                    effectively be thought of as a Role, (and was also
                    modelled in the IdentityObjectRelationship table)
                    for example "John" (User) is a "Manager" (Role, the
                    "named" bit of the relationship) in "Head Office"
                    (Group) - see [2] for more details.<br>
                    <br>
                    With the introduction of application roles we need
                    to jig this design a little bit.&nbsp; I was thinking of
                    keeping IdentityObject essentially the same, with
                    the exception that it would also be used to contain
                    Roles, as well as Users and Groups.&nbsp; Instead of the
                    IdentityObjectRelationship table though, I propose
                    we go with the following slightly less abstract
                    design:<br>
                    <br>
                    IdentityMembership<br>
                    -------------------------<br>
                    MEMBER<br>
                    GROUP<br>
                    ROLE<br>
                    <br>
                    This basically allows us to make any IdentityType
                    (User, Group or Role) a member of a Group or Role,
                    or both.&nbsp; Here's a few scenarios:<br>
                    <br>
                    1. John is a part of the accounting group.<br>
                    <br>
                    IdentityMembership<br>
                    -------------------------<br>
                    MEMBER = John (User)<br>
                    GROUP = accounting<br>
                    ROLE = null<br>
                    <br>
                    2. The Manager group is a subgroup of the Employee
                    group.<br>
                    <br>
                    IdentityMembership<br>
                    -------------------------<br>
                    MEMBER = Manager (Group)<br>
                    GROUP = Employee<br>
                    ROLE = null<br>
                    <br>
                    3. Kevin is an administrator for the Manager group<br>
                    <br>
                    IdentityMembership<br>
                    -------------------------<br>
                    MEMBER = Kevin (User)<br>
                    GROUP = Manager<br>
                    ROLE = Admin<br>
                    <br>
                    4. Kelly is a superuser (which is an application
                    role)<br>
                    <br>
                    IdentityMembership<br>
                    -------------------------<br>
                    MEMBER = Kelly (User)<br>
                    GROUP = null<br>
                    ROLE = Superuser<br>
                    <br>
                    With the above examples in mind, this now leads into
                    the "meaningful relationships" theme - can anyone
                    think of any other meaningful security relationships
                    that cannot be modelled with this design?&nbsp; I'm not
                    really looking to make the design "future proof" as
                    such, but I would like to ensure we cover all
                    currently known scenarios / use cases.&nbsp; Comments and
                    feedback welcome of course.<br>
                    <br>
                    <br>
                    [1]
                    <meta http-equiv="content-type" content="text/html;
                      charset=ISO-8859-1">
                    <a moz-do-not-send="true"
href="http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#spi_model">http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#spi_model</a><br>
                    [2]
                    <meta http-equiv="content-type" content="text/html;
                      charset=ISO-8859-1">
                    <a moz-do-not-send="true"
href="http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e342">http://anonsvn.jboss.org/repos/picketlink/idm/downloads/docs/1.0.0.GA/ReferenceGuide/en-US/html_single/index.html#d0e342</a>
                    <br>
                    <fieldset class="mimeAttachmentHeader"></fieldset>
                    <br>
                    <pre wrap="">_______________________________________________
security-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a>
</pre>
                  </blockquote>
                  <br>
                  <br>
                </div>
                _______________________________________________<br>
                security-dev mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a><br>
                <a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a><br>
              </blockquote>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
  </body>
</html>