Back to overview

Minutes of the Mmbase authorisation meeting, June 19 at EO.

Minutes of the Mmbase authorisation meeting, June 19 at EO, present: Daniel, Gerard, Mark, Rob, Cees, Antoine, John (Submarine, EO, VPRO, DDS).

Subject of the meeting is the definition of authorisation for Mmbase. Authorisation is the coupling of certain rights to a certain user who's identity has been authenticated. For instance access to selected parts of a database. It appears that only EO and DDS plan to use authorisation in the near future.

All agree on the following principles:

In line with the above we decide to use a security manager model such as used in Java. This boils down to checking, at a suitable place, all actions that access Mmbase objects. In this case we also want to check access to fields of objects. For Mmbase this necessitates the modification of only two lasses: MMObjectBuilder and MMObjectNode.

To facilitate a smooth transition to the new situation two Java interfaces will be defined. MMObjectBuilderInterface will define the public methods to access MMBase objects, such as create() and search(). MMObjectNodeInterface will define the public methods that access fields of objects. The current MMObjectBuilder and MMObjectNode will be implementations of these interfaces. This gives the possibility to make one's own versions, e.g. MyAuthorizedMMObjectBuilder which also implements object access methods such as create() and search(), but now an authorised version. This is illustrated in Figure 1. Developers now can implement their own authorisation by providing their own versions of MMObjectBuilder and MMObjectNode. (Note that all functionality is still defined in the existing lasses.)

Authorisation is done by calling a security manager first in each such method. If the user is accepted for this operation this call just returns, otherwise it throws a security exception. Thus all object access methods must be defined as throwing an exception. From this it follows that also the interfaces and thus also MMObjectBuilder (and MMObjectNode) should define these exceptions. E.g. the method Enumeration search(….) will become Enumeration search(….) throws SecurityException.

The question we could not answer yet was how exactly to model the context(s) of an object. Also we did not yet define a model for the situation where an Mmbase object can be part of more contexts and a user can have different rights in different contexts. It seems that this problem is not solvable in its general form but that solutions can be found for particular applications.
Everybody will think about this. DDS plans to build a prototype as soon as the core modifications are ready.

Next meeting: July 4th, 15.00 hour, again at the EO facilities.