Internal concept of user groups

[oyvindhagberg]

• This will enable API keys to be owned by a user group instead of a single user
• When a user's access is revoked, his keys should not stop working. Hence, a key's access can't be determined by looking at the user who created it.
  • Using the access level from the user group instead just moves the problem, sort of
  • The hope is that a user group is likely to be more stable and long-lasting than a user
  • If possible, we should use group id, not name, as identificator.
• When someone logs in, user group memberships should be determined automatically by a plugin by Nivlheim using LDAP to look it up, based on the user ID.
  • A primary group (the organizational unit) and a list of user group memberships
• Machines should be owned by user groups
  • How and when will ownership be determined? Nivlheim will call a plugin (cgi script) each time a new machine shows up, and for existing machines without ownership. The plugin will determine group ownership and update Nivlheim. This will be handled by the internal task runner (queuing, re-trying failed calls, etc.)
  • What about personal computers? Laptops etc. The ownership will be set to the person's primary group.
  • Each machine is owned by only one group
• When someone creates a new API key, they must specify which user group(s) it is associated with.
  • When using the key, you can only "see" machines owned by those user groups.
  • The key must be owned by the primary group of the user who created it, but can be associated with many other groups.
  • Keys are editable for members of the primary group of the user who originally created the key, even if that user gets deleted/revoked/moved to a different group.