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
- Andy doesn't need to make fine-grained changes to Joe's
permissions, he just assigned Joe a coarse-grained role
- We don't need to worry so much about hiding certain actions on the
admin pages. Joe just never sees those pages
- Hiding things Joe doesn't have permission to is more important than
slick error messages if he does try and access other things
- Bulk operations can be omitted
- Groups can be omitted
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
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.