I spent a few more minutes clarifying the behavioral rules for
permissions based on what I had in mind. These rules apply to the
construction and comparison (via the implies() method) of 2
WebloggerPermission objects ...
* we only support comparing 2 permissions of type WebloggerPermission,
and WebloggerPermission cannot be subclassed
* a permission with type = null indicates a global (application wide)
permission
* permissions that are global (type = null) cannot specify an object
(global perms do not pertain to objects)
* permissions of a specific type must also specify an object (typed
perms must correspond to an object)
* permissions must be of the same type to be compared (we do not compare
global and 'weblog' permissions)
* permissions of a specific type must also specify the same object to be
compared ('weblog' perms for different weblogs are never comparable)
* a permission action can only imply other permissions of the same type
('weblog' perms can only imply other 'weblog' perms)
* the '*all*' action is a special action that implies all possible
actions within the specified permission type/object combo
* a global permission with the '*all*' action implies all permissions in
the system (the global admin role)
* a permission can imply any number of other permissions
I debated some of these in my mind for a bit but settled on these rules
with the feeling that they are a reasonable balance between strictness
and flexibility. Comments and questions welcome.
I also updated the WebloggerPermission code on the wiki page with my
latest version which fixes a couple things in the implies() method and
enforces the rules above ...
http://cwiki.apache.org/confluence/display/ROLLER/More+Abstract+Security+Model
-- Allen
Allen Gilliland wrote:
Dave wrote:
On Mon, May 26, 2008 at 3:19 PM, Allen Gilliland
<[EMAIL PROTECTED]> wrote:
For completeness' sake I've spent a few hours messing around with my
ideas
and prototyping to see if they make sense. Here's the results ...
http://cwiki.apache.org/confluence/display/ROLLER/More+Abstract+Security+Model
I've also created a patch against the current trunk with actually
applies
these things and the changes are all additions to the code for the most
part, so they work side-by-side with the existing implementation if
you want
to apply the patch and compare.
I took a look at this patch today and I think it looks good. Overall
it's cleaner and easier to understand. Also, looks like the UI /
Struts 2 changes will be pretty small to cut over to the new
objects/methods you have proposed. So I'm +1 on the patch and willing
ot help with those Struts 2 changes.
Cool. Anyone else who is interested in the security model want to weigh
in?
One of the things the patch didn't include was the mappings of implied
permissions. We could use a little more thought in that area. We need
both a way of persisting the implied permission relationships as well as
a way to query for them. I had thought this might also be something
that would be done through the UserManager since it's tied to
permissions, but don't have strong feelings about it.
I am hoping that we can actually persist the implied permission mappings
in the db and make them dynamic, thus allowing us to add/modify/remove
permissions at runtime. This isn't a requirement right now though, so
just putting them in the static config is fine for now.
The other thing I am interested in now is David Jencks idea of having a
separate UserSource interface. Originally this seemed excessive to me,
but after doing the comment authentication work I realize that this
could be very useful if not necessary. The main need for this comes
from the need to be able to get the information about a User from more
than just a single data store. i.e. in comment authentication we want
commenters to authenticate against a 3rd party system, not the local db,
which creates the problem of "where do I get the User object from if
UserManager.getUser() only looks against the local db?"
That is also just more food for thought and is not a true necessity
right now, but I am thinking it makes a lot of sense.
I'm going to try and work on this a bit more this weekend.
-- Allen
Thanks!
- Dave
