Skip to main content
Jump to: navigation, search

CDO/Security Manager

Revision as of 02:39, 21 September 2013 by (Talk | contribs)

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 When the installation is finished import the org.eclipse.emf.cdo.server.product plugin into your workspace (open the Plug-ins view, select the plugin, right-click, select "Import As", select "Source Project").

Starting the Repository

Now the org.eclipse.emf.cdo.server.product plugin exists as a project in your workspace (either because you've checked it out from Git or you've imported it from your target platform):


To enable the security manager open the cdo-server.xml file and uncomment the <securityManager> element. Here's a stripped down version:

<?xml version="1.0" encoding="UTF-8"?>

  <acceptor type="tcp" listenAddr="" port="2036"/>

  <repository name="repo1">
    <property name="overrideUUID" value=""/>
    <property name="supportingAudits" value="false"/>
    <property name="supportingBranches" value="false"/>

    <securityManager type="default" description="/security:annotation:home(/home)"/>

    <store type="db">
      <mappingStrategy type="horizontal">
        <property name="qualifiedNames" value="true"/>

      <dbAdapter name="h2"/>
      <dataSource class="org.h2.jdbcx.JdbcDataSource" URL="jdbc:h2:database/repo1"/>


The description attribute of the <securityManager> element has the following syntax (without extra whitespace):

  description := realmPath commitHandler*
  realmPath := a string literal that specifies the resource path in the repository where the security realm is placed.
  commitHandler := ":" commitHandlerType ["(" commitHandlerDescription ")"]
  commitHandlerType := a string literal that specifies the type of the IFactory that contributes the commit handler.
  commitHandlerDescription := a string literal that specifies the commit handler-specific configuration description.

For our example that means:

  • A default implementation of the security manager will be used and the security realm will be stored in the resource /security.
  • The "annotation" commit handler will 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
  • The "home" commit handler automatically detects new users and creates user-specific home folders under the specified "/home" folder. Only the respective user will have WRITE access to this folder. noone else will have READ access to it. Compare

Then run the CDOServer.launch that ships in the project. 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.

Understanding the Security Model

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.


  • 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

Back to the top