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 > > > > -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
