Skip to main content
Jump to: navigation, search

Difference between revisions of "CDO/Security Manager"

< CDO
(Introduction)
(Introduction)
Line 15: Line 15:
 
The root element of the security model is the realm, which contains the following elements:  
 
The root element of the security model is the realm, which contains the following elements:  
  
*Roles, describing operational functions and their access rights.  
+
* 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.  
+
* 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.  
+
* Groups, gathering people sharing the same needs in term of access. Groups may have several roles. Groups may inherit Roles from other Groups.
*Directories, gathering any number of these 4 elements.
+
* Roles, describing operational functions and their access rights. Roles contain a list of Permissions.
  
Roles grant NONE, READ or WRITE (includes READ) access rights as follows:  
+
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:
  
* ResourcePermission: specify the access right for any resource or resource folder (including all contained objects) with a path matching the given pattern.  
+
* 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).
* PackagePermission: specify the access right for all the EClasses included in applicablePackage.  
+
* Deprecated (see ResourceFilter)! ResourcePermission: specify the access right for any resource or resource folder (including all contained objects) with a path matching the given pattern.  
* ClassPermission: specify the access right for the EClass applicableClass.
+
* Deprecated (see PackageFilter)! PackagePermission: specify the access right for all the EClasses included in applicablePackage.  
* ObjectPermission: specify the access right for any object based on your own implementation of the isApplicable() method. See [http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.security/src/org/eclipse/emf/cdo/security/impl/ObjectPermissionImpl.java ObjectPermissionImpl.java].
+
* Deprecated (see ClassFilter)! ClassPermission: specify the access right for the EClass applicableClass.
 +
* Deprecated (see ObjectFilter)! ObjectPermission: 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  ==
 
== Getting CDO  ==

Revision as of 23:45, 20 September 2013

Introduction

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.

SecurityModel.png

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).
  • Deprecated (see ResourceFilter)! ResourcePermission: specify the access right for any resource or resource folder (including all contained objects) with a path matching the given pattern.
  • Deprecated (see PackageFilter)! PackagePermission: specify the access right for all the EClasses included in applicablePackage.
  • Deprecated (see ClassFilter)! ClassPermission: specify the access right for the EClass applicableClass.
  • Deprecated (see ObjectFilter)! ObjectPermission: 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 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:

Cdo-server-xml.png

<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 "http://www.eclipse.org/CDO/Security", the keys "read" and/or "write" and list the role names to be granted the specified access. Compare AnnotationHandler.java.

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

Cdo-server-run-configuration.png

  • 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>

Cdo-server-run-configuration-args.png

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

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

osgi> cdo stop repo_1
Repository stopped

osgi> close

[INFO] CDO server stopping

!ENTRY org.eclipse.emf.cdo.server 1 0 2013-02-18 13:06:46.383
!MESSAGE CDO server stopping
[INFO] Net4j extension stopping

!ENTRY org.eclipse.emf.cdo.server.net4j 1 0 2013-02-18 13:06:46.383
!MESSAGE Net4j extension stopping
[INFO] Net4j extension stopped

!ENTRY org.eclipse.emf.cdo.server.net4j 1 0 2013-02-18 13:06:46.386
!MESSAGE Net4j extension stopped
[INFO] Security extension stopping

!ENTRY org.eclipse.emf.cdo.server.security 1 0 2013-02-18 13:06:46.386
!MESSAGE Security extension stopping
[INFO] Security extension stopped

!ENTRY org.eclipse.emf.cdo.server.security 1 0 2013-02-18 13:06:46.387
!MESSAGE Security extension stopped
[INFO] CDO server stopped

!ENTRY org.eclipse.emf.cdo.server 1 0 2013-02-18 13:06:46.387
!MESSAGE 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 '+':

CDO-session.png

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

CDO-login.png

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:

CDO-security-realm.png

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

Notes

  • 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 ISecurityManager.java.
  • All related Bugs

Back to the top