<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">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>
  </body>
</html>