On 8/1/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
> I took a quick look through this and I think it's looking pretty good.
> I like the idea of using the java security stuff as the base for the
> permissions, that sounds very clean and extensible.
Thanks for the careful review. I need all the help I can get on this one.
> I like how the checkPermission(perm, user) method is very generic and
> simple, that seems like a very nice design. So to take that design one
> step further, is there any reason why we really need to separate out the
> concept of roles vs. permissions any more? Is there any reason to keep
> those separate in the data model any more? i.e. what if we just had ...
>
> public void grantPermission(RollerPermission perm, User user);
>
> which would be a logic counterpart to the checkPermission(perm, user)
> method and would probably work similar to ...
>
> if(perm instanceof GlobalPermission) {
> // apply the user role
> } else if(perm instanceof WeblogPermission) {
> // grant weblog permission
> } else {
> // probably bad input
> }
>
> this would further simplify the methods you mention because we would no
> longer need any of the grant/revoke methods, and instead of having get
> methods for roles vs. permissions we would just have getPermissions()
> methods. would that work?
>
> i also like that you've redone the permission table, which seems to
> simplify things as well, but can we carry that on from my suggestion
> above and just store all permission data in that table, including roles
> and weblog permissions? would that work?
>
> this way if you add all of that up we are greatly reducing the security
> framework into these methods ...
>
> public boolean checkPermission(RollerPermission perm, User user);
> public void grantPermission(RollerPermission perm, User user);
> public void revokePermission(RollerPermission perm, User user);
> public List<RollerPermission> getPermissions(User user);
>
> is that feasible?
Possibly. I am somewhat reluctant to remove the notion of Roles
because I believe they give us a way to hook into and take advantage
of standard Java EE security. Here are some reasons to keep the notion
of Roles:
* Java EE supports roles and provides an API for creating them (JACC).
It is not very well supported yet, but it's coming soon to a container
near you. Standard permissions support may be a long time coming.
* App servers can/do provide infrastructure for:
- mapping external groups (e.g. LDAP groups) to roles
- automatically placing users into roles based on realms
* Roles are a way to imply specific permissions
Another reason I'm reluctant is that I need to externalize user
management so Roller can be easily integrated with other systems. Some
of those systems don't support permissions yet, but they do support
Roles. My user manager may have to take the common denominator
approach of dealing only with Roles and I'll need the flexibility to
use Roles to imply Permissions.
- Dave
