Thanks for the feedback.
On 7/24/07, David Jencks <[EMAIL PROTECTED]> wrote:
I've just glanced at this and may have further comments later. 1. I think that using Permissions is definitely the way to go.
Good. Glad you agree.
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);
Regarding SecurityService and SecurityManager, I'd rather not complicate things by adding additional interfaces beyond UserManager. My current thinking is that If you hook Roller up to an external user/perm management system and that system does not support writes of user/perm information, then you should: 1) disable/hide the parts of the Roller UI that support user/perm/role editing 2) impl. the write methods in UserManager to throw UnsupportedOperation exceptions
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.
You meant to say "only have the permission as the parameter", no? The Roller backend must be able to run outside of a container, so I'm against that change. And BTW, I'm definitely not a JACC fanatic, it it frighteningly complex and it is not supported on most containers. And it can't really handle dynamic permissions. I hope something better will come along.
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.
Right. I don't think Java EE or even JACC can help much here.
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.
Yes. I am convinced that we cannot use plain Java EE security to manage user-weblog permissions and I've had lengthly conversations with Sun's Java EE security architect to back that up. - Dave
