</table>

# Group Memberships

## Requirements

* A principal can be added to a group, with a particular role in that group
* A principal can be removed from a group
* A principals role in a group can be updated
* A group role has the same restrictions as a regular role: it can be any arbitrary string defined by the consumer of the group membership
* It should be possible to determine all the direct members of a group
* It should be possible to determine, given a principal, all the groups of which they are a member, either directly or VIA indirect membership (e.g., member of a group, which is a member of a group, etc...)

## Data Model

### Column Family: GroupMembers

A dynamic column family that enumerates the principals that are a member of a group.

**Row Key:** The UUID of the group whose membership follows (e.g., g:cam:group-id)

**Column Names:** The column names are the principal UUIDs that are a member of the group in some capacity (e.g., u:cam:mrvisser)

**Column Values:** The value of each column is the role that the principal has in the group

<table>
  <thead>
    <tr>
      <th>Row Key (group)
  <tbody>
    <tr>
      <th>g:oae:oae-team
      <th>g:oae:oae-backend
      <th>g:oae:oae-frontend
      <th>u:oae:anthony
    <tr>
      <td>
      <td>member
      <td>member
      <td>manager
    <tr>
      <th>g:oae:oae-backend
      <th>u:oae:mrvisser
      <th>u:oae:simong
      <th>u:gat:stuartf
    <tr>
      <td>
      <td>member
      <td>member
      <td>member
    <tr>
      <th>g:oae:oae-frontend
      <th>u:oae:bert
      <th>u:oae:nicolaas
      <th>u:gat:stuartf
    <tr>
      <td>
      <td>member
      <td>member
      <td>member
</table>
 
# Group Membership

Group Membership for a given principal is managed using the Roles CF directly, by using a group as a resource, and assigning a principal a role on the group resource. This is done internally, so as to avoid the group-resource restrictions of the roles API. See group-related use-cases in the Roles CF for more information on how the requirements of group membership are fulfilled.

**Note about fault tolerance:** Adding a user membership to GroupMembers and Roles CF's is a batch operation, however there is still possibility for incomplete updates. That said, since the Roles CF determines the effective group membership for permissions checks, the GroupMembership CF should always have a membership added first, then Roles second. When removing membership, Roles CF entry should be deleted first, then GroupMembership second. In this case, you never end up with a case in which a user unknowingly has access to content while data is in an inconsistent state.
 
# Permissions

Individual permission actions are currently synonymous to roles. For example, if a user has the 'manager' role on a resource, it is the 'manager' permission that you would have to check for that user to see if they can manage. Currently, there is no feature to assign a number of individual actions to roles on a resource, as this permission model is currently not used in the application. It is likely one day it may, in which case some permission logic will have to change.

The difference between checking a permission for a principal+resource and checking a role between a principal+resource, is that permission checks are inherited VIA group memberships. Therefore if user **mrvisser** is a member of a group that has **manager** access on resource **Foo.docx**: Does mrvisser have **manager role** on **Foo.docx**? No; Does mrvisser have **manager permission** on **Foo.docx**? Yes.

A heavy permission check is to use the existing CF's, and group membership ancestry technique discussed in the Roles query use cases. The authz module will over the group membership ancestry to determine if one has the permission. This is done through a series of Cassandra 'multi-gets'.