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
