Cloud Context Security

Author: Michiel Meeuwissen
Date: 2003-09-12

This software is OSI Certified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative.

The license (Mozilla version 1.0) can be read at the MMBase site. See http://www.mmbase.org/license

Table of Contents

1. Introduction

2. Object model

2.1. Contexts
2.2. Groups
2.3. Users
2.4. Ranks
2.5. Naming

3. Security editors

4. 'Extra' administration accounts

5. Other configuration

6. Conversion from `XML' context security

1. Introduction

MMBase has a pluggable security system. This means the object level security can be implemented on several ways. This document describes the 'cloud context' implementation for MMBase security.

The default security implementation for several MMBase releases was the normal 'context' security. This security implementation defines users, groups and so-called 'security contexts' in an XML. See also the documentation for 'context security configuration'.

Often it is desirable to have a more dynamic security implementation which is more readily configurable than by opening an XML file on the server in your text editor. It would be nice if the concepts and relations described in this XML file could be modeled using MMBase objects and relation. Then security could be administrated in the same way MMBase nodes can be edited.

2. Object model

Because of the nature of this security implementation, the object model of your MMBase installation must be enriched with several new object types and relations types. This section describes the object model needed for this security implementation.

Figure 1. The Cloud Context Security Object Model

3. Security editors

If you know the object model sufficiently well, security can now be administrated by using 'generic' editors. Cloud context security is however shipped with specialized editors.

Figure 2. The Cloud Context Security Editors embedded in another editor

Figure 3. The group editor

These editors are implemented as 'pieces of html', which makes it possible to include the entire editors into other editors (I use this to integrate them in the editors for a certain site), and you can configure extra links for users (e.g. make a link to a 'people' editwizard to relate people objects to accounts). There is an index.jsp available to use them stand-alone.

When defining a new 'context' object with the security editors, it might be convenient to allow read rights on it to most or all users. To facilitate this, this editors looks for a group with alias 'mayreadallgroup' when creating a context object, and if it exists the read operation is automaticly link to it immediately.

Often you would want to associate a context with every 'group' of users, so on the creation of one of those, you get the option to create to other one in one go.

It is suggested that these security editors are installed in /mmbase/security (as the `install' target of the cloud context security application would do).

4. 'Extra' administration accounts

Normally the cloud context security should be configured completely in itself. But it is e.g. possible to forget the admin password or so, and then you could not do certain things any more. You could fix it by temporary disabling security in security.xml and then reset the admin password.

This would however temporary let anybody in your web site, and it would be very vulnerable, in that time. When you switch it on then again, then all user have to login again, which is also a (however small) disadvantage. Therefore we have provided an extra feature, which we could refer to as 'extra administrators', which works by use of a property file 'admins.properties' in <config dir>/security/admins.properties. This property file contains name/password combinations of 'extra' administrators. The file is dynamically loaded and checked (you can change it, place it, remove it), so you can add and remove such administrators on a running MMBase (without affecting 'normal' users). So as long as you have access to the file system, you can in this way always administrate you site running Cloud Context Security, in a reasonably secure way.

5. Other configuration

Some other things can be configured in cloud context security. These setting are available as 'properties' in the builder xml of mmbase-contexts.

readall

If you don't care for read protection, you can considerably simplify configuration by setting this property to 'true'. Every object may always be read by every user. This should also have a positive effect on the performance impact of security.

allcontextspossible

Setting this to false, would make it possible to implement a simple kind of work flow using security, because then you must explicitly indicate which context may be changed to which other contexts explicitly. Unpublished nodes can then be owned by a security context which does not allow reading by everybody. You can arrange then that the context can only be changed in one direction (to publish). The security editors do currently not support this (no way to link to next context)

If this property is true (the default), then you may change any object (on which you have the 'change context' right, to any other context (which you can see).

maxcontextsinquery

When checking read rights, in the query things like 'WHERE owner in (<list of contexts>)' can appear. This property is an indication for how much the query may (expressed in the number of times one contexts is added to the query) grow. If the query would have to be more complex this is not done, but the result would need checking. This means also that the result of a 'count' on a query might not be exactly right any more, because it might have counted some objects which you are not allowed to actually read.

Warnings will be issued in the log when this number is too small (a postprocessing of query-results is needed), which you can solve in several ways. Firstly you can increase this property. You can also simply the used query (perhaps it has an extraordinary lot of steps), and lastly you could also make sure that there is for any user only a limited number of contexts which he can see or a limited number of contexts which he can not see (the query must contain for every step either contain a list of all 'invisible' contexts or all 'visible' contexts).

This property defaults to 50.

6. Conversion from `XML' context security

A conversion tool which read the XML file from the old style context security is available.

This tool reads all users, groups and contexts from this file and matches them with the existing users, groups and contexts (by username, name and name). All non existing ones are created. After that also the `group structure' (which groups and users are contains by which groups) is copied (That might result in 'double' links, but that does not matter). And finally also the rights relations are created which are defined in the XML.

The tool is available in the 'admin' directory of the security editors (there is no link, you need to make up the URL yourself, it might probably be /mmbase/security/admin, depending on where you put the editors).

The inverse operation; writing back the security configuration to an XML which can be read by the `XML' context security implementation is not yet available (and it is a bit tricky because the passwords are plain text in the XML, but are md5 encrypted in the cloud).