<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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 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><div><br></div><div>Bolek.&nbsp;<br><div><div><br><div><div>On Oct 15, 2012, at 10:27 AM, Shane Bryzak &lt;<a 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 class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a 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 href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/security-dev<br></blockquote></div><br></div></div></div></body></html>