CDO/Security Manager

Introduction

Since mid 2012, CDO includes a default security model that allows to specify the access rights to the objects of repositories (see ticket 380629).

An alternative model exists: the annotation model. It is not covered by this tutorial.

This tutorial is the result of a short period of evaluation of this feature. It doesn't pretend to cover the topic exhaustively. Please feel free to complete it, to update it and to fix it.

The default CDO security model is implemented on the server side as an Ecore model, as shown below.

The root element of the security model is the realm, which contains the following elements:

• Roles, describing operational functions and their access rights.
• Users, describing the people accessing the repository. Users may have several roles and may belong to several groups.
• Groups, gathering peoples sharing the same needs in term of access. Groups may have several roles.
• Directories, gathering any number of these 4 elements.

Roles grants NONE, READ or WRITE access rights as follows:

• ResourcePermission: specify the access right for any resource with a path matching the given pattern.
• PackagePermission: specify the access right for all the EClass included in applicablePackage.
• ClassPermission: specify the access right for the EClass applicableClass.

Getting CDO

As of February 2013, the security management feature is available in CDO 4.1 and in the master branch that will become CDO 4.2 with the release of Kepler. This tutorial applies to this branch, that can be cloned with EGit from http://git.eclipse.org/gitroot/cdo/cdo.git. An alternative is to download Eclipse 4.3 milestones from http://download.eclipse.org/eclipse/downloads/ and then to install CDO Model Repository SDK, Net4j Signalling Platform Runtime and Net4j DB Framework H2 adapter.

Setting up the security manager on a new repository

If you are creating a new repository, things are quite simple. First create a cdo-server.xml configuration file. The important bit is the highlighted line in the example below:

<securityManager

Notes

• The Apache Derby adapter seems to be broken in CDO 4.x. Prefer using H2, which is now the default embedded database.
• Some CDO features, like workspace and CDO projects management, are not yet compatible with the security manager.
• When setting up access right, be aware that ClassPermission doesn't apply to its subtypes, but only the specified class. See ticket #399478.
• Be aware that you can apply any change to the security realm, even removing write access to the security realm to all the accounts: handle it with care. See ticket 399487.
• Default access rights of User shall be understood as Minimum rights. A user with READ default access right has at least READ access to all objects of the repository. See ticket 399486.
• WRITE access are checked at commit time. It means that if you are using the CDO UI, you can create and modify objects in the editor. Your commit will be entirely rejected when saving. See ticket 399485.
• Modifications in the security realm done with the CDO editor are not taken into account at commit time by the server. See ticket 399480.
• There is no mean at the time this tutorial has been written to change passwords through the CDO UI. See ticket 399306.