On 07/27/2011 05:30 AM, Mark McLoughlin wrote:
Hi Scott,
On Wed, 2011-07-27 at 01:42 -0400, 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.
Wow, this is great - seriously thorough
I'd like to see more focus on what makes this interesting for users.
Like I suggested to Matt, a script for a screencast demo of this stuff
really helps make sure we're focusing on the right things.
e.g.
- Andy Admin adds a new Joe Schmoe user and gives Joe "User"
permissions
- Joe logs in, can select an image from a list and launch it
- Joe sees his instance but nobody else's instances
- Joe doesn't see any of the admin UI, nor any UI for adding pools
etc.
- Joe logs into his instance
- Joe shuts down his instance
If we make that demo our first target, there's a lot of things we can
punt on for now:
- It's fine if Joe has launch access to all images; we just need to
make sure that Joe can't delete or overwrite images. Perhaps this
means that Joe has no direct access to IWHD or Image Factory at
all, only the images list in Conductor
So there's probably 2 phases here in terms of IWHD issues:
1) where we are now -- IWHD isn't yet performing permission checks
2) IWHD fully enforces permissions and provides a permissions API
So for 1) -- the deleting/overwriting images bit isn't a problem right
now, since aeolus-image only lets you build (or at least push) an image
if you have write access to the providers. I'm less clear on deletion,
but we could enforce similar restrictions there. As IWHD doesn't yet
support permissions, any user can launch any image in IWHD by adding it
to the deployable (or choosing it in the "single instance" UI that
creates the deployable on the fly)
Once 2) occurs, then we have 2 choices:
a) keep ignoring iwhd permissions in conductor and report errors when
users attempt to do things they're not allowed to do (i.e. wait for IWHD
to enforce) -- users will have to use IWHD apis to get/set permissions
b) integrate permissions into the IWHD ActiveResource models, and then
we get full control/view into IWHD permissions from conductor
- Andy doesn't need to make fine-grained changes to Joe's
permissions, he just assigned Joe a coarse-grained role
Remember that the permissions that we're already enforcing in 0.3.0 are
relatively fine-grained (user creates an instance and has permissions
for this instance -- other non-admin users can't see them, etc.)
Also note, that in all cases, permission records are tied to specific
objects/resources. i.e. there's no such thing as granting a role to
someone in the abstract -- a user has a role on an object (i.e. on a
resource, in a particular context). So a user might belong to an Admin
role on one pool (i.e. can see anyone's instances there), a User role in
another (i.e. can create instances there and manage those instances,
once created, but no access to anyone else's instances in the pool) and
no role at all in a third. For example, Hugh might be an admin on
"aeolus dev pool", a user in "qe pool" and no role at all in the
"web
production" pool.
We do support the other extreme (course-grained as in 'all or nothing'
permissions) by defining roles on the base permission object -- this is
what we do for the top-level admin -- we have an "Administrator" role
that defines all possible privileges and we assign this user to admin on
the "site-wide" permission object. End users might get more limited
site-wide roles ("image user" can launch any image, etc).
- We don't need to worry so much about hiding certain actions
on the
admin pages. Joe just never sees those pages
I think what you're saying is that we don't need to hide actions on the
page if the people from whome those should be hidden can't get there in
the first place.
Yes, the page-level access is first -- every action has a minimum
permission level required (either on the object being manipulated --
i.e. provider view for a provider will throw an error for users who
aren't allowed to see that provider) or a site-wide level required, if
the page isn't scoped to a particular resource.
The action-level hiding is for a page where there are things mixed on
the same page with a different required permission level -- i.e. the
'provider view' page will only allow users to see this if they have view
permission on the provider, but if they don't have modify permission,
they shouldn't see the edit link. Granted, in the current 'no permission
UI' state, we don't have any users with permission to see providers but
not edit them (since we only have "site wide admin" and "non-admin
users"). This will change once we have a permissions UI -- then it will
be more important to hide 'edit' links for users that aren't allowed to
edit. Also this is a lower-impact issue than the page-level checks --
what will happen if we forget this is a "view providers only" user will
click "edit provider" and be promptly greeted with an error page since
the edit forms _already_ have the proper checks in place.
- Hiding things Joe doesn't have permission to is more
important than
slick error messages if he does try and access other things
Agreed -- as long as the basic "throw exeption if user has no permission
on this page" is in place, making that exception look pretty can be a
lower priority. Also, much of the page-level checks are done anyway --
mostly we need to go through and make sure it's done consistently. One
area we don't have this as much is on the admin side, so we definitely
need to make sure that the require_privilege() call is included on each
action.
- Bulk operations can be omitted
Agreed (and already identified as 'maybe out of scope')
- Groups can be omitted
Agreed (and already identified as 'maybe out of scope')
By framing things this way, I'd be optimistic we could reduce
the
dependency on the IWHD work and focus the Conductor work on something
achievable for a release in 3 weeks, rather than 3 months
Sure -- that's why I had IWHD permissions near the end. In fact there's
no dep whatsoever on IWHD for the permissions UI (perhaps the biggest
task on this list)
I'm not sure how many 3 week sprints we'll have in iteration 4, but it's
certainly more than one 3 week sprint. We won't even begin the impl of
the permissions UI until the UI design is completed in an earlier sprint.
Obviously, everything else you describe does need to be done
eventually.
It'd just be nice if we could greatly reduce the scope of the first
iteration of this.
Cheers,
Mark.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel