The aim of this document is to explain how to configure and deploy OperatorFabric.

1. Deployment

For now OperatorFabric consist of Docker images available either by compiling the project or by using images releases from Dockerhub

Service images are all based on openjdk:8-jdk-alpine.

For simple one instance per service deployment, you can find a sample deployment as a docker-compose file here

To run OperatorFabric in development mode, see the development environment documentation.

2. RabbitMQ

2.1. Docker container

In development mode, the simplest way to deploy a RabbitMQ server is to create a RabbitMQ docker container. A docker-compose file is provided to allow quick setup of a convenient RabbitMQ server.

2.2. Server installation

This section is dedicated to production deployment of RabbitMQ. It is not complete and needs to be tailored to any specific production environment.

2.2.1. Download & Installation

Download and install RabbitMQ following the official procedure for the target environment

2.2.2. Used ports

If RabbitMQ may not bind to the following ports, it won’t start :

  • 4369: epmd, a peer discovery service used by RabbitMQ nodes and CLI tools

  • 5672, 5671: used by AMQP 0-9-1 and 1.0 clients without and with TLS

  • 25672: used for inter-node and CLI tools communication (Erlang distribution server port) and is allocated from a dynamic range (limited to a single port by default, computed as AMQP port + 20000). Unless external connections on these ports are really necessary (e.g. the cluster uses federation or CLI tools are used on machines outside the subnet), these ports should not be publicly exposed. See networking guide for details.

  • 35672-35682: used by CLI tools (Erlang distribution client ports) for communication with nodes and is allocated from a dynamic range (computed as server distribution port + 10000 through server distribution port + 10010). See networking guide for details.

  • 15672: HTTP API clients, management UI and rabbitmqadmin (only if the management plugin is enabled)

  • 61613, 61614: STOMP clients without and with TLS (only if the STOMP plugin is enabled)

  • 1883, 8883: (MQTT clients without and with TLS, if the MQTT plugin is enabled)

  • 15674: STOMP-over-WebSockets clients (only if the Web STOMP plugin is enabled)

  • 15675: MQTT-over-WebSockets clients (only if the Web MQTT plugin is enabled)

2.2.3. Production configuration

See the guide for production configuration guidelines

3. Configuration

OperatorFabric has multiple services to configure. These configurations are managed by a Configuration Service, of which they can be several instances to ensure availability.

See OperatorFabric Architecture for more information on the different services.

All services are SpringBoot applications and use jetty as an embedded servlet container. As such, they share some common configuration which is described in the following documentation:

3.1. Global configuration

Aside from the one for the configuration service, all configurations are gathered as resources in the configuration service (under /services/infra/config/src/main/docker/volume).

Note that a few things cannot be set in the configuration served by the configuration service (because its needed right at the application startup for example) and must be set in each services bootstrap configuration file. In this regard, Cloud Configuration service[Configuration] and Cloud Registry service[Registry] services have specific configuration but for other services, they all require the same minimal information:

  • mandatory service name(spring.application.name)

  • mandatory configuration name (spring.cloud.config.name)

  • mandatory configuration fetch from registry enabled (spring.cloud.config.discovery.enabled: true)

  • mandatory configuration service name in registry (spring.cloud.config.discovery.service-id)

  • mandatory eureka registration (eureka.client.register-with-eureka: true and eureka.client.fetch-registry: true)

  • mandatory eureka registry urls (eureka.client.service-url.defaultZone)

  • configuration fail fast (spring.cloud.config.fail-fast)

  • configuration fetch maximum retry (spring.cloud.config.retry.max-attempts)

In most situation, you do not need to change the default bootstrap configuration for those services. Make a copy of the default bootstrap (inside the jar or from the sources) and set eureka up (see above).

The different services also share common configuration you can setup in the config service backend. those common configuration may be set up in the backend application.yml file.

spring:
  rabbitmq:
    host: rabbitmq
    port: 5672
    username: guest
    password: guest
  data:
    mongodb:
      uris:
        - mongodb://root:password@mongodb:27017/operator-fabric?authSource=admin&authMode=scram-sha1
  security:
    oauth2:
      resourceserver:
        jwt:
          jwk-set-uri: http://authserver/auth/realms/dev/protocol/openid-connect/certs
eureka:
  client:
    service-url:
      defaultZone: http://registry:8080/eureka
    region: default
  registryFetchIntervalSeconds: 5

operatorfabric:
  security:
    oauth2:
      client-id: opfab-client
      client-secret: opfab-oauth-secret
    jwt:
      login-claim: preferred_username
      expire-claim: exp

In the above example you can see that we need to configure:

3.2. OperatorFabric Mongo configuration

We only use URI configuration for mongo through the usage of the spring.data.mongodb.uris, it allows us to share the same configuration behavior for simple or cluster configuration and with both spring classic and reactive mongo configuration. See mongo connection string for the complete URI syntax.

3.2.1. Define time to live for archived cards

By default, archived cards will remain stored in the database forever. It is possible to have them automatically removed after a specified duration by using the TTL index feature of mongoDB on their publishDate field.

For example, to have cards expire after 10 days (864000s), enter the following commands in the mongo shell:

use operator-fabric
db.archivedCards.createIndex( { "publishDate": 1 }, { expireAfterSeconds: 864000 } )
You cannot use createIndex() to change the value of expireAfterSeconds of an existing index. Instead use the collMod database command in conjunction with the index collection flag. Otherwise, to change the value of the option of an existing index, you must drop the index first and recreate.

3.3. OperatorFabric Specific configuration

Below are description of OperatorFabric specific configuration properties.

Note that other components may have specific configuration, see the relevant sub-sections.

3.3.1. Security Configuration

Common configuration

This concern is configured within the ${OF_HOME}/services/infra/config project into 3 distinct files:

  • application.yml;

  • web-ui.yml;

  • client-gateway.yml.

They are located into the following folders within the ${OF_HOME}/services/infra/config/java/src/main/docker/volume folder:

  • dev-configurations: to be use into dev mode;

  • docker-configurations: used by docker at run time.

EXAMPLE: the configuration for dev before compilation is done in the following files: - ${OF_HOME}/services/infra/config/java/src/main/docker/volume/dev-configurations/application.yml; - ${OF_HOME}/services/infra/config/java/src/main/docker/volume/dev-configurations/client-gateway.ym; - ${OF_HOME}/services/infra/config/java/src/main/docker/volume/dev-configurations/web-ui.yml.

For test purposes in dev mode, it’s possible to edit files located into `${OF_HOME}/services/infra/config/build/docker-volume/dev-configurations. Be aware that those changes will be lost after a new compilation or even a simple re-run of the project.

This configuration files follow the springframework configuration convention. Within a same file it’s possible to use SpEL ${} convention. For example, ${AnotheProperty} allows to re-use the value of AnotherProperty already declared. It helps to avoid typos or missing to report some changes. An example could be find below into the delegate-url property.

application.yml
name default mandatory? Description

operatorfabric.security.oauth2.client-id

null

yes

Oauth2 client id used by OperatorFabric may be specific for each service

operatorfabric.security.oauth2.client-secret

null

yes

Oauth2 client secret used by OperatorFabric may be specific for each service

operatorfabric.security.jwt.login-claim

sub

no

Jwt claim is used as user login or id

operatorfabric.security.jwt.expire-claim

exp

no

Jwt claim is used as token expiration timestamp

spring.security.oauth2.resourceserver.jwt.provider-url

null

yes

The keycloak instance url

spring.security.oauth2.resourceserver.jwt.provider-realm

null

yes

The realm name within the keycloak instance

example of application.yml

operatorfabric:
    security:
        oauth2:
            client-id: opfab-client
            client-secret: opfab-keycloak-secret
        jwt:
            login-claim: preferred_username
            expire-claim: exp

where operatorfabric.security.jwt.expire-claim could have been omitted because having the same value as the default one.

client-gateway.yml

In a configuration service client-gateway.yml file

  • The application must set up a route to the oauth server

    • /auth/token(?<path>.*): must match the oauth2 token entry point;

    • /auth/code/(?<params>.*): must match the auth entry point with specific query parameters like response_type=code&client_id=[client id]&${params};

    • /auth/check_token: must match token introspection entry point

  • The application must add request header for each request:

    • AddRequestHeader: Authorization, Basic: followed, separated with a space, by the OAuth2 client-id and the OAuth2 client-secret encoded in base64.

  • The application may set up CORS rules if api are to be accessed from browser outside of the deployment domain

Configuration example of the filters, for the docker dev keycloak:

spring.cloud.gateway.routes[0].filters:
        - RewritePath=/auth/token(?<path>.*), /auth/realms/dev/protocol/openid-connect/token$\{path}
        - RewritePath=/auth/code/(?<params>.*), /auth/realms/dev/protocol/openid-connect/auth?response_type=code&client_id=opfab-client&$\{params}
        - RewritePath=/auth/check_token, /auth/realms/dev/protocol/openid-connect/token/introspect
        - AddRequestHeader=Authorization, Basic b3BmYWItY2xpZW50Om9wZmFiLWtleWNsb2FrLXNlY3JldA==

where: - spring.cloud.gateway.routes.uri: is your keycloak instance - spring.cloud.gateway.routes[0] is the routes with id equals to auth; - /realms/dev: is the keycloak realm where opfab-client is defined. - b3BmYWItY2xpZW50Om9wZmFiLWtleWNsb2FrLXNlY3JldA==: is the base64 encoded string of opfab-client:opfab-keycloak-secret with opfab-client as client-id and opfab-keycloak-secret its client secret.

web-ui.yml

For OAuth2 security concerns into this file, there are two way to configure it, based on the Oauth2 chosen flow. There are two common properties:

  • operatorfabric.security.oauth2.flow.provider which corresponds to the OAuth2 provider.

  • operatorfabric.security.realm-url: which is the OAuth2 realm provider under which the OpertaroFabric client is declared.

  • operatorfabric.security.provider-url: which is the The keycloak server instance.

OAuth2 Flows and specific configuration

There are 3 OAuth2 Authentication flows available into OperatorFabric UI:

  • password grant: referred as PASSWORD mode flow;

  • code flow : referred as CODE mode flow;

  • implicit flow: referred as IMPLICIT mode flow.

OAuth2 IMPLICIT Flow

It had its own way of configuration. To enable IMPLICIT Flow authentication the following properties need to be set:

  • operatorfabric.security.oauth2.flow.mode to IMPLICIT;

  • operatorfabric.security.oauth2.flow.delegate-url with the URL of the OAuth2 leading to the .well-known/openid-configuration end-point used for authentication configuration.

Example of Keycloak configuration for OperatorFabric OAuth2 
operatorfabric:
  keycloak:
    realm: dev
  security:
    oauth2:
      flow:
        mode: IMPLICIT
        provider: Opfab Keycloak
        delagate-url: http://localhost:89/auth/realms/${operatorfabric.keycloak.realm}

Within the delegate-url property the ${operatorfabric.keycloak.realm} refers to the value of the operatorfabric.keycloak.realm declared earlier, dev here. For keycloak instance used for dev purposes, this delegate-url correspond to the realm under which the client opfab-client is registred. The url look up by the implicit ui mechanism is localhost:89/auth/realms/dev/.well-known/openid-configuration.

Keycloak instance additional configuration for dev purposes

Once connected as Admin (login:_admin_,password:_admin_ ) on keycloak (localhost:89/auth/admin) The first thing is to enable the implicit flow for opfa-client. To do so select Dev in the upper select of the right panel then click on Clients. In the table, click on opfab-client in the column Client ID. Then in the Settings tabs turn on the Implicit Flow Enabled. In the same tab, modify localhost:2002/ui/ to localhost:2002/ and localhost:4200 to localhost:4200/.

OAuth2 PASSWORD or CODE Flows

These two modes share the same way of declaring the delegate URL. The default configuration for dev is set to CODE and work straight away.

  • operatorfabric.security.oauth2.flow.mode to PASSWORD or CODE;

  • operatorfabric.security.oauth2.flow.delegate-url with the URL of the OAuth2 leading to the protocol used for authentication.

Example of Keycloak Configuration For OperatorFabric OAuth2 
operatorfabric:
  keycloak:
    realm: dev
  security:
    oauth2:
      flow:
        mode: CODE
        provider: Opfab Keycloak
        delagate-url: http://localhost:89/auth/realms/${operatorfabric.keycloak.realm}/protocol/openid-connect/auth?response_type=code&client_id=opfab-client

Within the delegate-url property the ${operatorfabric.keycloak.realm} refers to the value(also dev here) of the operatorfabric.keycloak.realm declared earlier. Here, the client-id value is opfab-client which is define as client under the realm named dev on the dev keycloak instance.

Using token
Get a token

End point: localhost:2002/auth/token

Method: POST

Body arguments:

  • client_id: string constant=clientIdPassword;

  • grant_type: string constant=password;

  • username: string any value, must match an OperatorFabric registered user name;

  • password: string any value;

The following examples will be for admin user.

Curl

command:

curl -s -X POST -d
"username=admin&password=test&grant_type=password&client_id=clientIdPassword"
http://localhost:2002/auth/token

example of expected result:

{"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1pbiIsImV4cC
I6MTU1MjY1OTczOCwiYXV0aG9yaXRpZXMiOlsiUk9MRV9BRE1JTiIsIlJPTEVfVVNFUiJdLCJqdGkiOi
IwMmQ4MmU4NS0xM2YwLTQ2NzgtOTc0ZC0xOGViMDYyMTVhNjUiLCJjbGllbnRfaWQiOiJjbGllbnRJZF
Bhc3N3b3JkIiwic2NvcGUiOlsicmVhZCIsInVzZXJfaW5mbyJdfQ.SDg-BEzzonIVXfVBnnfq0oMbs_0
rWVtFGAZzRHj7KPgaOXT3bUhQwPOgggZDO0lv2U1klwB94c8Cb6rErzd3yjJ8wcVcnFLO4KxrjYZZxdK
VAz0CkMKqng4kQeQm_1UShsQXGLl48ezbjXyJn6mAl0oS4ExeiVsx_kYGEdqjyb5CiNaAzyx0J-J5jVD
SJew1rj5EiSybuy83PZwhluhxq0D2zPK1OSzqiezsd5kX5V8XI4MipDhaAbPYroL94banZTn9RmmAKZC
AYVM-mmHbjk8mF89fL9rKf9EUNhxOG6GE0MDqB3LLLcyQ6sYUmpqdP5Z94IkAN-FpC7k93_-RDw","to
ken_type":"bearer","refresh_token":"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWI
iOiJhZG1pbiIsInNjb3BlIjpbInJlYWQiLCJ1c2VyX2luZm8iXSwiYXRpIjoiMDJkODJlODUtMTNmMC0
0Njc4LTk3NGQtMThlYjA2MjE1YTY1IiwiZXhwIjoxNTUyNzAxMTM4LCJhdXRob3JpdGllcyI6WyJST0x
FX0FETUlOIiwiUk9MRV9VU0VSIl0sImp0aSI6IjMwOWY2ZDllLWNmOGEtNDg0YS05ZjMxLWViOTAxYzk
4YTFkYSIsImNsaWVudF9pZCI6ImNsaWVudElkUGFzc3dvcmQifQ.jnZDt6TX2BvlmdT5JV-A7eHTJz_s
lC5fHrJFVI58ly6N7AUUfxebG_52pmuVHYULSKqTJXaLR866r-EnD4BJlzhk476FtgtVx1nazTpLFRLb
8qDCxeLrzClQBkzcxOt6VPxB3CD9QImx3bcsDwjkPxofUDmdg8AxZfGTu0PNbvO8TKLXEkeCztLFvSJM
GlN9zDzWhKxr49I-zPZg0XecgE9j4WITkFoDVwI-AfDJ3sGXDi5AN55Sz1j633QoqVjhtc0lO50WPVk5
YT7gU8HLj27EfX-6vjnGfNb8oeq189-NX100QHZM9Wgm79mIm4sRgwhpv-zzdDAkeb3uwIpb8g","exp
ires_in":1799,"scope":"read
user_info","jti":"02d82e85-13f0-4678-974d-18eb06215a65"}
Httpie 
http --form POST http://localhost:2002/auth/token username=admin password=test
grant_type=password client_id=clientIdPassword

example of expected result:

.HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/json;charset=utf-8
Date: Fri, 15 Mar 2019 13:57:19 GMT
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
transfer-encoding: chunked

{
    "access_token":
"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTU1MjY2MDAzOS
wiYXV0aG9yaXRpZXMiOlsiUk9MRV9BRE1JTiIsIlJPTEVfVVNFUiJdLCJqdGkiOiI2MjQzMDliMS03Yz
g3LTRjZGMtODQ0My0wMTI0NTE1Zjg3ZjgiLCJjbGllbnRfaWQiOiJjbGllbnRJZFBhc3N3b3JkIiwic2
NvcGUiOlsicmVhZCIsInVzZXJfaW5mbyJdfQ.VO4OZL7ycqNez0cHzM5WPuklr0r6SAOkUdUV2qFa5Bd
3PWx3DFHAHUxkfSX0-R4OO6iG2Zu7abzToAZNVLwk107LH_lWXOMQBriGx3d2aSgCf1yx_wI3lHDd8ST
8fxV7uNeolzywYavSpMGfgz9GXLzmnyeuPH4oy7eyPk9BwWVi0d7a_0d-EfhE1T8eaiDfymzzNXJ4Bge
8scPy-93HmWpqORtJaFq1qy4QgU28N2LgHFEEEWCSzfhYXH-LngTCP3-JSNcox1hI51XBWEqoeApKdfD
J6o4szR71SIFCBERxCH9TyUxsFywWL3e-YnXMiP2J08eB8O4YwhYQEFqB8Q",
    "expires_in": 1799,
    "jti": "624309b1-7c87-4cdc-8443-0124515f87f8",
    "refresh_token":
"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1pbiIsInNjb3BlIjpbInJlYWQiLC
J1c2VyX2luZm8iXSwiYXRpIjoiNjI0MzA5YjEtN2M4Ny00Y2RjLTg0NDMtMDEyNDUxNWY4N2Y4IiwiZX
hwIjoxNTUyNzAxNDM5LCJhdXRob3JpdGllcyI6WyJST0xFX0FETUlOIiwiUk9MRV9VU0VSIl0sImp0aS
I6ImRiYzMxNTJiLTM4YTUtNGFmZC1hY2VmLWVkZTI4MjJkOTE3YyIsImNsaWVudF9pZCI6ImNsaWVudE
lkUGFzc3dvcmQifQ.Ezd8kbfNQHOOvUCNNN4UmOOkncHiT9QVEM63FiW1rq0uXDa3xfBGil8geM5MsP0
7Q2He-mynkFb8sGNDrAXTdO-8r5o4a60zWrktrMg2QH4icC1lyeZpiwZxe6675QpLpSeMlXt9PdYj-pb
14lrRookxXP5xMQuIMteZpbtby7LuuNAbNrjveZ1bZ4WMi7zltUzcYUuqHlP1AYPteGRrJVKXiuPpoDv
gwMsEk2SkgyyACI7SdZZs8IT9IGgSsIjjgTMQKzj8P6yYxNLUynEW4o5y1s2aAOV0xKrzkln9PchH9zN
qO-fkjTVRjy_LBXGq9zkn0ZeQ3BUe1GuthvGjaA",
    "scope": "read user_info",
    "token_type": "bearer"
}
Extract token

From the previous results, the data need to be considered to be authenticated by OperatorFabric services is the content of the "access_token" attribute of the body response.

Once this value extracted, it need to be passed at the end of the value of the http HEADER of type Authorization:Bearer. example from previous results:

Curl 
Authorization:Bearer
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTU1MjY1OTczOCw
iYXV0aG9yaXRpZXMiOlsiUk9MRV9BRE1JTiIsIlJPTEVfVVNFUiJdLCJqdGkiOiIwMmQ4MmU4NS0xM2Y
wLTQ2NzgtOTc0ZC0xOGViMDYyMTVhNjUiLCJjbGllbnRfaWQiOiJjbGllbnRJZFBhc3N3b3JkIiwic2N
vcGUiOlsicmVhZCIsInVzZXJfaW5mbyJdfQ.SDg-BEzzonIVXfVBnnfq0oMbs_0rWVtFGAZzRHj7KPga
OXT3bUhQwPOgggZDO0lv2U1klwB94c8Cb6rErzd3yjJ8wcVcnFLO4KxrjYZZxdKVAz0CkMKqng4kQeQm
_1UShsQXGLl48ezbjXyJn6mAl0oS4ExeiVsx_kYGEdqjyb5CiNaAzyx0J-J5jVDSJew1rj5EiSybuy83
PZwhluhxq0D2zPK1OSzqiezsd5kX5V8XI4MipDhaAbPYroL94banZTn9RmmAKZCAYVM-mmHbjk8mF89f
L9rKf9EUNhxOG6GE0MDqB3LLLcyQ6sYUmpqdP5Z94IkAN-FpC7k93_-RDw
Httpie 
Authorization:Bearer
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTU1MjY2MDAzOSw
iYXV0aG9yaXRpZXMiOlsiUk9MRV9BRE1JTiIsIlJPTEVfVVNFUiJdLCJqdGkiOiI2MjQzMDliMS03Yzg
3LTRjZGMtODQ0My0wMTI0NTE1Zjg3ZjgiLCJjbGllbnRfaWQiOiJjbGllbnRJZFBhc3N3b3JkIiwic2N
vcGUiOlsicmVhZCIsInVzZXJfaW5mbyJdfQ.VO4OZL7ycqNez0cHzM5WPuklr0r6SAOkUdUV2qFa5Bd3
PWx3DFHAHUxkfSX0-R4OO6iG2Zu7abzToAZNVLwk107LH_lWXOMQBriGx3d2aSgCf1yx_wI3lHDd8ST8
fxV7uNeolzywYavSpMGfgz9GXLzmnyeuPH4oy7eyPk9BwWVi0d7a_0d-EfhE1T8eaiDfymzzNXJ4Bge8
scPy-93HmWpqORtJaFq1qy4QgU28N2LgHFEEEWCSzfhYXH-LngTCP3-JSNcox1hI51XBWEqoeApKdfDJ
6o4szR71SIFCBERxCH9TyUxsFywWL3e-YnXMiP2J08eB8O4YwhYQEFqB8Q
Check a token
Curl

from previous example

curl -s -X POST -d
"token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTU1MjY1
OTczOCwiYXV0aG9yaXRpZXMiOlsiUk9MRV9BRE1JTiIsIlJPTEVfVVNFUiJdLCJqdGkiOiIwMmQ4MmU4
NS0xM2YwLTQ2NzgtOTc0ZC0xOGViMDYyMTVhNjUiLCJjbGllbnRfaWQiOiJjbGllbnRJZFBhc3N3b3Jk
Iiwic2NvcGUiOlsicmVhZCIsInVzZXJfaW5mbyJdfQ.SDg-BEzzonIVXfVBnnfq0oMbs_0rWVtFGAZzR
Hj7KPgaOXT3bUhQwPOgggZDO0lv2U1klwB94c8Cb6rErzd3yjJ8wcVcnFLO4KxrjYZZxdKVAz0CkMKqn
g4kQeQm_1UShsQXGLl48ezbjXyJn6mAl0oS4ExeiVsx_kYGEdqjyb5CiNaAzyx0J-J5jVDSJew1rj5Ei
Sybuy83PZwhluhxq0D2zPK1OSzqiezsd5kX5V8XI4MipDhaAbPYroL94banZTn9RmmAKZCAYVM-mmHbj
k8mF89fL9rKf9EUNhxOG6GE0MDqB3LLLcyQ6sYUmpqdP5Z94IkAN-FpC7k93_-RDw"
http://localhost:2002/auth/check_token

which gives the following example of result:

{
    "sub":"admin",
    "scope":["read","user_info"],
    "active":true,"exp":1552659738,
    "authorities":["ROLE_ADMIN","ROLE_USER"],
    "jti":"02d82e85-13f0-4678-974d-18eb06215a65",
    "client_id":"clientIdPassword"
}
Httpie

from previous example:

http --form POST http://localhost:2002/auth/check_token
token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTU1MjY2M
DAzOSwiYXV0aG9yaXRpZXMiOlsiUk9MRV9BRE1JTiIsIlJPTEVfVVNFUiJdLCJqdGkiOiI2MjQzMDliM
S03Yzg3LTRjZGMtODQ0My0wMTI0NTE1Zjg3ZjgiLCJjbGllbnRfaWQiOiJjbGllbnRJZFBhc3N3b3JkI
iwic2NvcGUiOlsicmVhZCIsInVzZXJfaW5mbyJdfQ.VO4OZL7ycqNez0cHzM5WPuklr0r6SAOkUdUV2q
Fa5Bd3PWx3DFHAHUxkfSX0-R4OO6iG2Zu7abzToAZNVLwk107LH_lWXOMQBriGx3d2aSgCf1yx_wI3lH
Dd8ST8fxV7uNeolzywYavSpMGfgz9GXLzmnyeuPH4oy7eyPk9BwWVi0d7a_0d-EfhE1T8eaiDfymzzNX
J4Bge8scPy-93HmWpqORtJaFq1qy4QgU28N2LgHFEEEWCSzfhYXH-LngTCP3-JSNcox1hI51XBWEqoeA
pKdfDJ6o4szR71SIFCBERxCH9TyUxsFywWL3e-YnXMiP2J08eB8O4YwhYQEFqB8Q

which gives the following example of result:

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json;charset=utf-8
Date: Fri, 15 Mar 2019 14:19:31 GMT
Expires: 0
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
transfer-encoding: chunked

{
    "active": true,
    "authorities": [
        "ROLE_ADMIN",
        "ROLE_USER"
    ],
    "client_id": "clientIdPassword",
    "exp": 1552660039,
    "jti": "624309b1-7c87-4cdc-8443-0124515f87f8",
    "scope": [
        "read",
        "user_info"
    ],
    "sub": "admin"
}

3.3.2. User creation

Setting automated user creation==. Creation user requires an user id. Given name and family name are optional.

name default mandatory? Description

operatorfabric.security.jwt.login-claim

sub

no

Jwt claim is used as an user login or id

operatorfabric.security.jwt.given-name-claim

given-name

no

Jwt claim is used to set the user’s given name

operatorfabric.security.jwt.family-name-claim

family-name

no

Jwt claim is used to set the user’s family name

3.3.3. Alternative way to manage groups

By default, Operator-Fabric manage groups through the user’s group. Another mode can be defined, the JWT mode. The groups come from the authentication token. The administrator of the authentication service has to set what claims define a group. In the Operator-Fabric configuration, the opfab administrator has to set properties to retrieve thoses groups.

name default mandatory? Description

operatorfabric.security.jwt.groups.mode

OPERATOR_FABRIC

no

Set the group mode, possible values JWT or OPERATOR_FABRIC

operatorfabric.security.jwt.groups.rolesClaim.rolesClaimStandard-claim.path

no

path in the JWT to retrieve the claim that defines a group

operatorfabric.security.jwt.groups.rolesClaim.rolesClaimStandardArray.path

no

path in the JWT to retrieve the claim that defines an array of groups

operatorfabric.security.jwt.groups.rolesClaim.rolesClaimStandardList.path

no

path in the JWT to retrieve the claim that defines a list of group

operatorfabric.security.jwt.groups.rolesClaim.rolesClaimStandardList.separator

no

set the separator value of the list of group

operatorfabric.security.jwt.groups.rolesClaim.rolesClaimCheckExistPath.path

no

path in the JWT to check if that path does exist, if it does, use the roleValue as a group

operatorfabric.security.jwt.groups.rolesClaim.rolesClaimCheckExistPath.roleValue

no

set the value of the group if the path exists

application.yml

operatorfabric:
  security:
    jwt:
      groups:
        mode: JWT # value possible JWT | OPERATOR_FABRIC
        rolesClaim:
          rolesClaimStandard:
            - path: "ATTR1"
            - path: "ATTR2"
          rolesClaimStandardArray:
            - path: "resource_access/opfab-client/roles"
          rolesClaimStandardList:
            - path: "roleFieldList"
              separator: ";"
          rolesClaimCheckExistPath:
            - path: "resource_access/AAA"
              roleValue: "roleAAA"
            - path: "resource_access/BBB"
              roleValue: "roleBBB"

JWT example

{
  "jti": "5ff87583-10bd-4946-8753-9d58171c8b7f",
  "exp": 1572979628,
  "nbf": 0,
  "iat": 1572961628,
  "iss": "http://localhost:89/auth/realms/dev",
  "aud": [
    "AAA",
    "BBB",
    "account"
  ],
  "sub": "example_user",
  "typ": "Bearer",
  "azp": "opfab-client",
  "auth_time": 0,
  "session_state": "960cbec4-fcb2-47f2-a155-975832e61300",
  "acr": "1",
  "realm_access": {
    "roles": [
      "offline_access",
      "uma_authorization"
    ]
  },
  "resource_access": {
    "AAA": {
      "roles": [
        "role_AAA"
      ]
    },
    "BBB": {
      "roles": [
        "role_BBB"
      ]
    },
    "opfab-client": {
      "roles": [
        "USER"
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "scope": "openid ATTR2 email ATTR1 profile roleFieldList",
  "email_verified": false,
  "name": "example_firtstname example_lastname",
  "ATTR2": "roleATTR2",
  "ATTR1": "roleATTR1",
  "preferred_username": "example_user",
  "given_name": "example_firtstname",
  "family_name": "example_lastname",
  "email": "example_user@mail.com",
  "roleFieldList": "roleA;roleB;roleC"
}

As the result, the group will be [ATTR1, ATTR2, roleA, roleB, roleC, USER, roleBBB, roleAAA]

3.4. Service-specific configuration

3.4.1. Actions Business service

OperatorFabric Actions Business service is a Spring Webflux application bootstrapped using SpringBoot.

In our spring micro service architecture this service depends on Eureka Registry.

Mandatory configuration, Profiles and default properties

The service has no mandatory configuration beside global configuration and usual bootstrap configuration.

For other configuration see:

Service specific properties
default properties

Note that you must provide a bootstrap file with a convenient registry configuration

bootstrap.yml

spring:
  application:
    name: actions
  cloud:
    config:
      name: actions
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true

bootstrap-docker.yml

spring:
  application:
    name: actions
  cloud:
    config:
      name: actions
      failFast: true
      retry:
        maxAttempts: 20
      discovery:
        service-id: config
        enabled: true
#  level.root: debug
eureka:
  client:
    registerWithEureka: true
    fetchRegistry: true
    registryFetchIntervalSeconds: 5
    service-url:
      defaultZone: 'http://${REGISTRY_HOST}:${REGISTRY_PORT}/eureka/'

bootstrap-dev.yml

spring:
  application:
    name: actions
  cloud:
    config:
      name: actions
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true
logging.level.root: debug
eureka:
  client:
    service-url:
      defaultZone: 'http://localhost:2001/eureka'

The bootstrap-docker.yml file is a replacement bootstrap file we use for our docker images configuration.

The bootstrap-dev.yml file is a replacement bootstrap file we use for our development environment

The above embedded configurations are the basic settings of the application:

  • it sets its service name

  • it sets the configuration name to use (which configuration file to retrieve)

  • it must set the registry service (example in bootstrap-docker.yml)

Sample development configuration
server:
  port: 2105
Sample docker image configuration
Specifying external configuration properties when launching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

See Set the Active Spring Profiles for specifying alternate profile.

Specifying configuration properties when launching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writing, you cannot specify an alternate profile at runActions. The default profiles activated are docker and native.

Available environment variables for docker image

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when launching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

3.4.2. Cards-Consultation Business service

OperatorFabric Cards-Consultation Business service is a Spring Webflux application bootstrapped using SpringBoot.

In our spring micro service architecture this service depends on Eureka Registry.

Mandatory configuration, Profiles and default properties

The service has no mandatory configuration beside global configuration and usual bootstrap configuration.

For other configuration see:

Service specific properties
default properties

Note that you must provide a bootstrap file with a convenient registry configuration

bootstrap.yml

spring:
  application:
    name: cards-consultation
  cloud:
    config:
      name: cards-consultation
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true

bootstrap-docker.yml

spring:
  application:
    name: cards-consultation
  cloud:
    config:
      name: cards-consultation
      failFast: true
      retry:
        maxAttempts: 20
      discovery:
        service-id: config
        enabled: true
#  level.root: debug
eureka:
  client:
    registerWithEureka: true
    fetchRegistry: true
    registryFetchIntervalSeconds: 5
    service-url:
      defaultZone: 'http://${REGISTRY_HOST}:${REGISTRY_PORT}/eureka/'

bootstrap-dev.yml

spring:
  application:
    name: cards-consultation
  cloud:
    config:
      name: cards-consultation
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true
#  level.root: debug
eureka:
  client:
    service-url:
      defaultZone: 'http://localhost:2001/eureka'

The bootstrap-docker.yml file is a replacement bootstrap file we use for our docker images configuration.

The bootstrap-dev.yml file is a replacement bootstrap file we use for our development environment

The above embedded configurations are the basic settings of the application:

  • it sets its service name

  • it sets the configuration name to use (which configuration file to retrieve)

  • it must set the registry service (example in bootstrap-docker.yml)

Sample development configuration
server:
  port: 2104
logging.level.root: DEBUG
Sample docker image configuration
Specifying external configuration properties when launching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

See Set the Active Spring Profiles for specifying alternate profile.

Specifying configuration properties when launching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writing, you cannot specify an alternate profile at runCards-Consultation. The default profiles activated are docker and native.

Available environment variables for docker image

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when launching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

3.4.3. Cards-Publication Business service

OperatorFabric Cards-Publication Business service is a Spring Webflux application bootstrapped using SpringBoot.

In our spring micro service architecture this service depends on Eureka Registry.

Mandatory configuration, Profiles and default properties

The service has no mandatory configuration beside global configuration and usual bootstrap configuration.

For other configuration see:

Service specific properties
name default mandatory? Description

operatorfabric.card-write.window.size

1000

no

card input window size to fill before flush

operatorfabric.card-write.window.timeout

500

no

card input window millis wait time before flush

operatorfabric.card-notification.window.size

100

no

card notification window size to fill before flush

operatorfabric.card-notification.window.timeout

1000

no

card notification window millis wait time before flush
default properties

Note that you must provide a bootstrap file with a convenient registry configuration

bootstrap.yml

spring:
  application:
    name: cards-publication
  cloud:
    config:
      name: cards-publication
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true

bootstrap-docker.yml

spring:
  application:
    name: cards-publication
  cloud:
    config:
      name: cards-publication
      failFast: true
      retry:
        maxAttempts: 20
      discovery:
        service-id: config
        enabled: true
#  level.root: debug
eureka:
  client:
    registerWithEureka: true
    fetchRegistry: true
    registryFetchIntervalSeconds: 5
    service-url:
      defaultZone: 'http://${REGISTRY_HOST}:${REGISTRY_PORT}/eureka/'

bootstrap-dev.yml

spring:
  application:
    name: cards-publication
  cloud:
    config:
      name: cards-publication
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true
eureka:
  client:
    service-url:
      defaultZone: 'http://localhost:2001/eureka'

The bootstrap-docker.yml file is a replacement bootstrap file we use for our docker images configuration.

The bootstrap-dev.yml file is a replacement bootstrap file we use for our development environment

The above embedded configurations are the basic settings of the application:

  • it sets its service name

  • it sets the configuration name to use (which configuration file to retrieve)

  • it must set the registry service (example in bootstrap-docker.yml)

Sample development configuration
server:
  port: 2102
Sample docker image configuration
Specifying external configuration properties when launching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

See Set the Active Spring Profiles for specifying alternate profile.

Specifying configuration properties when launching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writing, you cannot specify an alternate profile at runCards-Publication. The default profiles activated are docker and native.

Available environment variables for docker image

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when launching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

3.4.4. Cloud Gateway service

OperatorFabric Client Gateway service is a Spring Cloud Gateway application bootstrapped using SpringBoot.

In our spring micro service architecture the gateway service depends on Eureka Registry.

Mandatory configuration, Profiles and default properties

To get a working gateway service, there a few mandatory configuration properties:

In a configuration service client-gateway.yml file

  • The application must set up a route to the oauth server

    • /auth/token(?<path>.*): must match the oauth2 token entry point;

    • /auth/code/(?<params>.*): must match the auth entry point with specific query parameters like response_type=code&client_id=[client id]&${params};

    • /auth/check_token: must match token introspection entry point

  • The application must add request header for each request:

    • AddRequestHeader: Authorization, Basic: followed, separated with a space, by the OAuth2 client-id and the OAuth2 client-secret encoded in base64.

  • The application may set up CORS rules if api are to be accessed from browser outside of the deployment domain

Configuration example of the filters, for the docker dev keycloak:

spring.cloud.gateway.routes[0].filters:
        - RewritePath=/auth/token(?<path>.*), /auth/realms/dev/protocol/openid-connect/token$\{path}
        - RewritePath=/auth/code/(?<params>.*), /auth/realms/dev/protocol/openid-connect/auth?response_type=code&client_id=opfab-client&$\{params}
        - RewritePath=/auth/check_token, /auth/realms/dev/protocol/openid-connect/token/introspect
        - AddRequestHeader=Authorization, Basic b3BmYWItY2xpZW50Om9wZmFiLWtleWNsb2FrLXNlY3JldA==

where: - spring.cloud.gateway.routes.uri: is your keycloak instance - spring.cloud.gateway.routes[0] is the routes with id equals to auth; - /realms/dev: is the keycloak realm where opfab-client is defined. - b3BmYWItY2xpZW50Om9wZmFiLWtleWNsb2FrLXNlY3JldA==: is the base64 encoded string of opfab-client:opfab-keycloak-secret with opfab-client as client-id and opfab-keycloak-secret its client secret.

For other configuration see spring cloud gateway documentation.

Service specific properties
name default mandatory? Description

operatorfabric.gateway.configs

null

no

an array of string for each allowed config entries
default properties

Note that you must provide a bootstrap file with a convenient registry configuration

bootstrap.yml

spring:
  application:
    name: client-gateway
  cloud:
    config:
      name: client-gateway
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true

bootstrap-docker.yml

spring:
  application:
    name: client-gateway
  cloud:
    config:
      name: client-gateway
      failFast: true
      retry:
        maxAttempts: 20
      discovery:
        service-id: config
        enabled: true
eureka:
  client:
    registerWithEureka: true
    fetchRegistry: true
    registryFetchIntervalSeconds: 5
    service-url:
      defaultZone: 'http://${REGISTRY_HOST}:${REGISTRY_PORT}/eureka/'

bootstrap-dev.yml

spring:
  application:
    name: client-gateway
  cloud:
    config:
      name: client-gateway
      failFast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true
eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: 'http://localhost:2001/eureka/'

The bootstrap-docker.yml file is a replacement bootstrap file we use for our docker images configuration.

The bootstrap-dev.yml file is a replacement bootstrap file we use for our development environment

The above embedded configurations are the basic settings of the application:

  • it sets its service name

  • it sets the configuration name to use (which configuration file to retrieve)

  • it must set the registry service (example in bootstrap-docker.yml)

Sample developpement configuration
server:
  port: 2002
spring:
  cloud:
    gateway:
      routes:
      - id: auth
        uri: http://localhost:89
        predicates:
        - Path=/auth/**
        filters:
        - RewritePath=/auth/token(?<path>.*), /auth/realms/dev/protocol/openid-connect/token$\{path}
        - RewritePath=/auth/code/(?<params>.*), /auth/realms/dev/protocol/openid-connect/auth?response_type=code&client_id=opfab-client&$\{params}
        - RewritePath=/auth/check_token, /auth/realms/dev/protocol/openid-connect/token/introspect
        - AddRequestHeader=Authorization, Basic b3BmYWItY2xpZW50Om9wZmFiLWtleWNsb2FrLXNlY3JldA==
# WARNING : THIS CORS CONFIGURATION SHOULD NOT BE USED IN PRODUCTION
      globalcors:
        corsConfigurations:
          '[/**]':
            allowedOrigins: "*"
            allowedMethods: "*"
            allowedHeaders: "Authorization, Content-Type"
operatorfabric.gateway.configs:
  - web-ui.json
#logging.level.root: debug
Sample docker image configuration
spring:
  cloud:
    gateway:
      routes:
      - id: auth
        uri: http://keycloak:8080
        predicates:
        - Path=/auth/**
        filters:
        - RewritePath=/auth/token(?<path>.*), /auth/realms/dev/protocol/openid-connect/token$\{path}
        - RewritePath=/auth/code/(?<params>.*), /auth/realms/dev/protocol/openid-connect/auth?response_type=code&client_id=opfab-client&$\{params}
        - RewritePath=/auth/check_token, /auth/realms/dev/protocol/openid-connect/token/introspect
        - AddRequestHeader=Authorization, Basic b3BmYWItY2xpZW50Om9wZmFiLWtleWNsb2FrLXNlY3JldA==
# WARNING : THIS CORS CONFIGURATION SHOULD NOT BE USED IN PRODUCTION
        globalcors:
         corsConfigurations:
          '[/**]':
            allowedOrigins: "*"
            allowedMethods: "*"
            allowedHeaders: "Authorization, Content-Type"
operatorfabric.gateway.configs:
  - web-ui.json
Specifying external configuration properties when lauching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

See Set the Active Spring Profiles for specifying alternate profile.

Specifying configuration properties when lauching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writting, you cannot specify an alternate profile at runtime. The default profiles activated are docker and native.

Available environment variables for docker image

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when lauching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

3.4.5. Cloud Configuration service

OperatorFabric Configuration service is a Spring Cloud Config application bootstrapped using SpringBoot.

In our spring micro service architecture Configuration instances are the first services to bootstrap, thus they are configured in a specific way contrary to other services.

Mandatory configuration, Profiles and default properties

To get a working configuration service, there a few mandatory configuration properties:

  • in a bootstrap file:

    • The application must have a set name (spring.application.name)

  • in an application property file

    • The application must have a configured rabbitmq service for configuration change notification (spring.rabbitmq.*)

    • The application must have a configured eureka server (eureka.client.*)

For other configuration see spring cloud config documentation.

Note that it is mandatory to define an environment repository for the service. Dev and Docker profile uses a file system backend which is not suitable for production and redundancy. You should prefer the usage of Git or Vault for production.

default properties

It is preferable not to change the following bootstrap.yml file.

bootstrap.yml

spring:
  application:
    name: config

application.yml

management:
  endpoints:
    web:
      exposure:
        include: '*'

The above embedded configurations are the basic settings of the application: * it sets its name as a service (config) * it exposes management endpoints

dev profile

dev is the profile we use internally for developpement we make it available for external developers so that they don’t need extensive configuration to get a jar working in the development environment

server:
  port: 2000
spring:
#  level.root: debug
  profiles:
    active: [native,dev]
  cloud:
    config:
      server:
        native:
          search-locations:
           - file:./build/dev-data/dev-configurations
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
eureka:
  client:
    region: default
    service-url:
      defaultZone: http://localhost:2001/eureka
    registryFetchIntervalSeconds: 5

  • it exposes the service on port 2000 (defaults to 8080)

  • it activates the dev and native profile (native is mandatory for serving config from file system)

  • it configures rabbitmq for dispatching config change messages to other services

  • it configures registration in eureka discovery service

docker profile

docker is the profile we use in our docker images

spring:
  profiles:
    active: [native]
  cloud:
    config:
      server:
        native:
          search-locations:
           - file:/service-config
  rabbitmq:
    host: ${RABBITMQ_HOST}
    port: ${RABBITMQ_PORT}
    username: ${RABBITMQ_USER}
    password: ${RABBITMQ_PASSWORD}
eureka:
  client:
    region: default
    service-url:
      defaultZone: http://${REGISTRY_HOST}:${REGISTRY_PORT}/eureka
    registryFetchIntervalSeconds: 5

  • it activates the native profile (native is mandatory for serving config from file system)

  • it configures rabbitmq for dispatching config change messages to other services

  • it configures registration in eureka discovery service

Specifying external configuration properties when lauching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

Seehttps://docs.spring.io/spring-boot/docs/2.1.2.RELEASE//reference/htmlsingle/#howto-set-active-spring-profiles[Set the Active Spring Profiles] for specifying alternate profile.

Specifying configuration properties when lauching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writting, you cannot specify an alternate profile at runtime. The default profiles activated are docker and native.

Available environment variables for docker image

  • RABBITMQ_HOST: Rabbitmq host name

  • RABBITMQ_PORT: Rabbitmq host port

  • RABBITMQ_USER: Rabbitmq user name used for authentication service

  • RABBITMQ_PASSWORD: Rabbitmq user password used for authentication service

  • REGISTRY_HOST: Registry (eureka) host name

  • REGISTRY_PORT: Registry (eureka) host port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when lauching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • RABBITMQ_HOST: Rabbitmq host name

  • RABBITMQ_PORT: Rabbitmq host port

  • RABBITMQ_USER: Rabbitmq user name used for authentication service

  • RABBITMQ_PASSWORD: Rabbitmq user password used for authentication service

  • REGISTRY_HOST: Registry (eureka) host name

  • REGISTRY_PORT: Registry (eureka) host port

  • JAVA_OPTIONS: Additional java options

3.4.6. Cloud Registry service

OperatorFabric Registry service is a Spring Eureka application bootstrapped using SpringBoot.

In our spring micro service architecture Eureka Registry instances are the second services to bootstrap, its configuration relies on the Cloud Configuration service.

Mandatory configuration, Profiles and default properties

To get a working registry service, there a few mandatory configuration properties:

  • In a bootstrap file

    • The application must have a set name (spring.application.name)

    • The application must have a set configuration name (spring.cloud.config.name)

    • The application must have a set configuration server (spring.cloud.config.uri)

    • The application may have a retry/failfast configuration for config access (spring.cloud.config.failfast, spring.cloud.config.retry)

  • In a configuration service registry.yml file

    • The application may deactivate eureka registration to avoid self registration (deactivated by default in internal application.yml file)

    • The application must set the Eureka instance hostname (eureka.instance.hostname)

    • The application must set the Eureka default zone (eureka.lient.serviceUrl.defaultZone)

For other configuration see spring cloud netflix documentation.

default properties

It is preferable not to change the following bootstrap.yml file.

bootstrap.yml

spring:
  application:
    name: registry
  cloud.config:
    name: registry
    fail-fast: true

bootstrap-docker.yml

spring:
  application:
    name: registry
  cloud.config:
    name: registry
    uri: http://${CONFIG_HOST}:${CONFIG_PORT}
    failFast: true
    retry:
      maxAttempts: 50

bootstrap-dev.yml

spring:
  application:
    name: registry
  cloud.config:
    name: registry
    uri: http://localhost:2000

application.yml

eureka:
  client:
    register-with-eureka: false
    fetch-registry: false

The bootstrap-docker.yml file is a replacement bootstrap file we use for our docker images configuration.

The bootstrap-dev.yml file is a replacement bootstrap file we use for our developpement environment

The above embedded configurations are the basic settings of the application: * it sets its name as a service (config) * it sets the configuration name to use (which configuration file to retrieve) * it must set the configuration service (example in bootstrap-docker.yml)

dev profile

dev is the profile we use internally for developpement we make it available for external developers so that they don’t need extensive configuration to get a jar working in the development environment

server:
  port: 2001
eureka:
  instance.hostname: localhost
  client.serviceUrl.defaultZone: http://localhost:2001/eureka/
Sample development configuration
server:
  port: 2001
eureka:
  instance.hostname: localhost
  client.serviceUrl.defaultZone: http://localhost:2001/eureka/
Sample docker image configuration
eureka:
  instance.hostname: registry
  client:
    serviceUrl.defaultZone: http://registry:8080/eureka/
    registerWithEureka: false
    fetchRegistry: false
    server:
      waitTimeInMsWhenSyncEmpty: 0
Specifying external configuration properties when lauching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

See Set the Active Spring Profiles for specifying alternate profile.

Specifying configuration properties when lauching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writting, you cannot specify an alternate profile at runtime. The default profiles activated are docker and native.

Available environment variables for docker image

  • CONFIG_HOST: Configuration service host

  • CONFIG_PORT: Configuration service port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when lauching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • CONFIG_HOST: Configuration service host

  • CONFIG_PORT: Configuration service port

  • JAVA_OPTIONS: Additional java options

3.4.7. Thirds Business service

OperatorFabric Thirds Business service is a Spring MVC application bootstrapped using SpringBoot.

In our spring micro service architecture this service depends on Eureka Registry.

Mandatory configuration, Profiles and default properties

The service has no mandatory configuration beside global configuration and usual bootstrap configuration.

For other configuration see:

Service specific properties
name default mandatory? Description

operatorfabric.thirds.storage.path

null

no

File path to data storage folder
default properties

Note that you must provide a bootstrap file with a convenient registry configuration

bootstrap.yml

spring:
  application:
    name: thirds
  cloud:
    config:
      name: thirds
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true

bootstrap-docker.yml

spring:
  application:
    name: thirds
  cloud:
    config:
      name: thirds
      failFast: true
      retry:
        maxAttempts: 20
      discovery:
        service-id: config
        enabled: true
#  level.root: debug
eureka:
  client:
    registerWithEureka: true
    fetchRegistry: true
    registryFetchIntervalSeconds: 5
    service-url:
      defaultZone: 'http://${REGISTRY_HOST}:${REGISTRY_PORT}/eureka/'

bootstrap-dev.yml

spring:
  application:
    name: thirds
  cloud:
    config:
      name: thirds
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true
eureka:
  client:
    service-url:
      defaultZone: 'http://localhost:2001/eureka'

The bootstrap-docker.yml file is a replacement bootstrap file we use for our docker images configuration.

The bootstrap-dev.yml file is a replacement bootstrap file we use for our development environment

The above embedded configurations are the basic settings of the application:

  • it sets its service name

  • it sets the configuration name to use (which configuration file to retrieve)

  • it must set the registry service (example in bootstrap-docker.yml)

Sample development configuration
server:
  port: 2100
operatorfabric.thirds:
  storage:
    path: "./services/core/thirds/build/docker-volume/thirds-storage"
Sample docker image configuration
operatorfabric.thirds:
  storage:
    path: "/thirds-storage"
Specifying external configuration properties when launching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

See Set the Active Spring Profiles for specifying alternate profile.

Specifying configuration properties when launching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writing, you cannot specify an alternate profile at runThirds. The default profiles activated are docker and native.

Available environment variables for docker image

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when launching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

3.4.8. Users Business service

OperatorFabric Users Business service is a Spring MVC application bootstrapped using SpringBoot.

In our spring micro service architecture this service depends on Eureka Registry.

Mandatory configuration, Profiles and default properties

The service has no mandatory configuration beside global configuration and usual bootstrap configuration.

For other configuration see:

Service specific properties
name default mandatory? Description

operatorfabric.users.default.users

null

no

Array of user objects to create upon startup if they don’t exist

operatorfabric.users.default.user-settings

null

no

Array of user settings objects to create upon startup if they don’t exist

operatorfabric.users.default.groups

null

no

Array of group objects to create upon startup if they don’t exist
default properties

Note that you must provide a bootstrap file with a convenient registry configuration

bootstrap.yml

spring:
  application:
    name: users
  cloud:
    config:
      name: users
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true

bootstrap-docker.yml

spring:
  application:
    name: users
  cloud:
    config:
      name: users
      failFast: true
      retry:
        maxAttempts: 20
      discovery:
        service-id: config
        enabled: true
#  level.root: debug
eureka:
  client:
    registerWithEureka: true
    fetchRegistry: true
    registryFetchIntervalSeconds: 5
    service-url:
      defaultZone: 'http://${REGISTRY_HOST}:${REGISTRY_PORT}/eureka/'

bootstrap-dev.yml

spring:
  application:
    name: users
  cloud:
    config:
      name: users
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true
eureka:
  client:
    service-url:
      defaultZone: 'http://localhost:2001/eureka'

The bootstrap-docker.yml file is a replacement bootstrap file we use for our docker images configuration.

The bootstrap-dev.yml file is a replacement bootstrap file we use for our development environment

The above embedded configurations are the basic settings of the application:

  • it sets its service name

  • it sets the configuration name to use (which configuration file to retrieve)

  • it must set the registry service (example in bootstrap-docker.yml)

Sample development configuration
server:
  port: 2103
operatorfabric.users.default:
  users:
    - login: admin
      groups: ["ADMIN"]
    - login: rte-operator
      groups: ["RTE","ADMIN","TRANS"]
    - login: tso1-operator
      groups: ["TSO1","TRANS"]
    - login: tso2-operator
      groups: ["TSO2", "TRANS"]
  groups:
    - name: ADMIN
      description: The admin group
    - name: RTE
      description: RTE TSO Group
    - name: TSO1
      description: TSO 1 Group
    - name: TSO2
      description: TSO 2 Group
    - name: TRANS
      description: Transnationnal Group
  user-settings:
    - login: rte-operator
      description: Da Operator Rulez
#logging.level.root: DEBUG
Sample docker image configuration
operatorfabric.users.default:
  users:
  - login: admin
    groups: ["ADMIN"]
  - login: rte-operator
    groups: ["RTE","ADMIN","TRANS"]
  - login: tso1-operator
    groups: ["TSO1","TRANS"]
  - login: tso2-operator
    groups: ["TSO2", "TRANS"]
  groups:
  - name: ADMIN
    description: The admin group
  - name: RTE
    description: RTE TSO Group
  - name: TSO1
    description: TSO 1 Group
  - name: TSO2
    description: TSO 2 Group
  - name: TRANS
    description: Transnationnal Group
Specifying external configuration properties when launching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

See Set the Active Spring Profiles for specifying alternate profile.

Specifying configuration properties when launching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writing, you cannot specify an alternate profile at runUsers. The default profiles activated are docker and native.

Available environment variables for docker image

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when launching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

3.4.9. Web UI

OperatorFabric Web UI service is a Spring MVC application bootstrapped using SpringBoot. Its sole purpose is to serve the Angular SPA to browsers.

In our spring micro service architecture this service depends on Eureka Registry.

Mandatory configuration, Profiles and default properties

The service has no mandatory configuration beside global configuration and usual bootstrap configuration.

For other configuration see: NONE * Spring Boot documentation. * Spring MVC documentation.

Service specific properties
name default mandatory? Description

operatorfabric.security.realm-url

yes

The realm name in keycloak server settings page. This is used for the log out process to know which realm should be affected.

operatorfabric.security.provider-url

yes

The keycloak server instance

operatorfabric.security.logout-url

yes

The keycloak logout URL. Is a composition of: - Your keycloak instance and the auth keyword (ex: www.keycloakurl.com/auth), but we also support domains without auth (ex: www.keycloakurl.com/customPath) - The realm name (Ex: dev) - The redirect URL (redirect_uri): The redirect URL after success authentification

operatorfabric.security.oauth2.flow.mode

PASSWORD

no

authentication mode, awailable options:

  • CODE: Authorization Code Flow;

  • PASSWORD: Direct Password Flow (fallback);

  • IMPLICIT: Implicit Flow.

operatorfabric.security.oauth2.flow.provider

null

no

provider name to display on log in button

operatorfabric.security.oauth2.flow.delegate-url

null

no

Url to redirect the browser to for authentication. Mandatory with:

  • CODE flow: must be the url with protocol choice and version as query parameters;

  • IMPLICIT flow: must be the url part before .well-known/openid-configuration (for example in dev configuration it’s localhost:89/auth/realms/dev).

operatorfabric.feed.subscription.timeout

60000

no

Milliseconds between card subscription renewal

operatorfabric.feed.card.time.display

BUSINESS

no

card time display mode in the feed. Values :

  • BUSINESS: displays card with entire business period. It the fallback if the set value is none of the values listed here;

  • BUSINESS_START: displays card with business start date;

  • PUBLICATION: displays card with publication date;

  • LTTD: displays card with lttd date;

  • NONE: nothing displayed.

operatorfabric.feed.timeline.hide

false

no

If set to true, the time line is not loaded in the feed screen

operatorfabric.feed.timeFilter.followClockTick

false

no

If set to true, the time filter on the feed will shift to reflect elapsed time

operatorfabric.feed.notify

false

no

If set to true, new cards are notified in the OS through web-push notifications

operatorfabric.i18n.supported.locales

no

List of supported locales (Only fr and en so far)

operatorfabric.i10n.supported.time-zones

no

List of supported time zones, for instance 'Europe/Paris'. Values should be taken from the TZ database.

operatorfabric.navbar.thirdmenus.type

BOTH

no

Defines how thirdparty menu links are displayed in the navigation bar and how they open. Possible values:

  • TAB: Only a text link is displayed, and clicking it opens the link in a new tab.

  • IFRAME: Only a text link is displayed, and clicking it opens the link in an iframe in the main content zone below the navigation bar.

  • BOTH: Both a text link and a little arrow icon are displayed. Clicking the text link opens the link in an iframe while clicking the icon opens in a new tab.

operatorfabric.time.pulse

5000

no

Duration between two ticks of the internal state of the User Interface

operatorfabric.archive.filters.page.size

no

The page size of archive filters

operatorfabric.archive.filters.page.first

no

The first page start of archiving module

operatorfabric.archive.filters.process.list

no

List of processes to choose from in the corresponding filter in archives

operatorfabric.archive.filters.tags.list

no

List of tags to choose from in the corresponding filter in archives

operatorfabric.settings.tags.hide

no

Control if you want to show or hide the tags filter in settings and feed page

operatorfabric.settings.infos.disable

no

Control if we want to disable/enable editing user email, description in the settings page

operatorfabric.settings.infos.email

false

no

Control if we want to hide(true) or display(false or not specified) the user email in the settings page

operatorfabric.settings.infos.description

false

no

Control if we want to hide(true) or display(false or not specified) the user description in the settings page

operatorfabric.settings.infos.language

false

no

Control if we want to hide(true) or display(false or not specified) the language in the settings page

operatorfabric.settings.infos.timezone

false

no

Control if we want to hide(true) or display(false or not specified) the timezone in the settings page

operatorfabric.settings.infos.timeformat

false

no

Control if we want to hide(true) or display(false or not specified) the timeformat in the settings page

operatorfabric.settings.infos.dateformat

false

no

Control if we want to hide(true) or display(false or not specified) the dateformat in the settings page

operatorfabric.settings.infos.datetimeformat

false

no

Control if we want to hide(true) or display(false or not specified) the datetimeformat in the settings page

operatorfabric.settings.infos.tags

false

no

Control if we want to hide(true) or display(false or not specified) the tags in the settings page

operatorfabric.settings.about

operatorfabric:
name: 'OperatorFabric'
version: ${currentVersion}
rank: 0

no

Declares application names and their version into web-ui about section.
Each entry is a free key value followed by its name (a string of characters), its version(a string of characters) and its rank of declaration(a number) cf the default value where the declared key is operatorfabric'.
For this default value, with 'OperatorFabric' as name and 0 as rank, the value of ${currentVersion} is the version of the current release. 0.16.1-RELEASE for example.

operatorfabric.logo.base64

medium OperatorFabric icon

no

The encoding result of converting the svg logo to Base64, use this online tool to encode your svg. If it is not set, a medium (32px) OperatorFabric icon is displayed.

operatorfabric.logo.height

32

no

The height of the logo (in px) (only taken into account if operatorfabric.logo.base64 is set).

operatorfabric.logo.width

150

no

The width of the logo (in px) (only taken into account if operatorfabric.logo.base64 is set).

operatorfabric.logo.limitSize

true

no

If it is true, the height limit is 32(px) and the width limit is 200(px), it means that if the height is over than 32, it will be set to 32, if the width is over than 200, it is set to 200. If it is false, no limit restriction for the height and the width.

operatorfabric.title

OperatorFabric

no

Title of the application, displayed on the browser

User Settings default values

name

default

mandatory?

Description

operatorfabric.settings.timeZone

no

Default user time zone for users (use

operatorfabric.settings.timeFormat

LT

no

Default user time format (moment)

operatorfabric.settings.dateFormat

LL

no

Default user date format (moment)

operatorfabric.settings.dateTimeFormat

LL LT

no

Default user date format (moment)

operatorfabric.settings.locale

en

no

Default user locale (use en if not set)

operatorfabric.settings.default-tags

no

Default user list of filtered in tags

operatorfabric.settings.timeLineDefaultClusteringFormats.dateInsideTooltipsWeek

no

operatorfabric.settings.timeLineDefaultClusteringFormats.dateInsideTooltipsWeek

ddd DD MMM HH

Default format use on date inside tooltips for time’s unit lower than hour

operatorfabric.settings.timeLineDefaultClusteringFormats.dateInsideTooltipsMonth

ddd DD MMM YYYY

Default format use on date inside tooltips for other case

operatorfabric.settings.timeLineDefaultClusteringFormats.dateOnDay

ddd DD MMM

Default format use for display a day and month informations with day name, number, and month

operatorfabric.settings.timeLineDefaultClusteringFormats.dateOnWeek

DD/MM/YY

Default format use for display a week information with day number, month number and two last year’s number

operatorfabric.settings.timeLineDefaultClusteringFormats.dateOnMonth

MMM YY

Default format use for display a month information with month name and two last year’s number

operatorfabric.settings.timeLineDefaultClusteringFormats.dateOnYear

YYYY

Default format use for display a year information

operatorfabric.settings.timeLineDefaultClusteringFormats.titleDateInsideTooltips

DD/MM

Default format use on first part of title inside tooltips showing day number and month number of its date

operatorfabric.settings.timeLineDefaultClusteringFormats.titleHourInsideTooltips

HH:mm

Default format use on second part of title inside tooltips showing hours and minutes of its date

operatorfabric.settings.timeLineDefaultClusteringFormats.dateOnDayNewYear

DD MMM YY

Default format use for display first year’s day on a day configuration display day number, month name and two last year’s number

operatorfabric.settings.timeLineDefaultClusteringFormats.realTimeBarFormat

DD/MM/YY HH:mm

Default format use on real time bar date, show minutes, hours, day number, month number and two last year’s number

operatorfabric.settings.timeLineDefaultClusteringFormats.dateSimplifliedOnDayNewYear

D MMM YY

Default format use on date configuration for first year’s day, show simplified day number, month name and last two year’s number

operatorfabric.settings.timeLineDefaultClusteringFormats.dateSimplifliedOnDay

D MMM

Default format use on date configuration, show simplified day number and month name

operatorfabric.settings.timeLineDefaultClusteringFormats.hoursOnly

HH

Default format for show only hours

operatorfabric.settings.timeLineDefaultClusteringFormats.minutesOnly

mm

Default format for show only minutes

operatorfabric.settings.timeLineDefaultClusteringFormats.secondedsOnly

ss

Default format for show only seconds

operatorfabric.settings.timeLineDefaultClusteringFormats.weekNumberOnly

ww

Default format for show only week number
default properties

Note that you must provide a bootstrap file with a convenient registry configuration

bootstrap.yml

spring:
  application:
    name: web-ui
  cloud:
    config:
      name: web-ui
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true

bootstrap-docker.yml

spring:
  application:
    name: web-ui
  cloud:
    config:
      name: web-ui
      failFast: true
      retry:
        maxAttempts: 20
      discovery:
        service-id: config
        enabled: true
#  level.root: debug
eureka:
  client:
    registerWithEureka: true
    fetchRegistry: true
    registryFetchIntervalSeconds: 5
    service-url:
      defaultZone: 'http://${REGISTRY_HOST}:${REGISTRY_PORT}/eureka/'

bootstrap-dev.yml

spring:
  application:
    name: web-ui
  cloud:
    config:
      name: web-ui
      fail-fast: true
      retry:
        max-attempts: 20
      discovery:
        service-id: config
        enabled: true
eureka:
  client:
    service-url:
      defaultZone: 'http://localhost:2001/eureka'

The bootstrap-docker.yml file is a replacement bootstrap file we use for our docker images configuration.

The bootstrap-dev.yml file is a replacement bootstrap file we use for our development environment

The above embedded configurations are the basic settings of the application:

  • it sets its service name

  • it sets the configuration name to use (which configuration file to retrieve)

  • it must set the registry service (example in bootstrap-docker.yml)

Sample development configuration
server:
  port: 2200
operatorfabric:
  security:
    provider-url: http://localhost:89
    provider-realm: dev
    logout-url: ${operatorfabric.security.provider-url}/auth/realms/${operatorfabric.security.provider-realm}/protocol/openid-connect/logout?redirect_uri=http://localhost:2002/ui/
    oauth2:
      flow:
        mode: CODE
        provider: Opfab Keycloak
        delagate-url: ${operatorfabric.security.provider-url}/auth/realms/${operatorfabric.security.provider-realm}/protocol/openid-connect/auth?response_type=code&client_id=opfab-client
  feed:
    subscription:
      timeout: 600000
    card:
      time:
        display: BUSINESS
    timeline:
      domains:
        - "TR"
        - "J"
        - "7D"
        - "W"
        - "M"
        - "Y"
    notify: false
  archive:
    filters:
      page.size:
        - "10"
      page.first:
        - "0"
      publisher.list:
        - value: "TEST"
          label: "Test Publisher"
        - value: "TEST2"
          label: "Test Publisher 2"
      process.list:
            - process
            - someOtherProcess
      tags.list:
        - value: "tag1"
          label: "Label for tag 1"
        - value: "tag2"
          label: "Label for tag 2"
  i10n.supported.time-zones:
    - value: "Europe/Paris"
      label: "Headquarters timezone"
    - value: "Australia/Melbourne"
      label: "Down Under"
    - Europe/London
    - Europe/Dublin
    - Europe/Brussel
    - Europe/Berlin
    - Europe/Rome
    - Europe/Madrid
    - Europe/Lisbon
    - Europe/Amsterdam
    - Europe/Athens
    - Pacific/Samoa
  i18n.supported.locales:
    - en
    - fr
  settings:
    locale: en
    infos:
      description: true
    about:
      firstapplication:
        name: First application
        version: v12.34.56
        rank: 1
      keycloack:
        name: Keycloak
        version: 6.0.1
        rank: 2
      lastapplication:
          name: Wonderful Solution
          version: 0.1.2-RELEASE
  time:
    pulse: 5000
Sample docker image configuration
server:
  port: 2200
operatorfabric:
  security:
    provider-url: http://localhost:89
    provider-realm: dev
    logout-url: ${operatorfabric.security.provider-url}/auth/realms/${operatorfabric.security.provider-realm}/protocol/openid-connect/logout?redirect_uri=http://localhost:2002/ui/
    oauth2:
      flow:
        mode: CODE
        provider: Opfab Keycloak
        delagate-url: ${operatorfabric.security.provider-url}/auth/realms/${operatorfabric.security.provider-realm}/protocol/openid-connect/auth?response_type=code&client_id=opfab-client
  feed:
    subscription:
      timeout: 600000
    card:
      time:
        display: BUSINESS
    timeline:
      domains:
        - "TR"
        - "J"
        - "7D"
        - "W"
        - "M"
        - "Y"
    notify: false
  archive:
    filters:
      page.size:
        - "10"
      page.first:
        - "0"
      publisher.list:
        - value: "TEST"
          label: "Test Publisher"
        - value: "TEST2"
          label: "Test Publisher 2"
      process.list:
            - process
            - someOtherProcess
      tags.list:
        - value: "tag1"
          label: "Label for tag 1"
        - value: "tag2"
          label: "Label for tag 2"
  i10n.supported.time-zones:
    - value: "Europe/Paris"
      label: "Headquarters timezone"
    - value: "Australia/Melbourne"
      label: "Down Under"
    - Europe/London
    - Europe/Dublin
    - Europe/Brussel
    - Europe/Berlin
    - Europe/Rome
    - Europe/Madrid
    - Europe/Lisbon
    - Europe/Amsterdam
    - Europe/Athens
    - Pacific/Samoa
  i18n.supported.locales:
    - en
    - fr
  settings:
    locale: en
    infos:
      description: true
    about:
      firstapplication:
        name: First application
        version: v12.34.56
        rank: 1
      keycloack:
        name: Keycloak
        version: 6.0.1
        rank: 2
      lastapplication:
          name: Wonderful Solution
          version: 0.1.2-RELEASE
  time:
    pulse: 5000
Specifying external configuration properties when lauching a jar file

See Application Property Files on how to setup an external spring properties or yml file.

See Set the Active Spring Profiles for specifying alternate profile.

Specifying configuration properties when lauching a docker image

Our docker image expects optional property file to be stored in the container /service-config folder. You can bind so docker volume to this path to make properties or yml available.

At time of writing, you cannot specify an alternate profile at runCards-Publication. The default profiles activated are docker and native.

Available environment variables for docker image

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

Specifying configuration properties when lauching on Kubernetes

In progress

Available environment variables when launching on Kubernetes

  • REGISTRY_HOST: Registry service host

  • REGISTRY_PORT: Registry service port

  • JAVA_OPTIONS: Additional java options

3.5. Users and Groups Administration

A new operator call John Doe, who has OAuth granted right to connect ot current OperatorFabric instance, need to receive cards within current OperatorFabric instance. As a user of OperatorFabric, he needs to be added to the system with a login (john-doe-operator), his firstName (John) and his lastName (Doe). operator As there is no Administration GUI for the moment, it must be performed through command line, as specify here.

3.5.1. List all users

First of all, list the users (who are the recipients in OperatorFabric) of the system with the following commands:

Httpie

http http://localhost:2103/users "Authorization:Bearer $token" "Content-Type:application/type"

cURL

curl -v http://localhost:2103/users -H "Authorization:Bearer $token" -H "Content-Type:application/type"

response

HTTP/1.1 200 OK

[
    {
        "firstName": null,
        "groups": [
            "ADMIN"
        ],
        "lastName": null,
        "login": "admin"
    },
    {
        "firstName": null,
        "groups": [
            "RTE",
            "ADMIN",
            "CORESO",
            "TRANS",
            "TEST"
        ],
        "lastName": null,
        "login": "rte-operator"
    },
    {
        "firstName": null,
        "groups": [
            "ELIA"
        ],
        "lastName": null,
        "login": "elia-operator"
    },
    {
        "firstName": null,
        "groups": [
            "CORESO"
        ],
        "lastName": null,
        "login": "coreso-operator"
    },
    {
        "firstName": null,
        "groups": [
            "TSO1",
            "TRANS",
            "TEST"
        ],
        "lastName": null,
        "login": "tso1-operator"
    },
    {
        "firstName": null,
        "groups": [
            "TSO2",
            "TRANS"
        ],
        "lastName": null,
        "login": "tso2-operator"
    },
]

3.5.2. Create a new User

We are sure that no John-doe-operator exists in our OperatorFabric instance. We can add him in our OperatorFabric instance using the following command use httpie:

echo '{"login":"john-doe-operator","firstName":"Jahne","lastName":"Doe"}' | http POST http://localhost:2103/users "Authorization:Bearer $token" "Content-Type:application/json"

Or here cURL:

curl -X POST http://localhost:2103/users -H "Authorization:Bearer $token" -H "Content-Type:application/json" --data '{"login":"john-doe-operator","firstName":"Jahne","lastName":"Doe"}'

response

HTTP/1.1 200 OK

{
    "firstName": "Jahne",
    "lastName": "Doe",
    "login": "john-doe-operator"
}

3.5.3. Fetch user details

It’s always a good thing to verify if all the information has been correctly recorded in the system:

with httpie:

http -b http://localhost:2103/users/john-doe-operator "Authorization:Bearer $token" "Content-Type:application/json"

or with cURL:

curl http://localhost:2103/users/john-doe-operator -H "Authorization:Bearer $token" -H "Content-Type:application/json"

response

HTTP/1.1 200 OK

{
    "firstName": "Jahne",
    "groups": [],
    "lastName": "Doe",
    "login": "john-doe-operator"
}

3.5.4. Update user details

As shown by this result, the firstName of the new operator has been misspelled.We need to update the existing user with john-doe-operator login. To correct this mistake, the following commands can be used :

with httpie:

echo '{"login":"john-doe-operator","lastName":"Doe","firstName":"John"}' | http PUT http://localhost:2103/users/john-doe-operator "Authorization:Bearer $token" "Content-Type:application/json"

or with cURL:

curl -X PUT http://localhost:2103/users/john-doe-operator -H "Authorization:Bearer $token" -H "Content-Type:application/json" --data '{"login":"john-doe-operator","firstName":"John","lastName":"Doe"}'

response

HTTP/1.1 200 OK

{
    "firstName": "John",
    "lastName": "Doe",
    "login": "john-doe-operator"
}

3.5.5. List groups

This operator is the first member of a new group operator called the OPERATORS, which doesn’t exist for the moment in the system. As shown when we lists the groups existing in the server.

Httpie

http http://localhost:2103/groups "Authorization:Bearer $token" "Content-Type:application/type"

cURL

curl http://localhost:2103/groups -H "Authorization:Bearer $token" -H "Content-Type:application/json"

response

HTTP/1.1 200 OK

[
    {
        "description": "The admin group",
        "name": "ADMIN"
    },
    {
        "description": "RTE TSO Group",
        "name": "RTE"
    },
    {
        "description": "ELIA TSO group",
        "name": "ELIA"
    },
    {
        "description": "CORESO Group",
        "name": "CORESO"
    },
    {
        "description": "TSO 1 Group",
        "name": "TSO1"
    },
    {
        "description": "TSO 2 Group",
        "name": "TSO2"
    },
    {
        "description": "Transnationnal Group",
        "name": "TRANS"
    }
]

3.5.6. Create a new Group

Firstly, the group called OPERATORS has to be added to the system using the following command:

using httpie:

echo '{"name":"OPERATORS","decription":"This is the brand new  group of operator"}' | http POST http://localhost:2103/groups "Authorization:Bearer $token" "Content-Type:application/json"

using cURL:

curl -X POST http://localhost:2103/groups -H "Authorization:Bearer $token" -H "Content-Type:application/json" --data '{"name":"OPERATORS","decription":"This is the brand new  group of operator"}'

response

HTTP/1.1 200 OK

{
    "description": null,
    "name": "OPERATORS"
}

3.5.7. Fetch details of a given group

The result return seems strange, to verify if it’s the correct answer by displaying the details of the group called OPERATORS, use the following command:

using httpie:

http http://localhost:2103/groups/OPERATORS "Authorization:Bearer $token" "Content-Type:application/json"

using cURL:

curl http://localhost:2103/groups/OPERATORS -H "Authorization:Bearer $token" -H "Content-Type:application/json"

response

HTTP/1.1 200 OK

{
    "description": null,
    "name": "OPERATORS"
}

3.5.8. Update details of a group

The description is really null. After verification, in our first command used to create the group, the attribute for the description is misspelled. Using the following command to update the group, with the correct spelling, the new group of operator gets a proper description:

with httpie:

echo '{"name":"OPERATORS","description":"This is the brand new  group of operator"}' | http -b PUT http://localhost:2103/groups/OPERATORS "Authorization:Bearer $token" "Content-Type:application/json"

with cURL:

curl -X PUT http://localhost:2103/groups/OPERATORS -H "Authorization:Bearer $token" -H "Content-Type:application/json" --data '{"name":"OPERATORS","description":"This is the brand new  group of operator"}'

response

{
    "description": "This is the brand new  group of operator",
    "name": "OPERATORS"
}

3.5.9. Add a user to a group

As both new group and new user are correct it’s time to make the user member of the group. To achieve this, use the following command:

with httpie:

echo '["john-doe-operator"]' | http PATCH http://localhost:2103/groups/OPERATORS/users "Authorization:Bearer $token" "Content-Type:application/json"

with cURL:

curl -X PATCH http://localhost:2103/groups/OPERATORS/users -H "Authorization:Bearer $token" -H "Content-Type:application/json" --data '["john-doe-operator"]'

response

HTTP/1.1 200 OK

Let’s verify that the changes are correctly recorded by fetching the :

http http://localhost:2103/users/john-doe-operator "Authorization:Bearer $token" "Content-Type:application/json"

with cURL

curl http://localhost:2103/users/john-doe-operator -H "Authorization:Bearer $token" -H "Content-Type:application/json"

response

HTTP/1.1 200 OK

{
    "firstName": "John",
    "groups": ["OPERATORS"],
    "lastName": "Doe",
    "login": "john-doe-operator"
}

It’s now possible to send cards either specifically to john-doe-operator or more generally to the OPERATORS group.

3.5.10. Remove a user from a Group

When John Doe is no longer in charge of hypervising cards for OPERATORS group, this group has to be removed from his login by using the following command:

with httpie:

http DELETE http://localhost:2103/groups/OPERATORS/users/john-doe-operator "Authorization:Bearer $token" "Content-Type:application/json"

with cURL:

curl -X DELETE -H "Authorization:Bearer $token" -H "Content-Type:application/json" http://localhost:2103/groups/OPERATORS/users/john-doe-operator

response

HTTP/1.1 200 OK

{
	"login":"john-doe-operator","
	firstName":"John",
	"lastName":"Doe",
	"groups":[]
}

A last command to verify that OPERATORS is no longer linked to john-doe-operator:

with httpie:

http http://localhost:2103/users/john-doe-operator "Authorization:Bearer $token" "Content-Type:application/json"

with cURL:

curl http://localhost:2103/users/john-doe-operator -H "Authorization:Bearer $token" -H "Content-Type:application/json"

response

HTTP/1.1 200 OK

{
    "firstName": "John",
    "groups": [],
    "lastName": "Doe",
    "login": "coreso-operator"

}

4. Service port table

By default all service built artifacts are configured with server.port set to 8080

If you run the services using bootRun Gradle task or the provided docker-compose files (see [prj]/src/main/docker) the ports used are

Service bootRun port docker-compose mapping docker-compose debug mapping

registry

2001

2001

2001

gateway

2002

2002

2002

thirds

2100

2100

2100

time

2101

2101

2101

cards-publication

2102

2102

2102

users

2103

2103

2103

cards-consultation

2104

2104

2104

config

4000

4000

4000

registry

4001

4001

4001

gateway

4002

4002

4002

thirds

4100

4100

4100

time

4101

4101

4101

cards-publication

4102

4102

4102

users

4103

4103

4103

cards-consultation

4103

4103

4103

Complete port table

Port Forwards to

89

KeyCloak

89

KeyCloak api port

2000

config

8080

Configuration service http (REST)

2001

registry

8080

Registry service http (REST)

2002

gateway

8080

Gateway service http (REST+html)

2100

thirds

8080

Third party management service http (REST)

2101

time

8080

Time management service http (REST)

2102

cards-publication

8080

card publication service http (REST)

2103

users

8080

Users management service http (REST)

2104

cards-consultation

8080

card consultation service http (REST)

2105

actions

8080

actions (REST)

2200

web-ui

8080

card consultation service http (REST)

4000

config

5005

java debug port

4001

registry

5005

java debug port

4002

gateway

5005

java debug port

4100

thirds

5005

java debug port

4101

time

5005

java debug port

4102

cards-publication

5005

java debug port

4103

users

5005

java debug port

4104

cards-consultation

5005

java debug port

4105

actions

5005

java debug port

4200

web-ui

5005

java debug port

27017

mongo

27017

mongo api port

5672

rabbitmq

5672

amqp api port

15672

rabbitmq

15672

rabbitmq api port

5. Restricted operations (administration)

Some operations are restricted to users with the ADMIN role, either because they are administration operations with the potential to impact the OperatorFabric instance as a whole, or because they give access to information that should be private to a user.

Below is a quick recap of these restricted operations.

Users Service

Any action (read, create/update or delete) regarding a single user’s data (their personal info such as their first and last name, as well as their settings) can be performed either by the user in question or by a user with the ADMIN role.

Any action on a list of users or on the groups (if authorization is managed in OperatorFabric) can only be performed by a user with the ADMIN role.

Thirds Service

Any write (create, update or delete) action on bundles can only be performed by a user with the ADMIN role. As such, administrators are responsible for the quality and security of the provided bundles. In particular, as it is possible to use scripts in templates, they should perform a security check to make sure that there is no XSS risk.

Time Service (for demonstration purposes only)

Any user can get the current state of simulated time but acting on it (changing the speed of time flow, setting the reference for simulated time or resetting it entirely) requires the ADMIN role.

The ADMIN role doesn’t grant any special privileges when it comes to card consultation (be they current or archived), so an user with the ADMIN role will only see cards that have been addressed to them or to one of their groups), just like any other user.