Administration

Admin User Configuration

The first and most important action to take after completing the installation is to change the credentials of the admin user. To do so login to the Console with the default EC credentials.

Once you are logged in, click over the username located in the top right portion of the window and select Change password.

Configure Certificates

At first access the EC auto generates two certificates:

• Default JWT certificate. Used by the AuthenticationService on login to sign the token in the Access Token.
• Default Device Management certificate. Used by all of the Device Management Services to sign messages sent to a ESF-enabled device.

These certificates can be replaced if needed; as a good practice, for a pre-production and production environments consider to install the correct certificates before start connecting devices, this will save time later. For more details regarding certificate management refer to section Certificates

📘

Check that these two certificates have the Forwardable attribute set to TRUE (checked). This allows the certs to be transparently "inherited" by child accounts.

Messaging Service Configuration

After a fresh installation you may have created a Messaging Service instance with the deploy of the ec-broker Helm Chart. Check the Messaging Service to verify that the service is available.

Device Provisioning Enablement

EC provides a special account for Device Provisioning named ec-provisioning. If you want to enable Device Provisioning for the users, the ec-provisioning account must be assigned to a Messaging Service instance. Check Messaging Service for more info on how an account is assigned to a Messaging Service instance.

📘

The provisioning account is shared by all the devices in an EC instance. If you are going to create multiple Messaging Service instances (e.g. one instance per customer account), consider assigning a dedicated Messaging Service instance to the provisioning account.

Remote Access Service Configuration

After a fresh installation you may need to configure the Remote Access Service created with the deploy of the ec-vpn Helm Chart. Check the Remote Access Service section for more informations regarding configuration of this service.

CORS Filter Configuration

If you want to enable access to the RESTful API from the SwaggerUI of the API component itself or from any other origin that you trust, you must configure the CORS Filter. CORS Filters can be enabled at the instance level for every account or for specific accounts. Check the CORS Filter documentation for more details.

Data Store Engine Configuration

Data store is based on Elasticsearch engine. Data are stored in indices with the following name patterns:

1. [prefix-]accountID-data-message-* (e.g. * = "YYYY-WW", meaning year-week)
2. [prefix-]accountID-data-client
3. [prefix-]accountID-data-channel
4. [prefix-]accountID-data-metric

Consider to configure a prefix (e.g. "ec") so that indexes are easier to identify. Check the documentation at Datastore connection properties.

🚧

Index names and mappings may change in future versions. Use only Everyware Cloud services (such as RESTful API) to read/write data into the store so that data is kept consistent and impact of changes is minimized. Direct writes can break the service.

Log Store Engine Configuration

Log store is based on Elasticsearch engine. Logs are stored in indices with the following name patterns:

1. [prefix-]accountID-log-message-* (e.g. * = "YYYY-WW", meaning year-week)
2. [prefix-]accountID-log-client
3. [prefix-]accountID-log-channel
4. [prefix-]accountID-log-property

Consider to configure a prefix (e.g. "ec") so that indexes are easier to identify. Check the documentation at Logstore connection properties.

🚧

Index names and mappings may change in future versions. Use only Everyware Cloud services (such as RESTful API) to read/write data into the store so that data is kept consistent and impact of changes is minimized. Direct writes can break the service.

Routes Configuration

If you want to enable access to external systems through routes you may need to configure the Route Blacklisting feature. This feature acts at the instance level. Check the Blacklisting Feature documentation for more details.

Delegated Authentication Configuration

Everyware Cloud can be configured to authenticate users through an external Identity Provider. This feature is based on the OpenID Connect identity layer where Everyware Cloud acts as the client and the external OpenID Connect provider act as the authentication service.

Refer to the Container Properties page in order to provide the required configuration parameters.

📘

An Everyware Cloud instance can integrate with just one OpenID Connect Provider, thus the provider is shared by all the accounts in the instance.

Everyware Cloud delegated authentication uses the OpenID Connect Basic Client flow. In abstract the flow works as the following:

1. The Relying Party (EC) sends a request to the OpenID Provider (OP).
2. The OP authenticates the End-User and obtains authorization.
3. The OP responds with an ID Token and usually an Access Token.
4. The Relying Party can send a request with the Access Token to the UserInfo Endpoint.
5. The UserInfo Endpoint returns Claims about the End-User.

After the third step, the subject identifier is extracted. If an Everyware Cloud user is found that is externally authenticated and has an External ID that matches the subject identifier then access is give to that user.

If no matching user is found at this step, the flow is completed through out the fifth point. The username is extracted from the Claims. If an Everyware Cloud user is found that is externally authenticated and has an External Username that matches the extracted username then access is give to that user.

📘

External Usernames should be unique. Check that the Claim configured as the External Username is unique for the identities in the OpenID Provider, that is, there is only one identity matching a given claim value.

📘

Delegated authentication is available only for the Admin Console