The MMBase Security Framework

MMBase uses a security framework in which different security implementations can be used. This means that it is possible to developer various types of security systems, adapting MMBase to the needs of the environment in which it runs. A number of default implementations are available in MMBase (such as the context security, documented elsewhere), but new ones can be developed and easily substituted using the security configuration files.

This document focuses on the security framework. It falls in four parts.

The first part explains the general architecture, and the way security is used by MMBase. It explains what is possible in the approach we use and what isn't. It also comments on where security is used, and how it can be circumvented.

The second part explains how to configure the security framework, such as when you want to install an alternate security system.

The third part explains how to transparently use the security in scripts (the MMCI) or with the MMBase taglib.

The final part is a few handouts on how to build your own security system.

As the MMBase architecture image shows, the MMBase security framework forms a layer between the MMBase core and the MMCI - the MMBase Cloud Interface which is used for external programs and applications to communicate with the system.

All communication through the MMCI uses the security layer, while the 'core classes' of the system generally don't. This allows the core to handle requests quickly, while maintaining security where it matters - in communication with external sources.

When a user connects to MMBase using an external application (such as the taglibs, a jsp servlet, or the editwizards), that application creates a session to maintain the state of the user. In other words: maintaining state is left to the external application. Security itself does not offer this functionality as it is dependent on the means of communication.

The application then authenticates the user through a call to the bridge, passing authentication parameters appropriate to the authentication module in use. Various authentication modules may exist - each offering a different way of authentication, and possibly a different measure of reliability or accountability.

Once authenticated, the security passes a User object back, which contains the information required by the Authorization module. The bridge encapsulates the user object in the Cloud object, which is passed to the calling application. The application should then take care of storing the cloud in a session.

The user object is passed to the security system every time the bridge performs a security-sensitive operation. This is done automatically - a calling application need not perform any additional actions. Operations are defined on the MMBase node-level. Any operation on a Node is security-sensitive: each time a node is read, created, written, deleted, or related to, the bridge checks whether the operation is allowed. Depending on context, the bridge then either causes an error or ignores the operation (for instance, when retrieving a list of nodes, the bridge will only return nodes the user may read, ignoring any nodes the user has no access to).

Whether rights are really defined on node level is dependent on the system. Complex security systems may actually specify rights for individual users on individual nodes. Other systems may use a more general approach, i.e. allow all actions to logged on users of a certain rank, while allowing only read access to others.

There are various ways to authenticate a user. Name/password login is one of the most common, but other authentication methods might include certification, IP-filtering, or public keys. Another form of authentication is 'anonymous' access - which allows people to be identified as anonymous users. Advanced systems might use fingerprints or iris scans.

The security framework takes this into account by introducing the concept of authentication modules. Each module in a security implementation offers another way to authenticate a user.

There is currently no specific way to configure modules - the Authentication class deals with this, either by hardcoding the expected modules, or by using a configuration file specified with the url attribute (such as in the context security system). Future versions of the security framework may include specifics on how to configure authentication modules.

Authorization takes place on object level: for each object, the authorization system determines the rights for a specified user. How these rights are determined is not specified - a system can actually maintain (and store) rights per user/object, but it is also possible to determine access per object type, or (as is the case with the context security system), by granting user groups access to object groups (generally objects with the same 'context' or 'owner').

Forthcoming...

Forthcoming...

The security framework makes it possible to use different implementations for security within MMBase. The implementation is specified in the security configuration file. This file is called security.xml and can be found in the security subdirectory in the MMBase configuration directory.

The content of the configuration file should be similar to the following:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE security PUBLIC "//MMBase - security//" "http://www.mmbase.org/dtd/security.dtd">
<security active="true">
  <authentication
    class="org.mmbase.security.implementation.context.ContextAuthentication"
    url="context/config.xml" />
  <authorization
    class="org.mmbase.security.implementation.context.ContextAuthorization"
    url="context/config.xml" />
  <sharedsecret>my_secret_access_code</sharedsecret>
</security>
      

Within this document you can alter the following:

The first worry is that you have to authenticate yourself. You can do this when you obtain the cloud object from the 'CloudContext' object..

You will have to specify a 'cloud name' which is alway 'mmbase' in current mmbase implementations. Then you need to give a second string 'authentication type' which corresponds to the authentication modules. And the last and most important argument is a map of credentials. The credentials which need to be given are dependent on the chosen implementation and module of it.

The MMBase taglib entrance to this method is the mm:cloud tag. The 'autentication type' or 'module' string is present here as the 'authentication' attribute. The other attribute of importance is the 'method' attribute, which tells the cloud tag something about how the map of credentials must be filled. Most 'methods' produce name/password combinations. The important exceptions are method="anonymous", which produces a cloud without using credentials (the 'anonymous' cloud), and you will normally have very limited rights, and method="delegate" which make the tag put the request and response objects in the credential map, which then can be used for further acquisition of credentials (like redirecting to an external authentication server).

A new 'authentication module' in MMBase 1.8 (and available for 1.7 as a 'wrapper'), is the 'class' module , which is supported by most authentication implementations. Using this method of authentication you don't need to supply any credentials, because you are authenticated using the java strack-trace. The cloud which you obtain is then determined by an extra configuration file <config dir>classsecurity.xml, which connects classes to users.

        <authentication class="org.mmbase.security.classsecurity.ClassAuthenticationWrapper" url="wrapper.xml" />
        

When using the bridge, you don't have to do much...