I've just glanced at this and may have further comments later.
1. I think that using Permissions is definitely the way to go.
2. I think the proposal is still mixing permission evaluation with
permission and user administration too much. If a 3rd party system
is managing users and permissions, it may well be completely
impossible to administrate from roller at all: you may have to use
the 3rd party tools. So, I would like to see the administration
aspects separated completely from authorization decisions.
3. In line with (2), in section 5.3 I think you need 2 interfaces:
SecurityService
boolean checkPermission(RollerPermission perm, User user);
SecurityManager
// A way for the Roller front-end to grant and revoke roles because
roles imply global permissions
void grantRole(String roleName, User user);
void revokeRole(String roleName, User user);
// The Roller front-end also needs to be able to grant and revoke
weblog permissions
void grantWeblogPermission(WeblogPermission perm, User user);
void revokeWeblogPermission(WeblogPermssion perm, User user);
// and to display the roles and permissions associated with each user:
List<String> getRoles(User user);
List<WeblogPermission> getWeblogPermssions(User user);
List<WeblogPermission> getWeblogPermssions(Weblog weblog);
4. I am a bit of a JACC fanatic, but I think the
SecurityService.checkPermission method should only have the user as a
parameter. The container roller is running in should be tracking the
user, not roller itself. This is how javaee and jacc work, I don't
know how compatible it is with acegi.
So, I see this as being more or less two applications that may not be
running on the same server:
web log editing, creation, viewing, etc etc. This could be a more or
less standard web app that doesn't need to know anything about the
user except their "preferences", but nothing security related: all
security info is hidden behind the checkPermission method.
user management where you can, well, manage users and their permissions.
--------------------------
relationship to javaee and jacc security
The blog specific roller permissions may not fit incredibly well into
a plain vanilla javaee security framework. javaee security is based
on the idea that an app has a fixed, known set of roles, and that
permissions are assigned to roles. Then some external magic maps
users to permissions.
So,
create blog b1
add user A.
How do you allow A access to b1, but prevent user B from accessing b1?
in the javaee model, there would have to be a role mapped to the b1
permissions, that we could assign to A but not B.
AFAICT you really need a more dynamic or direct user <> permission
mapping than is provided by plain javaee security. I don't know what
other systems offer but I'm working intermittently on one system that
does offer stuff like this, apache directory's triplesec project.
thanks
david jencks
On Jul 24, 2007, at 9:16 AM, Dave wrote:
I have withdrawn my two Roller 4.1 user/perms management proposals and
replaced them with one proposal that incorporates feedback from Elliot
and Allen:
" Proposal Externalize User And Permissions Management"
http://tinyurl.com/28br55
Major changes
- Removed User Repository API
- Removed User Permssions API
- Defined single consistent permssions system exposed via UserManager
- Added details on specific changes to be made to implement the system
Comments and suggestions for improvement are more than welcome.
Thanks,
- Dave
