mRFC 0002: Access Control Mechanisms in Midgard
This document describes the future access control mechanisms
for Midgard. This has been deprecated by mRFC
0015: MidCOM Authentication and Access Control service.
Status
Midgard has a control system for defining who is allowed to
write to an object, but not who may read the object.
From the
manual:
Read Access
When authentication is required, read access to any record
within a Sitegroup is granted to all the users in that
Sitegroup. More comprehensive read-level access control has to
be implemented in PHP (which is easily achieved checking
against mgd_is_member($group)).
Write Access
Write access - which includes creation, modification and
deletion - is granted to any user who is either a member of the
owner Group the record belongs to, or a Member of a Group which
owns a parent of that record.
In other words, users get write privileges for any sub-tree
whose parent node owner is a Group they belong to.
Suggested changes
The main missing component of Midgard Access Control System
(MACS) is the ability to define an object as read only for a
group.
To solve this, there are two options:
- Add an extra reader field to all Midgard components
- Add an extra field to the repligard table.
Option nr 1 has the advantage of not having to add extra
complexity to the queries done against an object. The drawback
is that the change to the database tables will be larger.
The second option is simpler to implement wrt. databasechanges,
but will create more load on the database.
Approval and deapproval
There are two other changes that should be done at the same
time:
- Support for deleting documents in repligard (this is not covered in this RFC).
- Support for approvalstatus of all objects.
API changes
All objects
All objects should implement the following new interfaces:
isReadable()
isWritable()
setReadergroup($groupid)
setWritergroup($groupid)
Also the following will be needed wrt. to the approval section
above:
Approve()
unApprove()
Comment from Torben: This is
no major gain yet
While this would be undoubtly a step forward to the point we
are now, I would suggest keeping this thing suspended until
Midgard 2 (or at least MidCOM 2 with a complete abstraction
layer) becomes reality. Thing is, that modern need require much
more then that. Most complex applications bring severl
requirements.
First there are more then simple read and write permissions,
viewing change histories, creating elements, approving elements
are a few examples here.
In addition, those permissions nowadays should be assignable
both to persons and the objects they apply to, as depending on
the actual case, one thing or the other may be more useful.
Ah yes, I'm speaking about ACLs, not about the old Unix-like
User/Group System, which is good, but not that good. Besides,
you can always use ACLs in the old user/group manner, but you
cannot do this the other way around.
For a third point, Permissions can be inheritable, but they
must not. Ideally, you should be able to definie, wether a
permission counts for the whole tree of objects or only for a
specific one. (For the pourposes of clarity and simplicity, I
hereby define attachments and parameters as part of an object
itself, not of its tree.)
Often, too, it is required to introduce new permissions on a
(speaking in MidCOM Terms) component-level, depending on their
functionality.
Final summary: If we start overhauling this, lets do it right
and build a powerful permission system from the ground up.