Now that we have login authentication for the portal, the next step is
to come up with an infrastructure for granting and enforcing
permissions on objects.
At the moment I'd like to follow the same overall approach that we
took for oVirt, with a few modifications.
At the lowest level, we maintain a list of "privileges" in the
database which represent a particular type of allowed action. These
could be very fine-grained levels such as "start instance", "create
instance", "create pool", "view instance statistics", "grant user
access", etc., or we could use more general privileges such as
"modify", "view", "control instances", etc.
Privileges will be fairly closely tied to available actions, so we
would not provide an API to add/remove these -- they're fairly closely
tied to the actions we've already implemented in the portal code.
Going up one level, a "role" is an associated group of privileges (but
not yet tied to a particular resource). Roles exist mainly for
convenience -- a set of privileges often used together are grouped in
a role to simplify granting permissions to a user. So, for example, an
"admin" role might combine "create instance", "create Pool", "start
Instance", etc. -- or if we're using less fine-grained privileges,
"admin" might include "create", "modify", and "view" privileges.
For oVirt we never got to the point of providing an API for
manipulating roles (i.e. create a new role that combines privileges X,
Y, and Z), but we could do that here as a future enhancement.
A Permission record (or perhaps "granted permission") associates a
user with a resource and a particular role. For example, when a user
creates a portal pool, a permission record will be created that
assigns the creating user an "admin" role for the pool. This user
might later grant a lesser "instance management" role to another user
for this same pool -- in order to delegate permission to start/stop
instances, etc. In addition we might want to control access to images,
so we might want to grant users permission to use specific images for
instance creation.
What other actions need permissions defined on them? Some possibilities:
1) Provider creation: Should only certain users be allowed to
associate the portal with external cloud providers? What object would
these permissions be attached to?
2) Create new pool/cloud account for a provider: Is this allowed for
any user, or will a user need permissions granted for the provider
object to allow the user to add a new pool/cloud account.
3) Create new pool for existing cloud account: Other than providing
appropriate cloud account credentials, are there additional
permissions required if the cloud account is already used by
another user for a different pool (since one cloud account can be
used for multiple portal pools)?
4) High-level admin role: Able to grant permissions for 1), add new
user accounts, etc
In addition to using a polymporphic association for the "permission
object" rather than just a pool (to support permission grants on a
variety of resource types), we might need to make the field nullable
so that we can define "global" roles for permissions not attached to a
specific resource (who can create providers, who can grant top-level
permissions, etc)
As for the UI, we can use the ovirt permissions UI as the starting
point. For the associated object (pool, provider, etc) we add a
permissions tab with a table/grid of users showing assigned roles.
The global roles would need to be accessed as a separate tab somewhere
on the main UI.
Scott