IDS Connector deployment
This guide describes how to deploy an IDS connector used by SCSN Service Providers to expose back-end services to the network.
Requesting an Identity
Identities for the test environment can be requested via: Test DAPS. Both a participant certificate and a component certificate should be requested, by creating a Certificate Signing Request. The exact formatting of the certificate content is not fixed for the test environment, for the production environment guidelines will be made available. Contact Mike de Roode for the approval of the certificates.
Certificate Signing Requests can be created using several different tools, e.g. OpenSSL, make sure the key-length is at least 2048 bits. The distinguished name should reflect your participant and connector respectively, however, the these certificates are not used for SSL transport encryption but are only used for authentication and therefore the Common Name of the certificate is not required to be a Fully Qualified Domain Name.
The Participant ID and Connector ID are IDS identifier that can be chosen freely for the test environment, but they should be uniform resource identifiers (URI). This can be either an URL (starting with https://
) or an URN (starting with urn:
), since these identifiers are only used for identification the URN scheme is preferred. A common URN prefix of urn:scsn:ids
could be used (not registered as official prefix):
Participants:
urn:scsn:ids:participants:Service_Provider_Name
Connectors:
urn:scsn:ids:connectors:Service_Provider_Connector_Name
The result of the interaction with the DAPS should result in having at least the following files:
participant.key
participant.cert
connector.key
connector.cert
config.yaml
(only required for alternative Docker Compose deployment, but useful as reference for Kubernetes deployment)docker-compose.yaml
(only required for alternative Docker Compose deployment)
Deploying the Connector
The deployment scenario for the IDS connector uses Kubernetes and Helm. Make sure you are familiar with setting up an Kubernetes cluster and know what the purpose of at least the following resource types are: Deployment, Pod, Stateful Set, Service, Ingress, Ingress Controller, Config Map.
Helm is used as package manager for Kubernetes, in the form of an Helm chart. This Helm chart uses templates to describe resources and makes sure that the right connections are made between the different resources of the complete deployment. From a deployment perspective only the values.yaml
file must be modified to reflect your configuration.
The Helm chart can be found on the Connector documentation page, with comments inside the values.yaml
indicating the configuration options for the Helm chart.
Ingress Controller
For Kubernets Ingresses to work, the cluster should be configured correctly with an existing Ingress Controller (see Ingress Controllers). The ingress controller should be an nginx ingress controller, or another controller that supports the same annotations. Other ingress controllers may work, but can require manual annotations to be configured.
Depending on the cluster, optionally, automatic certificate renewal can be supported via LetsEncrypt and cert-manager. For this the manual for Microsoft Azure can be followed, except the step for setting up the DNS A record this manual is provider independent. Remember the identifier of the ClusterIssuer, since this is needed in the configuration.
Services
The services that will be deployed are the main focus for exposing the connector to other connectors and for exposing the connector to the internal backend systems.
service/{{ .Release.Name }}
: The /router endpoint of the http (8080) port of this service should be exposed via an Ingress to the outside world. This will be used by other connectors to exchange messages. This service also exposes a metrics (9999) port, that returns metrics of the connector via its root. As well as an core container API on the api (4567) port, this will be enhanced in the future and documented accordingly.service/{{ .Release.Name }}-openapi-data-app
: The /openapi endpoint of this service must be used by your backend system in order to send messages to other connectors. This endpoint acts as kind of a proxy for the messages. Note: this service is not protected, exposing this to the outside world allows everyone to send messages via your connector! . Exposing this service can be done in several ways:ClusterIP service, when the backend system also is deployed on the same Kubernetes cluster
NodePort service, when the cluster nodes are not directly reachable from outside your network a NodePort service can be used which allows other non-kubernetes machines to access the service via a specific port on one of the cluster nodes.
Ingress, a ingress can be used with strict access control policies (using authentication or strict network segregation).
Core container service configuration
The core container is intended to be exposed via an ingress, this can be configured in the coreContainer.ingress
values. For this an ingress controller is required to be available on the kubernetes cluster. The chart assumes an nginx ingress controller, since there is a need for the configurability of the ingress. Optionally, a cert-manager ClusterIssuer can be used to automatically provision LetsEncrypt (or other ACME certificate authorities) certificates for the ingress.
The host
or coreContainer.host
value is used as hostname for the ingress.
For the core container, the rewriteTarget
must be able to include /router
, this endpoint should be publicly accessible. Examples configurations are (with the corresponding accessUrl):
The ingress configuration is mapped to the http
port of the core container, next to this port there are two other ports exposed as services:
api
: exposes the core container API, used for the optional user interface of the connector. Will be explained via an OpenAPI description in the future, together with a new user interfacemetrics
: exposes metrics of the core container via a Prometheus style exporter
OpenAPI data app service configuration
For the OpenAPI data app service there is more flexibility, however, it is important that this service is not exposed publicly without strict firewalling or authentication.
Per default, the OpenAPI data app service is exposed as ClusterIP service, which makes the data app only available within the kubernetes cluster.
A NodePort service can also be configured, this service exposes the service to a port above 30000 on the nodes of the cluster. It is important to ensure firewall restrictions to make sure only your own applications can use this port. The following example exposes the data app on port 31000:
Also an ingress can be used, however it is advised to add authentication to the ingress (e.g. https://kubernetes.github.io/ingress-nginx/examples/auth/basic/):
Distributed tracing
Both the core container as the OpenAPI data app support distributed tracing, respecting X-B3 headers. The trace identifiers are logged to standard out of the containers. The log templates are:
Core container (Log4J):
OpenAPI data app (Logback):
Horizontal scaling
Both the core container as the OpenAPI data app can be scaled horizontally by setting the coreContainer.replicaCount
key or in the ids.containers[0].replicaCount.replicaCount
key. The distribution of the load is provided via Kubernetes.
Metrics endpoint
The core container exposes a metrics endpoint with relevant metrics of the processing times and number of messages exchanged. These metrics may be used to identify bottlenecks early, or can be used to support the decision making for horizontal autoscaling of the core container. The important keys that are exposed are: camel_exchanges_failed
, camel_exchanges_inflight
, camel_exchanges_completed
, camel_exchanges_total
, camel_last_processing_time
, camel_total_processing_time
.
Metrics are gathered per route, for easier searches the ids.routes[].id
key can be used to specify custom route identifiers (NOTE: these identifiers must be unique in the connector). Per default the routes are given an identifier based on the order in the ids.routes
list, together with the type of the route (e.g. route-0-https-out
and route-1-https-in
for the default routes in values.yaml
).
In following releases this functionality will be extended with metrics for the OpenAPI data app and with sample deployments for Prometheus and Grafana (to visualize the metrics) and the Kubernetes Horizontal Pod Autoscaler in combination with these metrics.
Configuration
The configuration of the Helm deployment is contained in the values.yaml
file. The values.yaml
file in the Connector documentation page contains a basic deployment, with a lot of comments to further structure your connector. An example of a full values.yaml
file can be found in values.test.yaml
which includes ingress configuration, an agent database, and demo applications as used by the TNO Test Buyer. The contents of the values.yaml file is also shown below for easy reference by line numbers:
In the next release values that have to be secret (such as the IDS identity key) will be able to be configured as Kubernetes Secrets that can be configured to be installed via the Helm chart as well as using existing secrets.
Agent Database support
The OpenAPI data app supports configuration of agents via a MongoDB database. The structure of the documents follows the static agents in the values.yaml
. The chart includes an optional Bitnami MongoDB deployment, which can be activated by setting mongodb.enabled
to true and set a root password. Or you can use an existing MongoDB or deploy it next to the connector.
The configuration allows for different types of MongoDB to be connected:
The provided database and collection will be created automatically if they do not exist and the user has the rights to create the database.
API version configuration
The configuration file allows different kinds of configuration for the API version that is used in the OpenAPI data app. In the example above, the global version configuration is shown that applies to all agents configured. But more granular version support per agent can also be configured, so that not all agents are required to support the same versions. Also, the way the versions are propagated to the backend system can be configured to further control the way the backends are called from the data app. The following examples show the different options, all starting on the level of the customProperties
field on line 167 in the config example above.
Different versions per Agent
In this example, both agents support the global version(s) from the list on line 3 and specific versions specified on lines 8 and 13 for respectively agent A and agent B. So agent A will support versions 0.9.0 and 1.0.0 and agent B 1.0.0 and 1.1.0.
Internal backend configuration
Global backend URL mapping
The global backEndBaseUrl
can be used to forward all messages to generalized paths in the form of {backEndBaseUrl}/{agentId}/{version}
in the example above: http://globalBackend:8080/urn:scsn:agentA/1.0.0
.
Global backend per version
The global backEndBaseUrlMapping
can be used to forward all messages for specific API versions to generalized paths in the form of {backEndBaseUrlMapping}/{agentId}/
in the example above: http://100backend:8080/urn:scsn:agentA
.
Agent based generic backend
The agent based backendUrl
can be used to forward all messages for a specific agent to a backend, this backend will be appended with the version. For example: http://agentAbackend:8080/0.9.0
.
Agent based backend per version
This is the most configurable option, where you can specify for each agent and each version specifically what backend should be used.
Alternative deployment: Docker-Compose
This deployment method will become deprecated, since this method is less configurable and requires more manual work to safely expose the connector to the outside world.
Deploying the connector is done via docker-compose. So the environment requires to have Docker and Docker Compose installed.
First the Docker registry credentials have to be set on the machine that will deploy the connector:
The docker-compose.yaml file is as follows:
The deployment is started by executing the docker compose up command inside the directory with the configuration files:
When bringing the connector down, it is important to bring the deployment down by executing docker-compose down
, as this ensures that the data app container and helper containers are shutdown correctly. Otherwise, when the machine shuts down without correctly removing these containers the possibility exists that when a new deployment is started the old containers are blocking the deployment.
Docker privileges
The basic deployment requires the core-container to mount the Docker socket, this is not desirable for all configurations. The requirement for mounting the Docker socket comes from the fact that the core container is responsible for managing the data apps. Mounting the Docker socker requires the container to run as root, or effectively as root, which might pose risks to the security of the system the container is running on.
For the docker-compose deployment you can run the core-container as non-root, but this will require the docker socket to not be mounted and to set the containerManager field in the config.yaml
to none:
Disabling this feature also means that the data apps should be configured and deployed manually. The image tag of the core-container must be appended with -nonroot
, not including the date pinned tag, e.g.:registry.ids.smart-connected.nl/trusted-core-container:master-nonroot
Production Environment
In order to migrate to the SCSN Production environment, the following actions should be undertaken.
Request a Participant and Component certificate signing request for the Production DAPS. Contact Mike de Roode for the approval of the certificates.
Replace the signed certificates in the Connector's configuration.
Change the UUID and truststore values:
UUID: The UUID of your production environment certificate Truststore:
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR5VENDQXJHZ0F3SUJBZ0lVUFY0T3Q3bzVhNFpDTzd6UmFPRGRxandkQ1Qwd0RRWUpLb1pJaHZjTkFRRUYKQlFBd1hqRUxNQWtHQTFVRUJoTUNUa3d4TkRBeUJnTlZCQW9NSzFOdFlYSjBJRU52Ym01bFkzUmxaQ0JUZFhCdwpiR2xsY2lCT1pYUjNiM0pySUVadmRXNWtZWFJwYjI0eEdUQVhCZ05WQkFNTUVFbEVVeUJUUTFOT0lGSlBUMVFnClEwRXdIaGNOTWpBeE1EQXhNVFEwTVRVMldoY05OREF3T1RJMk1UUTBNVFUyV2pCZU1Rc3dDUVlEVlFRR0V3Sk8KVERFME1ESUdBMVVFQ2d3clUyMWhjblFnUTI5dWJtVmpkR1ZrSUZOMWNIQnNhV1Z5SUU1bGRIZHZjbXNnUm05MQpibVJoZEdsdmJqRVpNQmNHQTFVRUF3d1FTVVJUSUZORFUwNGdVazlQVkNCRFFUQ0NBU0l3RFFZSktvWklodmNOCkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFPOWNKVHZPTkFhMWN5dDBjU3hIZHZleHhkRFFSZEFyRGJTcHdhbGoKbWFvV2s5d3Y3RllrdU1ROW1Hd2l0NWNmNzdhb0RXYmpLVzZnTXQyNEp2ZEtKOSsvbVNCOVJab2VzSjRZVVFBeApyUHI0UXgzdjk0cndncEZWQzVOa1ZSbkkrSHJaUDlOc01kN0pIOTF4UzFpR29ScGE5Y0RCT08wNDZNNEtDR0ZVCm1QQXNpZ3loYTNNR1VFM3d3YWg3L1JzdGxwcmRLN0xHcHRJUGlNamkxMUw0S2NycTZJN2lHNGtWWHJ0eDFSK2wKSjAxb1FUVFZVZ041L2Zmdm9ISzd1UnMzb2plL212Z21QWTNnK1h3WVk4d2pXM2VLckt2NGhlQ2hLdkdwZGgvNgpveSs2UzhuYko0djFwRXR2QnFVdzR6eXZNVENpNTBObkZIZUN1YVJBREFVTlpiRUNBd0VBQWFOL01IMHdIUVlEClZSME9CQllFRk9lRzJFVnFVYkpxdG1VYU90cU9jY29tUWI0SU1COEdBMVVkSXdRWU1CYUFGT2VHMkVWcVViSnEKdG1VYU90cU9jY29tUWI0SU1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0N3WURWUjBQQkFRREFnRkdNQjBHQTFVZApKUVFXTUJRR0NDc0dBUVVGQndNQkJnZ3JCZ0VGQlFjREFqQU5CZ2txaGtpRzl3MEJBUVVGQUFPQ0FRRUFZaFd3CjRab2p0dmRORzRuaFFQOXlOcmJRYXdmMW12eW9HMzRLSDZCcWh3REhqTk1MM2llU1B0ak9LUkNDUVpMbjVhVWYKUWpmRlZXN1FWZFREL0dNSzBPVDZ4c1R0aElzbCtncGpicmx1cnc5eEJBWkpnQWM5bXVldmthdGtja0dCc2NMVwpvbGtTTFJsVjFkRVk4Z2hJV2NoMFhqY1dLV0dFWjdWdUd2eTBZWWJIYTNZSEZzYWxBejUybjVueFROdjdZTlk5CjdsVnpSZDFiRDN6dk5kVkNCTCs3M2t5dU5kSGFZbFBuZ0JJUG5DazBkZXF1Mzk1NGZpNk9NU3BEV2NxZGRQU3oKQWhWbkhCV21EOWFubXArc3Z6UVZxbEkwSDM1UlMrekZWRllHUy9IbjJkODgzU1VwQ2dwTnlwTkZZNzZBRXBKZApOVVdBdUJuelZjckV6YjVXbXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQpNSUlFdkRDQ0E2U2dBd0lCQWdJQkFUQU5CZ2txaGtpRzl3MEJBUVVGQURCZU1Rc3dDUVlEVlFRR0V3Sk9UREUwCk1ESUdBMVVFQ2d3clUyMWhjblFnUTI5dWJtVmpkR1ZrSUZOMWNIQnNhV1Z5SUU1bGRIZHZjbXNnUm05MWJtUmgKZEdsdmJqRVpNQmNHQTFVRUF3d1FTVVJUSUZORFUwNGdVazlQVkNCRFFUQWVGdzB5TURFd01ERXhORFF4TlRkYQpGdzB5T0RBNU1qa3hORFF4TlRkYU1HUXhDekFKQmdOVkJBWVRBazVNTVRRd01nWURWUVFLREN0VGJXRnlkQ0JECmIyNXVaV04wWldRZ1UzVndjR3hwWlhJZ1RtVjBkMjl5YXlCR2IzVnVaR0YwYVc5dU1SOHdIUVlEVlFRRERCWkoKUkZNZ1UwTlRUaUJFUlZaSlEwVWdVMVZDSUVOQk1JSUNJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBZzhBTUlJQwpDZ0tDQWdFQXNXdUdlYWNXT2I5VkFWVGYwanpTVXhLcUtjR3VXazM0bjByUlNZakhSMTJpUmxHb3l6UHV4S0RlCmhoaXc4eVBhSGdFOHVURTFHS1k2dnVNdHB6Q2JHRlk3WjN6QVhzSjloNDVPYnQ5d05EaWlxTEZWN2VSKzJTdisKVExNb0ZXRGxjeFVmQjRHc1c0cWMzSlpXQy8wTDkxcEdxNm5nSk1RV3NaNnQwOWhkL3hwZTVxbmEzMDFqUXN3bwppWGFsb3BVUVNpWjJld1hLUmp5QllUbWkwMy9WN0dZUG8vWW1IcjJ1MDB6blRKSFpCMEM2NWU3MWltcERPVERGCkpSV3ROQXB3MWIydUhIUSs1UklHeGllNWliR2xHV3VzanNKR0dMbGY4Y25jRlNpc3JhMWgwVkRCaS9rMk5Idm4KSFo1SDVPT0FiNTdXV041U1A5VHU2Y1dWUHVrSXZObGVtTjV2UktIYmpZSDdXSnd0cGdjd0JCZ0dzYjZiZ0hPNQpIa2ZEazljNWQvNGMrQTdOU0VXT043U0NJMUx2YjZrbFJRbk1kSjVWRm9IVW5HU2ZpMzQycU0xSlhDRFpidkVGCjYwMmRNWWFnaUlOdWM3WWc2RjhYcno1UVA1VzRKdDRudW5hV3NnaVdSZUtzWHJpQ1dYdm9Vc2V1VVJIeUw5SWsKZzZST3RuTll4MmF1MGF4Z2VpRk5qdmhnOCt3K0psaXpUeERBOGc4OFp6Slp2S3M1Mm51T2t6bGxRbUVOazlZVwpxaGcva094VTl1amdPTnV2Zmo2K2lSY2x5T0hKTEV6RDhFNlMzcnExTXdBV1FyNStmZkE4MnlxRThZSWtIS3hhCjVJcnVlS1FUYXg2S3Z6SDFNUTRpNkV3eFVUZ0JLMEVOdk1LRDhpQm1TUWFCTitQL05FMENBd0VBQWFOL01IMHcKSFFZRFZSME9CQllFRk1NOEdPTHN3ak1STkp0Zy9QZDBqZG9qQlJyd01COEdBMVVkSXdRWU1CYUFGT2VHMkVWcQpVYkpxdG1VYU90cU9jY29tUWI0SU1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0N3WURWUjBQQkFRREFnR0dNQjBHCkExVWRKUVFXTUJRR0NDc0dBUVVGQndNQkJnZ3JCZ0VGQlFjREFqQU5CZ2txaGtpRzl3MEJBUVVGQUFPQ0FRRUEKZHdHeHVUNHdtQjd0YTlpQm5Fakx5Mm9Bd0pkZXFaYldhRC83aVdpNHl5V04vYldBQ2FVT2gwbDJhdmJTOG1IegpScUh4V0FOSnZhNTN3ZXhsakZlbURpbGNYMlF1YUtoUVNReVNmM3FwbDZzY2cvQUtZc3JHTlpqNVVSMFR3cUpCCmQ4TU9XbVhNM3RMRHdTaWFVY2RyK0I2bkFjNUhzRXpUQmw4WDRxOWhkMktSTytsREZ6alh4Vk8vYXFBZklPMWsKOFhyQksvQ0kyMnlTQWd4cUFZK01lS0R3R1pVTDArdzh6d0FiRGtIZFZsWkpLK0pkaS90dHcyT0syNDNuUlAyMgo2a3ZFN0ZwOHlHRHFESmN6VHdSOE1iY201d2c4VDZBNDEvektGWXE2eHlLQWkwd3U2OGF6SGpDSXBzVTloUG0xCkRLSkRJV1hwTktlaE5ZaCs3eWExVWc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQpNSUlFd1RDQ0E2bWdBd0lCQWdJQkFUQU5CZ2txaGtpRzl3MEJBUVVGQURCZU1Rc3dDUVlEVlFRR0V3Sk9UREUwCk1ESUdBMVVFQ2d3clUyMWhjblFnUTI5dWJtVmpkR1ZrSUZOMWNIQnNhV1Z5SUU1bGRIZHZjbXNnUm05MWJtUmgKZEdsdmJqRVpNQmNHQTFVRUF3d1FTVVJUSUZORFUwNGdVazlQVkNCRFFUQWVGdzB5TURFd01ERXhORFF4TlRkYQpGdzB5T0RBNU1qa3hORFF4TlRkYU1Ha3hDekFKQmdOVkJBWVRBazVNTVRRd01nWURWUVFLREN0VGJXRnlkQ0JECmIyNXVaV04wWldRZ1UzVndjR3hwWlhJZ1RtVjBkMjl5YXlCR2IzVnVaR0YwYVc5dU1TUXdJZ1lEVlFRRERCdEoKUkZNZ1UwTlRUaUJRUVZKVVNVTkpVRUZPVkNCVFZVSWdRMEV3Z2dJaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQwpEd0F3Z2dJS0FvSUNBUUMwZ1NvRjltRWZGOE5abVlUZHpQbmQ3aXBSeGtLSU4rcFExWHhPbHlYTGhoNXJRYkl5CkNzSkx4NHNRMnE0VEoxTVNnTWZBb0RualowdTZ2d3lodnh4TUpub0cvellGZzBLZGRaeGdjYVAxZWVxTHlBcWsKT1VhZjJtZ3AzbEg5S0lpdjhKVk5pTHBTVHRtOERTS01KK25xbWdsWloxZTEwd29jOFJ1SFM4T2xmZDVUU0lIVwptTDhYcUlrczJXenNxTWswUmJ0ZmNVV2kybFFzR2dSNGMwNVNUdnFYTkVPditiZ3lNNUF3QkhOV2JIMzZqd2ZCClFEaTZtd3F1aU5hdXd6ZnBnWVh4elVXb041aHhxQzJCREc4TlBTSjdRVU9tK3daMUhuUGxhM2FTYldnQ0ozd00KTElmcTA0YWhZSHdwaXE5alhoNjJQZGNCaW5pcVlzUkFOczkva3UrNEdIbWh2YkZ4aXI3d3NFdzd3bXlCN09tQwpTdEt0NGdKWjRJaVVUaDlzbGJTRjFSVVh6QS9UNjJScEl4dkx1c1JJT2ROQVNWcEM0YVdycmFvZGRkV1ZaZVRjCkJrUzFJdmpxaWxuN01PemZsWEk1REpkbDF6dHY3bHA4Qm55RTJoQ3ZtUStYakY0TUhwSmx4UlFrVWhlL2pwcGkKaUVubWl1MjBsNE04WWVhY3d0MHhvVUNkeUE5dHlzK3hhOUlrZTVxcVVJYXFWdG5lSXdlSUNXclV1MGJESFJKcgpZRStjNEFBcjZUcXhPQlJ0aTdrMDRuSlhqblFNemxqYW9RSHZDWmZtcHJOQ01HNXRIeFJsRGRtdWV1eXJOU0pDCk5QaEZubmtkWGhHL2VOV3Zwd3ZEWUQ0bnBDVUQ4TjY5V0Y2WTFpZVpyRU9XdXJ1aFpabFhaRUwvdHdJREFRQUIKbzM4d2ZUQWRCZ05WSFE0RUZnUVVHTEQ5T0JXdWNGS0tQKzErS2NUZXJCekJkdVF3SHdZRFZSMGpCQmd3Rm9BVQo1NGJZUldwUnNtcTJaUm82Mm81eHlpWkJ2Z2d3RHdZRFZSMFRBUUgvQkFVd0F3RUIvekFMQmdOVkhROEVCQU1DCkFZWXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0VHQ0NzR0FRVUZCd01DTUEwR0NTcUdTSWIzRFFFQkJRVUEKQTRJQkFRQVgreEZFcEpwdGovVkRYdEk5d0VWZnFaZjlTbmlIZlhNaTNvb29QbWpibnpOcGQyeEtCU2lxQnY5TgpMTmlkazVVMS9UV3FROWl2U2RPaGJNZzNXMFVTbnVaWG5iTThLQmY4Vjcyc2htcHBMVEpjRUI3cllXZW9QYTc2CmNPRGpYMGI1czlpSGpHM1hiN1R2TE52RjhqWjdWeEEzOHJnNys5T0FEK0lVc0NnQ05NbjFIdmdPZHR0UDRWRWkKMVQ3YzhvbjJSM2taYUs2Zm1laW90STE0eTduOXgrMVhYakhnZDZ6R0hKMUJrRnRsczVyUWlRWUxyM2F6U2RrTwpnd2FyTzhybnY5TkFIeVNSMTFqcDZJVUZ4cGZFYTJQYkQyaFQ3WlB6ZnMxcmRjTVlMVUFscEE0UVdLNjByRXJHCm5GdnpvaUJYWlFjdC9na1ltOXBSUDl4aUNTZGUKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ==
Change the Broker and DAPS URLs: ids.info.broker.address:
https://broker.test.ids.smart-connected.nl/infrastructure
->
https://broker.ids.smart-connected.nl/infrastructure
ids.daps.url:https://daps.test.ids.smart-connected.nl
->
https://daps.ids.smart-connected.nl
Test the connection.
Last updated