Configuration

RDepot is configured through static YAML files.

Manager App

It is recommended to create two configuration files to override the default values of the RDepot manager application:

• application.yml containing general configuration
• authentication.yml containing configuration related to authentication

These files should be added to the same folder from where the manager app is run.

You can find up-to-date configuration examples on the Deployment page or in the integration tests of RDepot:

• authentication.yml
• application.yml

Repositories

As an alternative to configuring repositories through the interface you can specify them in the configuration. This is especially useful for scripted deployments.

repositories:
  - name: A
    publication-uri: http://mydomain.com/repo/A
    server-address: http://oa-rdepot-repo:8080/A
  - name: B
    publication-uri: http://mydomain.com/repo/B
    server-address: http://oa-rdepot-repo:8080/B
  - name: C
    publication-uri: http://mydomain.com/repo/C
    server-address: http://oa-rdepot-repo:8080/C

For each repository the following fields should be specified:

• name: repository name
• publication-uri: the external uri of the repository
• server-address: the internal address which the manager app uses to communicate with the repo server.

Database

It is recommended to use a PostgreSQL-compatible database. Other SQL flavours may work but have not been tested.

You can configure access to your database in a db block:

• db.driver : the database driver. Since the recommendation is to use postgres, this should be kept at org.postgresql.Driver
• db.url : JDBC connection url
• db.username: username/role to connect with
• db.password: password to connect with

Authentication

The RDepot manager application supports multiple authentication backends. You can select the authentication method to use via the app.authentication field.

Simple Authentication

Users can be defined directly in the configuration file. To do so, select the simple authentication method. You can then define the users under app.simple:

app:
  simple:
    users:
      - login: einstein
        password: testpassword
      - login: tesla
        password: testpassword
      - login: galileo
        password: testpassword
      - login: newton
        password: testpassword
      - login: newbie
        password: testpassword
        name: New User

LDAP Authentication

The following properties can be set:

• app.ldap.url: the LDAP connection string
• app.ldap.basedn: base DN (distinguished name)
• app.ldap.userou: user OU (organizational unit)
• app.ldap.loginfield: field to use for login
• app.ldap.namefield: field to use for name
• app.ldap.emailfield: field to use for email
• app.ldap.default.admins: array of default admins. For example: [ "admin" , "einstein", "newton" ]

OpenID Connect (OIDC)

OpenID Connect is a modern authentication protocol based on the OAuth2 standard. OIDC supports multiple authentication flows. The standard authentication flow applicable for web apps is three-legged (auth provider, client/application and user) and is based around tokens. This removes the need to store passwords and enables a single-sign-on experience.

To configure OIDC in the RDepot manager application, the following properties can be set:

• app.authentication: should be set to oidc
• app.openid.auth-url: the endpoint that will be used by the manager application to initiate the authentication flow. This is where users will be redirected when visting the app without a (valid) token.
• app.openid.token-url: the endpoint where tokens can be retrieved or exchanged. This is used during the authentication process.
• app.openid.jwks-url: the endpoint where the provider’s public certificates can be found. This is used during the authentication process.
• app.openid.client-id: unique ID generated by the provider for your client/application
• app.openid.client-secret: a secret generated by the provider for your client/application
• app.openid.default.admins: array of default admins. For example: [ "admin" , "einstein", "newton" ]

The client id and secret are sensitive and should be treated as such.

Keycloak

Keycloak is an open source identity and access management system supported by Red Hat. Using keycloak as an authentication backend to the RDepot manager enables advanced features such as User Federation, Identity Brokering and Social Login.

Keycloak supports both OIDC and SAML, but in the context of the RDepot manager, which relies on the client adapter for Spring, only OIDC can be used.

Keycloak authentication can be configured as follows:

• app.authentication: should be set to keycloak
• app.keycloak.realm: Keycloak allows to divide the identity space into distinct reams. You can use this property to select the appropriate one.
• app.keycloak.auth-server-url: the endpoint that will be used by the manager application to initiate the authentication flow.
• app.keycloak.baseUrl: the base url of RDepot manager, essentially the site url.
• app.keycloak.resource: client/application id
• app.keycloak.credentials-secret: client/application secret
• app.keycloak.ssl-required: SSL/HTTPS mode. One of none, all or external (default). Read more here.
• app.keycloak.principal-attribute: the identity-defining attribute to use in the manager application.
• app.keycloak.default.admins: array of default admins. For example: [ "admin" , "einstein", "newton" ]

General information on how to configure Keycloak can be found here, but should look similar to the following:

1. define a new client and set the access type to confidential
2. obtain a summary of the settings to configure the RDepot manager from the Installation tab

Logging

By default, information about various application events will be logged into the standard output stream of the process.

You can also send the log output to a file via the logging.file setting:

logging:
  file:
    rdepot.log

You can change the log level by using the logging.level.<component> setting, where <component> can be either of:

• root: this affects all components
• any specific component: e.g. org.springframework.web.filter.CommonsRequestLoggingFilter

A full discussion of all components is out-of-scope for this document.

Storage

• storage.implementation: Currently only a single storage implementation is supported: local.
• localStorage.maxRequest: Maximum request size
• requestTimeout: Timeout for requests

Repo Server

TODO

Sensitive Configuration