Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDO/Security Manager"

< CDO
Line 1: Line 1:
 
__TOC__  
 
__TOC__  
 +
 +
==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]).
 +
 +
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.
 +
 +
[[Image: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.
 +
 +
 +
Available options
 +
 +
==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 the master branch.
  
 
== Setting up the security manager on a new repository ==
 
== Setting up the security manager on a new repository ==

Revision as of 16:59, 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).

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.


Available options

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 the master branch.

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

<securityManager

Cdo-server-xml.png

Enabling the security manager on an exiting repository

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