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.
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 line highlighted in the example below:
<securityManager type="<default|annotation>" realmPath="<path to the resource containing the security Realm>"/>
In our example, the security realm will be stored in the resource /security and will use the default model.
Then configure and launch your CDOserver in the run/debug configuration window as shown below:
- The application to be launched is org.eclipse.emf.cdo.server.app
- 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:
Configuration location: file:/Development/workspaces/cdo/.metadata/.plugins/org.eclipse.pde.core/CDOServer/ Configuration file: file:/Development/workspaces/cdo/.metadata/.plugins/org.eclipse.pde.core/CDOServer/config.ini loaded Install location: file:/Development/eclipse-4.3M4/ Framework located: file:/Development/eclipse-4.3M4/plugins/org.eclipse.osgi_3.9.0.v20130128-202223.jar Framework classpath: file:/Development/eclipse-4.3M4/plugins/org.eclipse.osgi_3.9.0.v20130128-202223.jar Splash location: null Debug options: file:/Development/eclipse-4.3M4/Eclipse.app/Contents/MacOS/.options not found osgi> Time to load bundles: 3 Starting application: 1194 [INFO] CDO server starting !SESSION 2013-02-17 22:58:27.272 ----------------------------------------------- eclipse.buildId=unknown java.version=1.6.0_37 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=fr_FR Framework arguments: -application org.eclipse.emf.cdo.server.app Command-line arguments: -application org.eclipse.emf.cdo.server.app -data /Development/workspaces/cdo/../runtime-CDOServer -dev file:/Development/workspaces/cdo/.metadata/.plugins/org.eclipse.pde.core/CDOServer/dev.properties -os macosx -ws cocoa -arch x86_64 -consoleLog -console -debug !ENTRY org.eclipse.emf.cdo.server 1 0 2013-02-17 22:58:28.599 !MESSAGE CDO server starting [INFO] Net4j extension starting !ENTRY org.eclipse.emf.cdo.server.net4j 1 0 2013-02-17 22:58:29.532 !MESSAGE Net4j extension starting [INFO] Net4j extension started !ENTRY org.eclipse.emf.cdo.server.net4j 1 0 2013-02-17 22:58:29.584 !MESSAGE Net4j extension started [INFO] Security extension starting !ENTRY org.eclipse.emf.cdo.server.security 1 0 2013-02-17 22:58:29.588 !MESSAGE Security extension starting [INFO] Security extension started !ENTRY org.eclipse.emf.cdo.server.security 1 0 2013-02-17 22:58:30.054 !MESSAGE Security extension started [INFO] CDO server started !ENTRY org.eclipse.emf.cdo.server 1 0 2013-02-17 22:58:30.054 !MESSAGE CDO server started Application Started: 2783
Enabling the security manager on an exiting repository
Logging into the repository
Modifying the access rights
- 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 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.