deployment.md

hide:

- navigation

Deployment

!!! info "Abstract"

We modified some services and exchanged them with reviewed, open-source implementations that extend the functionality
even more from version 1.2 onwards. On this page, some of the configuration possible is summarized.

Authentication Service

From version 1.2 onwards we use Keycloak for authentication and deprecated the previous Spring Boot application. Consequently, the authentication will be through Keycloak.

!!! warning "Unsupported Keycloak features"

Due to no demand at the time, we currently do not support the following Keycloak features:

* E-Mail verification
* Temporary passwords

By default, the Authentication Service comes with a self-signed certificate valid 3 months from build date. For deployment it is highly encouraged to use your own certificate, properly issued by a trusted PKI, e.g. GEÁNT. For local deployments you can use the self-signed certificate. You need to accept the risk in most browsers when visiting the admin panel.


Google Chrome warning about the self-signed certificate

Sign in with the default credentials (username fda, password fda) or the one you configured during set-up. Be default, users are created using the frontend and the sign-up page. But it is also possible to create users from Keycloak, they will still act as "self-sign-up" created users. Since we do not support all features of Keycloak, leave out required user actions as they will not be enforced, also the temporary password.


Alternative user creation via Keycloak

Identifier Service

From version 1.2 onwards there are two modes for the Identifier Service:

1. Persistent Identifier (PID)
2. Digital Object Identifier (DOI)

By default, the URI mode is used, creating a PID for databases or subsets. If starting the Identifier Service in DOI mode, a DOI is minted for persistent identification of databases or subsets. Using the DOI system is entirely optional and should not be done for test-deployments.


Minting a test-DOI for a subset

Gateway Service

From version 1.2 onwards we use both HTTP and HTTPS to serve the API, especially for the Authentication Service. The Discovery Service lists both the non-secure and secure ports.