Skip to main content
Jump to: navigation, search

Difference between revisions of "CDO/Security Manager"

< CDO
Line 1: Line 1:
 
__TOC__  
 
__TOC__  
  
==Introduction==
+
== Introduction ==
Since mid 2012, CDO includes a default security model that allows to specify the access rights to the objects of repositories (see ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=380629 380629]).
+
  
An alternative model exists: the annotation model. It is not covered by this tutorial.
+
Since mid 2012, CDO includes a default security model that allows to specify the access rights to the objects of repositories (see ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=380629 380629]).  
  
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.
+
An alternative model exists: the annotation model. It is not covered by this tutorial.  
  
The default CDO security model is implemented on the server side as an Ecore model, as shown below.
+
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.  
  
[[Image:SecurityModel.png]]
+
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:
+
[[Image:SecurityModel.png]]
* 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:
+
The root element of the security model is the realm, which contains the following elements:  
* 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==
+
*Roles, describing operational functions and their access rights.
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.
+
*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.
  
==Setting up the security manager on a new repository==
+
Roles grants NONE, READ or WRITE access rights as follows:  
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
+
*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.
  
[[Image:Cdo-server-xml.png]]
+
== Getting CDO ==
  
== Enabling the security manager on an exiting repository ==
+
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''.
  
== Logging into the repository ==
+
== Setting up the security manager on a new repository ==
  
== Modifying the access rights ==
+
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:
  
== Notes ==
+
[[Image:Cdo-server-xml.png]]
* 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.  
+
<pre>&lt;securityManager type="<default|annotation>" realmPath="<path to the resource containing the security Realm>"/&gt;
* When setting up access right, be aware that ClassPermission doesn't apply to its subtypes, but only the specified class. See ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399478 #399478].
+
</pre>
* 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399487 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399486 399486].
+
In our example, the security realm will be stored in the resource ''/security'' and will use the default model.
* 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399485 399485].
+
 
* Modifications in the security realm done with the CDO editor are not taken into account at commit time by the server. See ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399480 399480].
+
Then configure and launch your CDOserver in the run/debug configuration window as shown below:
* There is no mean at the time this tutorial has been written to change passwords through the CDO UI. See ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399306 399306].
+
* The application to be launched is org.eclipse.emf.cdo.server.app
 +
[[Image: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>
 +
[[Image:Cdo-server-run-configuration-args.png]]
 +
 
 +
== Enabling the security manager on an exiting repository  ==
 +
 
 +
TBC
 +
 
 +
== Logging into the repository  ==
 +
 
 +
== Modifying the access rights  ==
 +
 
 +
== 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399478 #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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399487 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399486 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399485 399485].  
 +
*Modifications in the security realm done with the CDO editor are not taken into account at commit time by the server. See ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399480 399480].  
 +
*There is no mean at the time this tutorial has been written to change passwords through the CDO UI. See ticket [https://bugs.eclipse.org/bugs/show_bug.cgi?id=399306 399306].

Revision as of 16:53, 17 February 2013

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.

SecurityModel.png

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

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

Enabling the security manager on an exiting repository

TBC

Logging into the repository

Modifying the access rights

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.

Back to the top