David, Thanks for submitting this.I hope to have some time this week to take a closer look.
- Dave On Wed, Feb 20, 2008 at 11:14 AM, David Jencks <[EMAIL PROTECTED]> wrote: > > On Feb 20, 2008, at 12:38 AM, Sean Gilligan wrote: > > > I have a few questions about these changes: > > > > 1) Can someone explain the benefits of the security changes to the > > blog user/administrator? > > So far what I've proposed is, other than what I think are a lot of > bug fixes, refactoring, so users and administrators should see no > functional changes. > > > > 2) How do they affect the ACEGI implementation? > > As above, so far no changes. > > > > 3) Will they help implement SSO using something like CAS (http:// > > www.ja-sig.org/products/cas/) > > I am not familiar with CAS, but after a quick look at the docs it > appears to be an authentication service. This patch is only > concerned with authorization, so I don't see any overlap. > > > > 4) Will they tie Roller more tightly to any JEE APIs? > > So far, no changes. > > I'd like to investigate how to use JEE security and a RBAC system in > roller, but as I noted earlier that will require changes to the JEE > security model (e.g. "new user" functionality"). The refactoring I'm > proposing should make it possible to plug in alternate authorization > providers such as an RBAC/JACC system, but is not intended to affect > the default roller behavior. > > thanks > david jencks > > > > > > > > Thanks, > > > > Sean > > > > > > Matthias Schmidt wrote: > >> That's the ONE BIG features that was IMO missing in Roller. Thanks > >> a lot for your work!! > >> > >> > >>> ----- Ursprüngliche Nachricht ----- > >>> Von: David Jencks > >>> Gesendet: 19.02.08 09:42 Uhr > >>> An: [email protected] > >>> Betreff: Proposal for some refactoring around security > >>> > >>> i talked with Dave Johnson a bit about some of this at apachecon. > >>> > >>> Fundamentally I'm interested in Roller working with javaee > >>> security and a role-based access control framework. It's quite > >>> clear this will require some additional capabilities in javaee > >>> security, but I think Roller can be refactored to make this > >>> plausible, and that this refactoring will also make "stand-alone" > >>> roller security easier to understand and work with. > >>> > >>> I've been working on this for a week or so and have some results > >>> that I think are reasonable and working. I've opened ROLLER-1680 > >>> and attached a patch. Working on the security code it looked to > >>> me as if there were a lot of bugs: I've fixed the ones I've > >>> noticed but haven't tried to track them individually. > >>> > >>> I've had two main ideas here: > >>> - From the business layer, make all security decisions by > >>> checking if the current user has a particular permission > >>> - Abstract what is tracking the current user. > >>> > >>> This results in a SecurityService with a method > >>> boolean checkPermission(RollerPermission perm, UserSource > >>> userSource); > >>> > >>> UserSource is the abstraction of what is tracking the current > >>> user. Basically it attempts to avoid looking up the current User > >>> object unless it's really necessary. For instance with a JACC > >>> based authorization system the security service would already > >>> know the current user from the container login and would not need > >>> to consult the UserSource. > >>> > >>> I've also separated storage of security information such as which > >>> users have which permissions from the Permission implementation > >>> itself. The user administration code works with the data objects > >>> WeblogPermission and GlobalPermission which are no longer > >>> Permission objects, whereas the security code as we just saw > >>> works with RollerPermission, which is. > >>> > >>> I've combined several bits of functionality into RollerPermission > >>> which is now the only Permission class needed. Since I'm familiar > >>> with the code I borrowed the JACC 1.1 UserDataPermission class > >>> and simplified it by leaving out some functionality I'm pretty > >>> sure isn't needed. It still has some capabilities that may or may > >>> not be useful and can probably be simplified further. > >>> > >>> Here's a brief description of what it can do now and what might > >>> be simplified: > >>> > >>> - name. This is adapted from the URLPattern handling of > >>> UserDataPermission. We don't need exclusions so there's only one > >>> pattern, which acts like URL patterns in web security > >>> constraints. Currently global permissions get "/*" and > >>> permissions specific to a particular blog, say "foo", get "/foo". > >>> This could be simplified a little bit more, but what is there now > >>> allows hierarchical categorization of blogs. For instance one > >>> might organize blogs under /internal and /external: it would then > >>> be possible to give permissions to categories of blogs, say / > >>> internal/*. I thought it would be worth asking if this sounded > >>> interesting before removing the code that lets you do this. > >>> > >>> - actions. This is adapted from the HTTPMethod handling of > >>> UserDataPermission. This is probably significantly more > >>> complicated that necessary, but my questions as to what is needed > >>> have so far gone unanswered. The actions I've found in the > >>> existing code ("admin", "post", "editdraft", "weblog", "login") > >>> are represented in a bitmask. Any additional actions are stored > >>> as strings. There's an "isExcluded" flag that indicates whether > >>> the set of actions explicitly listed (in the mask or as strings) > >>> is the set of granted actions or the set of denied actions. Thus > >>> any finite set of actions or the complement of any finite set of > >>> actions can be represented. I strongly suspect that there is a > >>> known finite set of actions so a bitmap would be sufficient. I'm > >>> hoping someone can explain whether or not this is the case. > >>> > >>> Some of the actions are not independent. For instance, admin > >>> implies post and editdraft. Rather than requiring code to check > >>> these I've simply represented these in the masks for these > >>> permissions. > >>> > >>> Open questions: > >>> - as already mentioned, I'd like to know what actions are possible. > >>> - I don't really understand the thinking behind the ORM for > >>> ObjectPermission. It doesn't look to me as if GlobalPermissions > >>> can be persisted which I don't understand. In any case I suspect > >>> this area might be possible to simplify. > >>> > >>> Next steps > >>> With something like this patch in place I could start looking at > >>> running roller with javaee security and a role-based access > >>> control system. The obvious problem with javaee security is that > >>> currently it doesn't really support security changes while the > >>> app is running very well. For instance, adding a new users and > >>> permissions for that user is problematical, especially for > >>> content that isn't there until that new user generates it (their > >>> new blog, for instance). Beyond this, I think RBAC will provide > >>> some interesting capabilities that are currently lacking. The > >>> basic idea is to, starting with a directed acyclic graph of > >>> roles, assign permissions to roles rather than users, and assign > >>> users to roles. For instance you might have an author role > >>> specific to a particular department, "DevelopmentPoster". You > >>> could have a bunch of blogs with post permissions assigned to > >>> that role. Then any user assigned to that role could post to all > >>> of these blogs. > >>> > >>> Any comments are welcome. Aside from running (and adding to) the > >>> unit tests which I eventually discovered in the ant build despite > >>> their lack of documentation using -p, I've tested this with the > >>> geronimo roller plugin. I'm not a roller expert but everything > >>> I've tried seems to have the same behavior as with plain roller. > >>> > >>> thanks > >>> david jencks > >>> > >>> > >>> > >>> > >>> > >> > >> > > >
