FWIW... Katello has a running version of this already using carls "tag"
model. Should be easy to either copy/paste or we could try and turn into
a gem.
-- bk
On 07/27/2011 01:42 AM, Scott Seago wrote:
Authorization:
The main purpose of authorization (permissions) is to control access
to resources based on defined permission records, once the
autherntication system has determined the identity of the current
user. The basic infrastructure and enforcement is already in
place. What we're doing here is to make sure we're enforcing
existing permissions consistently, providing a UI for admins to
manipulat permission grants, and expanding the scope of the
permissions system to deal with resources stored externally to the
main conductor database.
The basic components of permissions that we need are as
follows. Some initial indication of what we think is in scope for
this iteration is included, but this is only an initial estimate.
In scope for 0.4.0
1) Always check/filter/etc for permissions:
a) raise exceptions/show proper error pages on permission denied
(a good bit is done)
b) hide elements/links/actions based on permission (user shouldn't
be presented with any option that he's not allowed to perform)
c) filter lists properly based on permission (some is done already)
2) Permission setting UI
a) UI design for single object grants/deletes
b) Implementation for single object grants/deletes
c) UI design for bulk operations (maybe out of scope)
d) Implementation for bulk operations (maybe out of scope)
3) Permissions on IWHD objects
Maybe in scope for 0.4.0
4) Permissions on user groups
Probably not in scope for 0.4.0
5) Permission filtering of search results (if search is in scope,
this must be too)
6) Additional permissions for external objects
a) permissions on templates
b) permissions on assemblies/deployables
User stories and tasks:
1)
a) As a user, I should see an appropriate error page if I attempt to
access a resource to which I do not have the appropriate level
of access
1) Make sure permission checks are being applied to every page
2) Make sure error pages are being styled properly
b) As a user, I should not see action links for actions that I do
not have permission on (i.e. if I have 'view' permission on a
provider I shouldn't see an 'edit' link, if I have 'view'
permission on a deployment, I shouln't see a 'stop' action)
1) make sure links, actions, and any "privileged" content section
are included conditionally (by privilege level) in views
(already done in some cases)
c) As a user, I should not see entries in a list of resources that I do
not have access to view by other means (i.e. the pool 'instance
list' should only include instances that I have 'view'
permissions on, etc.)
1) Make sure we use 'list_for_user' where appropriate for any
list output.
2) We may need an association-specific list_for_user, or we could
re-style association queries to use existing list_for_user
(i.e. instead of pool.instances, we have
Instance.list_for_user(...) where the user and pool are
specified.
2)
a) As a Developer, I should be able to see the web UI design for
single-object permission operations
1) UI design for permissions tab:
* reusable across all permissioned-object types (pool,
instance, provider, etc)
* Shows table of existing permission grants:
- user
- role
- whether direct or indirect -- if indirect, which object
is the explicit grant on:
- a direct permission is a permission defined on this
resource -- i.e. the instance owner has the 'owner'
role on this instance
- for some object types, there's a defined hierarchy of
permission grant inheritence. For example, 'view
instance' permission defined on a pool lets a user
view all instances in that pool
- Any permission defined on BasePermissionObject is
considered a site-wide permision grant and will be
applicable to any object of the same type as that of
the BasePermissionObject role
* Actions allowed on the table of permissions
(delete/change role)
* "Grant additional access" action which will allow the
user/admin to choose a new user and a role on which to
grant permissions on this resource
b) As an admin, I should be able to use the Web UI to grant and
revoke access to a resource.
1) Design permission setting UI (single user/resource)
2) Implement views and controller actions for permission setting
UI (single user/resource)
3) Make sure API calls are sane here too (single user/resource)
4) Repeat 1)-3) for bulk operations
c) As a Developer, I should be able to see the web UI design for
bulk permission operations (no tasks broken out here)
d) As an admin, I should be able to use the Web UI to grant and
revoke access to multiple resources at once (no tasks broken
out here).
3) As a user, I should be able to see that permissions checking,
filtering, etc. is being applied to Images, Builds, and Provider
Images
1) Design interaction w/ IWHD api for permissions
2) Refactor PermissionedObject into a hierarchy:
PermissionedObject is the base class with anything common to
both AR and ActiveResource models
PermissionedActiveRecordObject includes AR-specific
components (from today's model)
PermissionedActiveResourceObject contains the parts needed to
deal with the IWHD models (at a general level)
3) Augment IWHD models to include
PermissionedActiveResourceObject and implement any required
methods
4) Refactor Permission model to work with ActiveResource models
5) Define appropriate privileges and roles for the new models
4) As an admin, I should be able to grant a user group access to a
pool (or other resource) without identifying individual users.
1) Implement UserGroup model (figure out any integration w/
external data source)
2) Work out caching group membership from external source (cache
on schedule, by trigger, or re-query a user's group
memberships before performing a permission query
for this user (or something else entirely). We need it cached
locally since the permission filtering queries wil need to
include group and membership in the join for filtering results.
3) Alter Permission model to use a polymorphic association
instead of User (Grantee which can be either a User or a
UserGroup, or something similar)
4) Alter permission checks, filters, etc. to take groups into
account
5) Alter permissions setting UI to allow group selection in
addition to user selection.
5) As a user, I should not see entries in search results that I do
not have access to view by other means (i.e. by clicking on the
appropriate pool/instance/etc pages)
1) Figure out appropriate place to insert permission filtering in
search results and implement it (more detail needed)
6)
a) As a user, I should be able to see that permissions checking,
filtering, etc. is being applied to Templates
1) determine how templates will be stored (assuming an
ActiveResource model pointing to katello-managed templates for
now)
2) Augment Template ActiveResource model to implement any
required PermissionedActiveResourceObject methods
3) Define appropriate privileges and roles for the template model
b) As a user, I should be able to see that permissions checking,
filtering, etc. is being applied to Assemblies and Deployables
1) determine how templates will be stored -- impl will be
dependent on this answer.
The main external prerequisites are as follows:
For IWHD permissions, IWHD must have in place a permissions system
and API that is, at least at a conceptual level, consistent with
our underlying permisions model.
For user group permissions, we need to have identified our plan for
external auth and how we're interacting with the underlying user
groups functionality.
Once we're considering dealing with permissions on objects stored
in katello, we'll need to deal with the same questions as above for
IWHD.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel