Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

CDO/Security Manager

Revision as of 00:17, 21 September 2013 by (Talk | contribs) (Getting CDO)


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

An alternative model exists: the annotation model. It is incompletely 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 when required.

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:

  • Directories, gathering any number of these 4 elements. They are not used during permission checking, but may be helpful to organize the Realm items.
  • Users, describing the people accessing the repository. Users may have several roles and may belong to several groups.
  • Groups, gathering people sharing the same needs in term of access. Groups may have several roles. Groups may inherit Roles from other Groups.
  • Roles, describing operational functions and their access rights. Roles contain a list of Permissions.

Permissions grant NONE, READ or WRITE (includes READ) access to sets of objects. Permissions form a bridge between the declarative part of the security model and the programmatic approach to determining sets of objects (implemented via the isApplicable() predicate method). The security model ships with the following Permission implementations:

  • FilterPermission: specify the access right for a set of objects declaratively with a tree of PermissionFilters (see below). If you specifiy multiple PermissionFilters they must all match (AND).
  • ResourcePermission: deprecated (see ResourceFilter), specify the access right for any resource or resource folder (including all contained objects) with a path matching the given pattern.
  • PackagePermission: deprecated (see PackageFilter), specify the access right for all the EClasses included in applicablePackage.
  • ClassPermission: deprecated (see ClassFilter), specify the access right for the EClass applicableClass.
  • ObjectPermission: deprecated (see ObjectFilter), specify the access right for any object based on your own implementation of the isApplicable() method. You need to generate your own EPackage.

PermissionFilters are used to declaratively specify sets of objects. The following PermissionFilters ship:

  • ResourceFilter: resources or resource folders with a path matching the given path and inclusion. The special token ${user} in the path attribute is substituted with the autheticated user ID at runtime.
  • PackageFilter: objects of any of the EClasses included in applicablePackage.
  • ClassFilter: objects of the EClass applicableClass. Whether subtypes are included can be specified.
  • (Abstract) ObjectFilter: objects for that your own implementation of the isApplicable() method returns true. You need to generate your own EPackage.
  • ExpressionFilter: objects for that the specified expression evaluates to true. Expressions come from the expressions model (or your custom extension to that).
  • LinkedFilter: objects that matched by a filter thats specified elsewhere.
  • NotFilter: objects that are not matched by the first contained filter.
  • AndFilter: objects that are matched by all contained filters.
  • OrFilter: objects that are matched by any contained filter.

Getting CDO

As of September 2013, the security management feature is available in CDO 4.2 and in the master branch that will become CDO 4.3 with the release of Eclipse Luna. This tutorial applies to the master branch, that can be cloned with EGit from (see CDO Source Installation). An alternative is to download Eclipse 4.4 milestones from and then to install CDO Model Repository SDK, Net4j Signalling Platform SDK and Net4j DB Framework H2 adapter from

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 line highlighted in the example below:


<securityManager type="<default|annotation>" realmPath="<path to the resource containing the security Realm>"/>

In our example a default implementation of the security manager will be used and the security realm will be stored in the resource /security. If the type was specified as "annotation" the security manager would additionally consider EAnnotations on all committed EPackages and EClasses. These annotations have the source URI "", the keys "read" and/or "write" and list the role names to be granted the specified access. Compare

Then configure and launch your CDOserver in the run/debug configuration window as shown below:

  • The application to be launched is


  • Configure the server to run a local and remote OSGi console (Program arguments: -console ; VM arguments: -Dorg.osgi.service.http.port=8080 -Dosgi.console.enable.builtin=true)
  • Precise the location of the cdo-server.xml folder with: -Dnet4j.config=<path to the cdo-server.xml folder>


When launching the server without the debugging options, the console should display:

osgi> Time to load bundles: 3
Starting application: 1194

[INFO] CDO server starting
[INFO] CDO server starting
[INFO] Net4j extension starting
[INFO] Net4j extension started
[INFO] Security extension starting
[INFO] Security realm /security created
[INFO] Security extension started
[INFO] CDO server started

Application Started: 2783

For stopping the repository, use the following commands in the OSGi remote or local console:

osgi> close

[INFO] CDO server stopping
[INFO] Net4j extension stopping
[INFO] Net4j extension stopped
[INFO] Security extension stopping
[INFO] Security extension stopped
[INFO] CDO server stopped

Enabling the security manager on an existing repository

Initializing the security manager on an existing repository is not more complicated. You only have to stop the CDO server, modify its configuration by adding the <securityManager [...]> directive, and restart it. The default security realm will be added with the Administrator account. Beware that after this restart, nobody, even the Administrator, has the right to add models or modify anything else than the security realm: it will be needed to add access rights to the Administrator, or to add new roles and users.

Logging into the repository

Start as usual a session in the CDO Sessions view by clicking on '+':


Once you have clicked on OK, a special login window appears:


The CDO server has automatically added an administration account when the security realm has been created. The user name is Administrator and the password is 0000.

You can then open a transaction and edit the security realm:


By default, the Administrator can read the resource of the repository, and modify the security realm.


  • The Apache Derby adapter seems to be broken in CDO 4.x. Prefer using H2, which is now the default embedded database of CDO.
  • 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 to the specified class. See bug 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 bug 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 bug 399486.
  • WRITE access are checked at commit time on the server side. 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 bug 399485.
  • Modifications in the security realm done with the CDO editor are not taken into account at commit time by the server. See bug 399480.
  • There is no mean at the time this tutorial has been written to change passwords through the CDO UI. See bug 399306. For now, new accounts can therefore be added only using the API. See
  • All related Bugs

Copyright © Eclipse Foundation, Inc. All Rights Reserved.