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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel