Administrator Manual

In this document you will discover how to manage a Server supporting Collaborative Modeling features.

Once the server is started and correctly configured, please refer to the Collaborative Modeling – User Manual to discover how to collaborate in real-time through Shared Modeling Projects.

  1. Administrator Manual
    1. Starting a Collaborative Server
      1. Using the Obeo Designer Team Server
      2. Using default Server configurations
      3. From command line
      4. Configure LDAP authentication on the Server
      5. Configure LDAP with Active Directory
      6. Configure LDAP with a manager
      7. Activate SSL connection
      8. Customize the server configuration
      9. Implement your own CDO Server
    2. Configure Permissions on the Server
      1. Activate Permissions on Server
      2. Create a Shared User Profiles Project
      3. Add Users
      4. Associate Users to Roles
      5. Define new Roles & Permissions
      6. User profile configuration examples
      7. Deploy metamodels used in permissions on Server
      8. Import/Export the User Profiles
      9. User profile example
    3. Administrator commands
      1. Resource rename
      2. Resource deletion
    4. Importer Application
      1. Importer strategies
      2. Importer parameters
      3. Launching the importer
      4. How to set the Importer credentials in secure storage
    5. Annex: Managing certificate
      1. Generate a keystore
      2. Sign your certificate from a certificate authority(optional)
      3. Export certificate from a keystore
      4. Create a truststore from a certificate

Starting a Collaborative Server

The starting point of Collaboration is the setting-up of a Collaborative server.

Using the Obeo Designer Team Server

The Obeo Designer Team Server is a ready-to-use Collaborative server, optimized for Sirius Collaborative features and customizable according to your specific needs.

We strongly advice you to read the Obeo Designer Team Server User Guide to get started, although the other methods described below are valid alternatives.

Using default Server configurations

See this Step in Video

Obeo Designer Team Edition provides four default launch configurations allowing to set-up four default servers. To load these default configurations, import the Collaborative Server examples by selecting File > New > Example... > Obeo Designer > Collaborative Server examples

After having imported the example project, you should be able to launch three different servers (from Run > Run Configurations... > Eclipse Application). The following table presents the differences between each default Server configuration:

Server configuration name Collaborative server – Default Collaborative server – Authenticated Collaborative server – User profile Collaborative server – Memory
Basic Server description Informations are stored in an H2 database. Forbids access to non-authenticated users.
Informations are stored in an H2 database.
Forbids access to non-authenticated users, and support user-specific permissions.
Informations are stored in an H2 database.
Informations are stored in memory (no data persistence).
Persists all informations inside a database
When stopped and relaunched, retrieve the previous elements state
Allows anonymous log-in
Supports authentication
Supports user-specific permissions
Supports branching
Supports auditing
Set-up instructions Launch the Collaborative Server [default] configuration Install the additional server features
✓ Launch the Collaborative Server [authenticated] configuration
More about the configuration
Install the additional server features
✓ Launch the Collaborative Server [user profile] configuration
More about the configuration
Launch the Collaborative Server [memory] configuration
How can I check that my server is started ? ✓ For performance considerations, server logging is deactivated. Open the debug view ( Window > Show View > Other ... > Debug)
✓ Check that the Collaborative Server process is active
Tear-down instructions ✓ Open the debug view ( Window > Show View > Other ... > Debug)
✓ Select the Collaborative Server process
✓ Right-click and select Terminate

Install additional server features

This step is only required when launching the server samples from Obeo Designer Team Edition. On Obeo Designer Team Server everything is already installed and this step can be ignored.

To be able to launch a server with authentication or user profiles server, a couple of features that are not pre-installed in the Obeo Designer Team Edition are required. To install these additional features, follow the following steps:

Authenticated server configuration

To activate the authenticated server you have to set the line below in the cdo-server.xml file before the <store > tag.
<userManager type="collab_file" description="usermanager.properties"/>

usermanager.properties is a path to the authenticated server configuration file. The path can be absolute or relative to the cdo-server.xml file.

users.file.path=users.properties
# ldap configuration
auth.type=ldap
auth.ldap.url=ldap://127.0.0.1:10389
auth.ldap.dn.pattern=cn={user},ou=people,o=sevenSeas
auth.ldap.filter=
auth.ldap.tls.enabled=false
auth.ldap.truststore.path=
auth.ldap.truststore.passphrase=

users.file.path is the name of the file containing the users. This file has to be copied into the root server installation folder. You can add new users by modifying the users.properties file.
auth.xxx corresponds to the authentication configuration. The properties are prefixed by auth.

The file users.properties contains entries which keys are the logins and values are the passwords. Note that space must be escaped with \ else it will be considered as a key-value separator.
Examples:

admin=admin
			
John\ Doe=secret

User profile configuration

To activate the user profile server you have to set the line below in the cdo-server.xml file before the <store > tag.
<securityManager type="collab" realmPath="userprofile-config.properties" />

userprofile-config.properties is a path to the user profile configuration file. The path can be absolute or relative to the cdo-server.xml file.

realm.users.path=users.userprofile
administrators.file.path=administrator.properties
# ldap configuration
auth.type=ldap
auth.ldap.url=ldap://127.0.0.1:10389
auth.ldap.dn.pattern=cn={user},ou=people,o=sevenSeas
auth.ldap.filter=
auth.ldap.tls.enabled=false
auth.ldap.truststore.path=
auth.ldap.truststore.passphrase=

realm.users.path is the name of the resource that contains the user profile model.
administrators.file.path is a path to the administrators file. The path can be absolute or relative to the cdo-server.xml file. This file is used to initialize administrators in the user profile model. It is mandatory for a production server because the definition of the user profile (users and their permissions) can only be done by an administrator. For testing purpose, if there is no administrators file or if it is empty, a default administrator will be created with Administrator / 0000 as credentials.
auth.xxx corresponds to the authentication configuration. The properties are prefixed by auth.

Default user profile configuration

When the server is configured with the User Profiles functionality, the following roles are automatically created:

These defaults roles are required :

Note that as user created as administrators (in the administrator properties file as presented in the previous part) have full access and do not need to be assigned to any role. Trying to assign roles to administrators will be prevented and a dialog will appear explaining that the administrators already have full access.

From command line

java -Dnet4j.config="$PATH_TO_SERVER_CONFIG_FOLDER" -jar $PATH_TO_EQUINOX_LAUNCHER -application org.eclipse.emf.cdo.server.app

Configure LDAP authentication on the Server

Activate LDAP authenticator

You can activate LDAP authentication in three different ways:

These ways are excluding themselves.

To activate LDAP authentication, as exclusive authenticator, the following authenticator tag must be added to the repository configuration in cdo-server.xml.

<repository name="...">
	...
	<authenticator type="ldap" description="<ldap properties file>"/>
	...
</repository>

The description attribute is a path to a properties file containing the LDAP authenticator configuration. This path may be relative to the CDO server configuration file or absolute.

Configure LDAP authenticator

The LDAP authenticator’s configuration file is a properties file which should contain the following keys :

When the LDAP authenticator is used in User Profile or Authenticated configurations, those properties property keys must be prefixed by the auth. and the auth.type=ldap is needed to activate the LDAP authentification.

Important !

If the LDAP certificate has been signed by an official Certificate Authority it is not required to set the trust store path as the JVM already trusts the CA.

If you need to generate a self-signed certificate or need to create a trust store from an existing certificate please refer to the following section.

Configure LDAP with Active Directory

An LDAP using Active Directory provides a field sAMAccountName that is usually used as a key (like the «cn» field). Users can be identified using this field associated with a domain name after an «@» as separator. This leads to this pattern: sAMAccountName@DomainName. As the user identifies himself by providing only his identifier, not the domain name, the corresponding pattern is: {user}@DomainName.
For instance, if the domain name is «MyCompanyDomain» then the LDAP pattern will be: auth.ldap.dn.pattern={user}@MyCompanyDomain

Use a self-signed or non CA-authentified certificate

In case the certificate is self-signed or the CA used in your certificate is not managed by the jvm, you will need to generate a truststore and reference this truststore from the configuration file.

Follow the Export and TrustStore creation steps to create the trust store.

Configure LDAP with a manager

Some LDAP does not support anonymous binding (if your LDAP server doesn’t even allow a query without authentication), then Sirius would have to first authenticate itself against the LDAP server, and Sirius does that by sending «manager» DN and password. Using this specific connection, the user credentials can be looked for in the LDAP tree.

This manager credentials needs to be provided in the properties file as it will not be asked to the user. These credentials are provided with the following properties:

The search for the user himself in the LDAP is provided with the following properties:

Example of LDAP configuration with a manager

# ldap configuration
ldap.url=ldap://ldap.myCompany.com:389
ldap.user.search.base=dc=myCompany,dc=com
ldap.user.search.filter=(&(objectClass=account)(cn={user}))

# The manager credentials are useful for LDAP requiring authentication to run search filters
ldap.manager.dn=uid=manager,ou=People,dc=myCompany,dc=com
ldap.manager.password=DerfOcDoocs6

ldap.tls.enabled=false

Example of LDAP configuration with a manager and Active Directory

# ldap configuration
ldap.url=ldap://ldap.myCompany.com:389
ldap.user.search.base=dc=myCompany,dc=com
ldap.user.search.filter=(&(objectClass=organizationalPerson)(name={user}))

# The manager credentials are useful for LDAP requiring authentication to run search filters
ldap.manager.dn=manager@myCompany.com
ldap.manager.password=managerPassword

ldap.tls.enabled=false

Activate SSL connection

It is possible to activate a SSL connection between the client and the CDO server.
Both client and server have to be configured accordingly.
On server side a keystore has to be set up and, on client side, a trust store containing the key store public key has to be set up. See chapter Managing certificate to generate keystore and truststore.

Client configuration:

Add the following lines in the client ini file:

-Dorg.eclipse.net4j.tcp.ssl.passphrase=secret
-Dorg.eclipse.net4j.tcp.ssl.trust=file:///<trusted.ks absolute path>

Server configuration:

In the cdo-server.xml configuration file the acceptor has to be configured to accept SSL connections
<acceptor type="ssl" listenAddr="0.0.0.0" port="2036">
Set the acceptor type to ssl.

Add the following lines in the server ini file:

-Dorg.eclipse.net4j.tcp.ssl.passphrase=secret
-Dorg.eclipse.net4j.tcp.ssl.key=file:///<server.ks absolute path>

Customize the server configuration

You can customize any feature of the default server configurations. This section will only give some examples of customization, please refer to CDO documentation to get a complete documentation of server configuration files.

Let’s take the following example : you want to modify the Collaborative server - Authenticated configuration to make it support branching.

Open the serverconfig_authenticated/cdo-server.xml file and change the <property name="supportingBranches"> value to value="true". By editing this configuration file, you can modify the server behavior like the storage of informations inside the server ( MappingStrategy). The changes in configuration files will be applied during the next server start up.

Implement your own CDO Server

CDO provides API to implement your own CDO Server. Pleaser refer to CDO documentation to get additional informations about Server implementation.

Configure Permissions on the Server

It is possible to define permissions on the Server to specify who can perform changes on model elements and representations.
A user without WRITE permission on an object will see a grey padlock on it and will not be able to modify this element.

To be able to manage the permissions, the administrators have to install the feature «Sirius Collaborative User Profiles Administrator» from the Obeo Designer Team Edition update site.

Activate Permissions on Server

To activate permissions support on the server, you can:


Notice that if you use a db store in your CDO server configuration, you must add the following property in the mappingStrategy section:

<mappingStrategy type="horizontalBranching">
	...
	<property name="qualifiedNames" value="true"/>
	...
</mappingStrategy>


Create a Shared User Profiles Project

Once your server with permissions enabled has been launched, you can create a new Shared User Profiles Project ( New > Other... > Sirius > Shared User Profiles Project), which provides facilities for defining user-specific permissions.


The first time a Server is launched with permissions activated, it creates a user profile model with the Administrators that are declared in the administrator file. See server configuration.
Administrators are user having WRITE access to the whole repository.

Once the project is created, a User Profiles table is created and opened.

Add Users


To add new users to the system, right-click on the table and select the Create User action. The following popup will appear.


Notes:

If you want these modifications to be effective, restart your Server.



Associate Users to Roles


To assign a User to a role, type «X» in the corresponding table cell (in the example above we assign the Role All Objects Reader to User user1).

To directly assign several roles to a same user, you can also select the user in the Model Explorer and edit the Roles field in the Properties view:

If you want these modifications to be effective, restart your Server.



Define new Roles & Permissions

A Role is a set of Permissions, composing a coherent list of rules. For example, we could define the Administrator role as a role which allows to modify user profile models elements ( PackagePermission on the UserProfile package_, with WRITE rights on the folder which is supposed to contain user profile models ( ResourcePermission).

There are four kinds of permissions:

Warning: With PackagePermission, EClassPermission and ConcreteObjectPermission,the corresponding metamodel elements (EPackage or EClass) must have their corresponding metamodel plugins deployed on the Server so the permission can work. See section Metamodel deployment.. This administrators must have all the metamodel plugins which are deployed on the server they want to configure.

Each permission is associated to an Access Type, which can be WRITE or READ.
When several permissions (or roles) can apply for an element, then the highest priority (e.g. WRITE versus READ) is considered.


Notice that Sirius requires all user to have at least READ access on all elements. Consequently, you should leave the default access to READ for all users.
If you want these modifications to be effective, restart your Server.

Warning: For a role with concrete ConcreteObjectPermission, the aird resource permission must be placed before all of these in the user profile model or exceptions will occurs.

To do that, the only solution is to create the aird resource permission before any concrete one in a role. You cannot create the aird resource permission if a concrete one is already present. In such case, remove all concrete permission, create the resource one and recreate the concretes.

User profile configuration examples

User profiles configuration will allow you to to give WRITE right on semantic elements and/or on their representations in table or diagrams.
If you allow only semantic model modifications, user can perform that changes mainly from the properties view. Any tool or action that includes representation changes will not be allowed.
On the contrary, if you forbid only semantic changes, you may allow representations creation and modification, open editors and perform graphic changes such as resizing container.

Functional need Needed access type Needed permission
Allow any changes Write access to the whole repository (including the user profiles model) ResourcePermission .* or /.*
Allow exporting local project to the server It requires Write access to the root resource of the repository ResourcePermission /
Allow any changes in a specific project It requires Write access to any resource in that specific project ResourcePermission /MyProject/.*
Allow changes in semantic models It requires Write access to every resource of a given extension (here «myext») ResourcePermission .*\.myext
Allow representation creation and Viewpoint activation You can provide a write access on .aird resource ResourcePermission .*\.aird
Allow representation creation only It requires a write access on any DView class instance ClassPermission org.eclipse.sirius.viewpoint.DView
Allow representation content modification It requires Write access to .srm resource ResourcePermission .*\.srm

By default, the user profile model is initialized with permissions to:

Special case for representation folder

In the Representations Lazy Loading mode , available if CDOSiriusPreferenceKeys.PREF_CREATE_SHARED_REP_IN_SEPARATE_RESOURCE is set to true, by default the representations are stored in srm resources located in .representations folder in the project.
For that reason, we need a resource permission with .*/\.representations regular expression that will be required(but not sufficient) to create a new representation. As it is considered as a technical permission, it is automatically created at user profile model initialization and automatically associated to any added user in the user profile model. That permission will be automatically added when exporting a user profile model to the server.

Deploy metamodels used in permissions on Server

PackagePermission, ClassPermission and ConcreteObjectPermission are applied on elements of a specific EMF metamodel.

If the metamodel plugin containing the elements used in permissions is not installed on the Server, then the permission won’t work.

The Server is provided by default with only the Ecore metamodel deployed.

To deploy a metamodel used in your permissions, you have to use p2.director application available in some Eclipse package like Obeo Designer.

The steps to deploy your metamodel from such package to a target Collab server is the following :

On Windows:

<executableName> -application org.eclipse.equinox.p2.director -console -consoleLog -repository <pathToUpdateSite> -installIU <metamodelPlugin> -tag <tagName> -destination <pathToServerRootDirectory> -profile DefaultProfile  

where you must customize only:

You can find more information on the p2 director application here.

If the installation fails, a stack will be available in the .log file of the configuration folder of the package from which you launch the deployment. You can check if it was properly install by opening the file «configuration/org.eclipse.equinox.simpleconfigurator/bundles.info» that lists every plug-ins that was installed.

On Linux distribution:

The same mechanism as Windows is used except that the command line must start by ./:

./<executableName> -application org.eclipse.equinox.p2.director -console -consoleLog -repository <pathToUpdateSite> -installIU <metamodelPlugin> -tag <tagName> -destination <pathToServerRootDirectory> -profile DefaultProfile  

Import/Export the User Profiles

It is possible to reuse a user profile model defined in another existing repository. To do so, you can use:


Note that if you export an user profile model containing ConcreteObjectPermission, you must check before that objects referenced by each ConcreteObjectPermission exist in the target repository.

User profile example

This section shows a user profile with different roles containing the four different kinds of permissions and with for each role the aird resource permission allowing to edit authorized elements from other permissions with Sirius tables and diagrams editors.

Administrator commands

Resource rename

The Rename command allows, from the CDO Sessions view, to rename the full path of an EMF resource. The full path means the name of the resource and all the folder parts name representing the path of the resource.
It is not enabled in a Read-Only View.

It is not possible to change the resource extension.

The resources (representation and other) impacted by the rename are coherently changed to keep integrity in the repository.

After such changes, existing user sessions must be deleted and recreated.

Resource deletion

The Deletion command allows, from the CDO Sessions view, to delete an EMF resource.
It is not enabled in a Read-Only View.

The resources (representation and other) impacted by the deletion are coherently changed to keep integrity in the repository.

After such changes, existing user sessions must be deleted and recreated.

Importer Application

The importer is an application used to extract the project from the cdo server database to a local folder.
It produces as many zip file as modeling project.
It can also be used to import the user profiles model.

The importer also extracts information from the CDO Commit history in order to produce a representation of the activity made on the repository. This information is denominated '‹Activity metadata›'. See help chapter The commit history view and Commit description preferences for a complete explanation. By default, the importer will extracts '‹Activity Metadata›‹ for every commits on the repository. Be aware that the parameter ›‹-projectName›‹ has no impact on this feature. It will also export commits that do not impact the selected project. Still, it is possible to specify a range of commit using the parameters ›‹-to›‹ and ›‹-from›'.

Note: The Importer application does not require a license.

Importer strategies

Several import strategies are supported by the Importer application:

Importer parameters

The importer needs credentials to connect to the CDO server if the server has been started with authentication or user profile.
Credentials can be provided using either -importerCredentials or -importerLogin and -importerPassword parameters. Credentials are required only for Connected import .

Here is a list of arguments that can be set to the Importer (in importer.bat or in a launch config):

Arguments Description
-importerCredentials Login and password can be provided using a credentials file. It is the recommended way for confidentiality reason. If the credentials does not contain any password, the password will be searched in the eclipse secure storage. See how to set the password in the secure storage
This parameter must not be used with -importerLogin or -importerPassword parameters else the importer will fail.

To use this property file
* Add the following program argument: -importerCredentials path_to_credentials_file
* Fill the specified file using the following format (only one line allowed):
aLogin:aPassword

Note: credentials are only required for the not required for Connected imports .
-importerLogin The importer needs a login in order to connect to the CDO server if the server has been started with authentication or user profile.
-importerPassword must not be used with -importerCredentials else the application will fail.
Note: credentials are not required for Connected imports .
-importerPassword This parameter is used to provide a password to the importer accordingly to the login.
If -importerPassword is not used, the password will be searched in the eclipse secure storage. See how to set the password in the secure storage
-importerPassword must not be used with -importerCredentials else the application will fail.
Warning: some special characters like double-quote might not be properly handled when passed in argument of the importer. The recommended way to provide credentials is through the importerCredentials file or the secure storage.
Note: credentials are only required for Connected imports .
-hostName Define the team server hostname (default: localhost).
-port Define the team server port (default: 2036).
-connectionType The connection kind can be set to tcp or ssl (keep it in low case) (default: tcp).
-importType The backup is available in three different modes:
PROJECT_ONLY to only export the shared modeling projects from the CDO repository to local;
SECURITY_ONLY to only export the shared user profile project from the CDO repository to local;
ALL to export both.
(default: PROJECT_ONLY)
-repoName Define the team server repository name (default: designer-server).
-projectName By default, all projects are imported (with the right -importType parameter). Argument «-projectName X» can be used to import only project X (default: *).
-runEvery Import every x minutes (default -1: disabled).
-archiveFolder (deprecated) Define the folder where to zip projects (default: workspace). This argument is deprecated. Instead you should use -outputFolder (and -archiveProject=true but true is its default value).
-outputFolder Define the folder where to import projects (default : workspace).
-logFolder Define the folder where to save logs (default : outputFolder).
-archiveProject Define if the project should be zipped (default : true). Each project will be zipped in a separate archived suffixed with the date.
-overrideExistingProject If the output folder already contains a project with the same name this argument allows to remove this existing project.
-checkSize Check project zip file size in Ko under which the import of this project fails (default: -1(no check)).
-checkSession Import zip file and open then close session (default: true).
-errorOnInvalidCDOUri Raise an error on cdo uri consistency check (default: true).
-addTimestampToResultFile Add a time stamp to result files name (.zip, logs, commit history) (default: true).
-optimizedImportPolicy This option is no longer available since 1.1.2.
-maxRefreshAttemptBeforeFailure The max number of refresh attempt before failing (default: 10). If the number of attempts is reached, the import of a project will fail but as this is due to the activity of remote users on the model.
-timeout Session timeout used in ms (default: 60000).
-exportCommitHistory Whether the Commit History metadata should be exported. (default: true).
If the value is false, all other options about the commit history will be ignored.
-from The timestamp specifying the date from when the metadata will be exported. The timestamp should use the following format yyyy-MM-ddThh-mm-ss.SSS. For example, for the date 03/08/2017 14h28m453ms use the timestamp 2017-08-03T10:14:28.453. It can also be computed from an '‹Activity Metadata›' model. In that case, this parameter could either be an URL or a path in the file system to the location of the model. The framework selects the closest commit following this date. If omitted, then exports from the first commit of the repository.
-to The timestamp specifying the latest commit used to export metadata. The timestamp should use the following format yyyy-MM-ddThh-mm-ss.SSS. For example, for the date 03/08/2017 14h28m453ms use the timestamp 2017-08-03T10:14:28.453. The framework selects the closest commit preceding this date. If omitted, exports to the last commit of the repository. ''Be careful, due to technical restrictions, this parameter only impacts the range of commit for exporting activity metadata from the CDO server. Using this parameter will not export the version of the model defined by the given date.''
-importCommitHistoryAsText Import commit history in a text file using a textual syntax (default: false). The file has the same path as the commit history model file, but with txt as extension.
-importCommitHistoryAsJson Import commit history in a json file format (default: false). The file has the same path as the commit history model file, but with json as extension.
-includeCommitHistoryChanges Import the commit history detailed changes for each commit (default: false). This option is applied for all kinds of export of the commit history(xmi, text or json files).
-XMLImportFilePath This option allows to activate the Offline import . The expected argument is the file path of an XML extraction of the repository. It is recommended to provide an absolute path. some arguments will be ignored with -XMLImportFilePath argument since we do not establish any connection with the server. Only the arguments -outputfolder and -repoName are mandatory.
-help Print help message.


If the server has been started with user profile, the Importer needs to have write access to the whole repository (including the user profiles model).
See Resource permission pattern examples section.

If this recommendation is not followed, the Importer might not be able to correctly prepare the model (proxies and dangling references cleaning, ...). This may lead to a failed import.

Launching the importer

As a Launch Configuration

-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog
-outputfolder C:\Users\UserLogin\Desktop\Importer
-logfolder C:\Users\UserLogin\Desktop\Importer\Logs
-archiveproject false
-overrideexistingproject true
-importType ALL
-importerLogin admin
-importerPassword admin
-connectionType tcp
-port 2036
-repoName designer-server
-checkSize -1
-importCommitHistoryAsJson true
-importCommitHistoryAsText true

As a command file

eclipsec.exe ^
--launcher.suppressErrors ^
-nosplash -console -consoleLog ^
-data importer-workspace ^
-application fr.obeo.dsl.viewpoint.collab.importer ^
-importerCredentials importerLoginPassword.properties ^
-checksize -1 ^
%* ^
-vmargs -Xms1000m -Xmx3000m -Xss4m -Dorg.eclipse.net4j.util.om.trace.disable=true

Examples

Example1: import project

importer.bat -nosplash -data importer-workspace
-outputFolder C:/Sirius/result
-connectionType ssl
-checkSize 10

Example2: import user profile model

importer.bat -nosplash -data importer-workspace
-outputFolder C:/Sirius/result
-connectionType ssl
-checkSize -1
-importType SECURITY_ONLY

How to set the Importer credentials in secure storage

The importer does not use the same credentials as the user. It is stored in a different entry in the Eclipse ‹Secure Storage›. Storing and clearing the credentials requires the application presented in the following parts.

How to set the Importer credentials in secure storage with an Eclipse application

-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog
-importerLogin admin
-importerPassword admin
-hostname localhost
-port 2036
-repoName designer-server

How to clear the Importer credentials in secure storage with an Eclipse application

-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog
-clearStoredCredentials true
-hostname localhost
-port 2036
-repoName designer-server

Annex: Managing certificate

Keytool can be used to create and manage certificates and stores. This tool is provided with the JDK and its documentation is available here.

Generate a keystore

The keystore contains certificate information, private and public key. To generate it use the following command:

keytool -genkey -ext SAN=IP:<server IP> -keyalg "RSA" -dname o=sevenSeas -alias keystore_alias -keystore server.ks -storepass secret -validity 730 -keysize 4096

-ext: For example, <server IP> may be the LDAP server for SSL connection between CDO server and LDAP server or may be the CDO Server for SSL connection between client and CDO server.
-dname: optional. It initializes the metadata of your organization.

When the key password is asked, press Enter, to keep the same password as the key file’s.

Sign your certificate from a certificate authority(optional)

This step is optional and you may then proceed with Export certificate from a keystore.
For that step, you have to give your certificate signature request(server.csr) to your certificate authority(CA) which, in return will provide a signed certificate(server.crt).

keytool -certreq  -alias keystore_alias -file server.csr -keystore "server.ks"

The two steps below allow to import root certificate and intermediary certificate.

keytool -import -alias Root_CA -keystore server.ks -file Root_CA.cer
bc. keytool -import -alias Server_CA -keystore server.ks -file Server_CA.cer

Then, import the signed certicated into the server.ks keystore.

keytool -import -alias keystore-signed -keystore server.ks -file server.crt

Export certificate from a keystore

To export a certificate from an existing keystore, use the following command accordingly to the keystore generation example

keytool -export -keystore server.ks -alias keystore_alias -file server.cer

This command asks for the store’s passphrase (Enter secret accordingly to the example) and then create a server.cer file containing the certificate previously created.

Create a truststore from a certificate

It is advised to not export the whole keystore on clients. Creating a truststore containing only the certificate and public key is recommended. This truststore is intended to be deployed on clients which need to connect to the server.

keytool -import -file server.cer -alias keystore_alias -keystore trusted.ks -storepass secret

When asked for «Trust this certificate?» enter yes.
This command creates a new truststore in file trusted.ks. This truststore contains the server’s public key, it can be copied on client machines and referenced via the truststore.path configuration key.

The truststore is protected with secret as a passphrase.