I have a few questions about these changes:
1) Can someone explain the benefits of the security changes to the blog
user/administrator?
2) How do they affect the ACEGI implementation?
3) Will they help implement SSO using something like CAS
(http://www.ja-sig.org/products/cas/)
4) Will they tie Roller more tightly to any JEE APIs?
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
