I've been looking at Turbine security, and had some ideas I wanted to share.
The page at <http://jakarta.apache.org/turbine/howto/security-howto.html>
tells me I should write a bunch of if statements in my screens and actions
to allow or deny select, insert, update, and delete access to application data.
I think that it wouldn't be hard to make the data security more data-driven,
rather than application-driven. This would allow you to specify access
at design time, rather than coding time, and possibly automate the access
control generation (a la torque).
I've been tinkering to see how this could be implemented, and I've come up
with the following so far:
- Create a table called "TURBINE_ACCESS_CONTROL" with columns
GROUP, ROLE, RELATION, FIELD, and TEST (explained below).
- Add a "DataManager" interface, analogous to the "UserManager"
interface, with all its associated classes. (I figure this
should be pluggable in case you want to manage data access from
an LDAP server. Is that reasonable? I don't know much about LDAP.)
- Add methods to org.apache.turbine.util.security.AccessControlList to see
if a user has access to particular relations (tables) and fields (columns)
- Add grant/revoke methods to the SecurityService interface, and
all the associated classes (BaseSecurity, TurbineSecurity, DBSecurity, etc.)
- Create interfaces AccessControlledRelation and AccessControlledField
so the SecurityService can call back to the peers at run time to determine
access dynamically (e.g., if the logged-in user created the row in
question, then he can delete it). This would be used in case the
TEST column in TURBINE_ACCESS_CONTROL were non-null.
I've posted a diff at <http://dawnstar.org/diff.txt>. See also Field.java
and Relation.java in the same directory. The diffs almost certainly do
not compile, and half is still crap, but it may clarify some of what
I'm talking about.
I should also note that this scheme can peacefully coexist with the
current scheme. There's nothing to stop anyone from using permissions.
Let me know what you think, I'd appreciate any input.
cheers,
-- Travis Low
<mailto:[EMAIL PROTECTED]>
<http://dawnstar.org/travis>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
