Server Configuration

You can activate LDAP authentication in three different ways:

The server must be restarted to take into account the modifications done in the cdo-server.xml file.

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.

ldap-config.properties 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.

As access control modes are exclusive, other modes must be commented in the cdo-server.xml file:

The LDAP authenticator’s configuration file is a properties file whose content could look like the following one:

where :

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.

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.

Some LDAP does not support anonymous binding (if your LDAP server doesn’t even allow a query without authentication), then Capella would have to first authenticate itself against the LDAP server, and Capella does that by sending the «manager» DN and password. Using this specific connection, the user credentials (given by the user in the authentication popup) 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:

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.

Once the authentication with OpenIDConnect succeded the T4C client browser will call T4C admin server on redirect URI passing some information inside cookies. So The T4C client browser needs to trust the URL and authorize cookies.

On windows, the configuration is done in Internet properties.

On the OpenID Connect platform, there is one property that requires to be properly set: the redirect URI. Indeed, the embedded web server expects that the redirect URI is the page /auth/redirect. This means that the redirect URI must be set to

On client side, users will have to use WS or WSS connection types regarding the configuration of the server.

The client side configuration will depend on the global deployment of the current server and the use of the WS and WSS connection types.

Then a user will have to use the following parameters to connect to the repository:

When the REST Admin server runs in HTTPS mode, it will be configured with a certificate.

When WebSocket transport is activated on the server, the importer and other tools must be configured accordingly to be successful. The same configuration than the client needs to be done in the -vmargs section of the tools script (importer.bat, maintenance.bat, exporter.bat, …​).

The REST Admin Server and the CDO Server need to be configured to enabled the Net4J WebSocket-based transport:

The move from a Websocket-based transport to a SecuredWebsocket-based transport can be done through Jetty configuration by enabling HTTPS, or with the use of an HTTPS reverse proxy server (Nginx or Apache for example).

Here is a list of optional settings which will impact both server and clients configurations:

Add the following lines in the client capella.ini file:

When SSL is activated on the server, the importer and other tools must be configured accordingly to be successful. Add the following lines in the script files (importer.bat, maintenance.bat, exporter.bat):

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:

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

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

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).

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

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

To export a certificate from an existing keystore the following command can be used :

This command asks for the store’s passphrase and then create a server.cer file containing the certificate previously created.

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.

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.

The REST Admin Server provides a whole set of services to manage the projects, the models and the users. The documentation is available at the URL http(s)://<admin server IP>:<admin server port>/doc

A swagger documentation is available at the URL http(s)://<admin server IP>:<admin server port>/openapi. It can be enabled or disabled with the admin.server.jetty.servlets.admin.docandopenapi.enabled property

The first time the server is launched, a default «admin» user and its associated default token are created in the Eclipse secure-storage of the user that started the CDO server. The «admin» credentials are stored in a dedicated node used by the server. The token is hashed and encrypted. A secret.txt file, containing the token, is created in the same folder than admin-server.properties file. It can be used in third party application to authenticated with the admin server. Do not forget to remove this file as soon as you can.

Moreover, the admin credentials are also added in the secure storage for the application needs (importer, exporter, etc) in a dedicated node. The credentials are encrypted.

This way once the server has been started the first time, there is no additional step. The applications can automatically be used, being authenticated with the admin server with the «admin» user.

Nevertheless, it is possible to manage the user and the user token with the Credentials application

By default, the secure storage is created or retrieved from the home of the system user currently executing the application:

It is also possible to change the location of the secure storage with the use of the -eclipse.keyring program argument in both TeamForCapella/server/server.ini and TeamForCapella/capella/capella.ini. The secure storage must be shared between server-side client, tools and server in order to be able to use it from the Scheduler jobs. For example to use a fixed secure storage located in TeamforCapella/.eclipse/secure_storage:

The -eclipse.password option can be used with -eclipse.keyring, it allows to use the content of the specified file as the default password instead of saving the password in the secure storage. On Linux, this helps to overcomes issues related to passwords management by secure storage and the use of the default PasswordProvider.

Installation process and details are described in the Installation Guide for Team for Capella.

Moreover, do not install any viewpoint except PROPERTIES KEY/VALUES-typed viewpoint. Ask to viewpoint providers whether their viewpoint is compatible with Team for Capella.

If the viewpoint is compatible with Team for Capella, deploy the viewpoint on every Team for Capella client and the importer used by server. Clean and export models again after a viewpoint installation.

The use of the Database – Restore job should be preferred but it is still possible to manually do the same operation.

This operation should be used to restore a database from the file generated by the Database – Backup job (this file has a pattern like: repoCapella.20151105.171109-sql.zip).

The database will be restored in exactly the same state as it was when the backup was performed:

This way gives more control on the restoration as you may delete the repository and the repository is restored project by project. To restore projects in a repository:

The system property fr.obeo.dsl.viewpoint.collab.common.commit.description.max.length can modify the length of the commit message. By default the value is the Integer maximum value. This property needs to be set to the same value on the client and the server.

This default Integer maximum value length is due to com.thalesgroup.mde.melody.db.h2.H2Adapter that consider the commit comment as a CLOB. Note that this is a custom H2Adapter for Team for Capella. It replaces the default org.eclipse.net4j.db.h2.H2Adapter that expects a VARCHAR for the comment description DB field limiting the length of the message to 255 characters. If the commit description is longer than the accepted max length, it will be truncated before commit to match the max length in core wizards, actions and session save operations. For components extending the collaborative layer, if they directly call setCommitComment() and commit() methods on the CDO transaction, they can use fr.obeo.dsl.viewpoint.collab.common.internal.commit.CommitCommentUtil.fitCommitDescriptionLength(String) to fit their commit comment. -1 can be used to remove the limitation. Otherwise only values greater than or equals to 10 are accepted. "Xxxxxxxxxx" will become "Xxxx […​]". If the property value if -1, it will take the system dependent SWT widget Text.LIMIT length.