Domain Model and Security Principles of the re.alto API Platform

The vision of re.alto is to support businesses in developing outstanding products by providing APIs and energy-driven data solutions to help build digital products faster. We do this by connecting to devices through their existing IoT connectivity. At the core of our solution is a powerful IoT management platform. It connects to any type of device, streams device data in real-time and securely stores it for future retrieval. The platform can stream thousands of data sets per second, it can aggregate readings, it can retrieve charge data records (where available), and it can be used to manage and steer devices. Integration is also straightforward.  

The guide below explains our domain model, the terminology used and our IoT platform’s security principles.  

The platform is structured in Tenants. Tenant refers to a customer environment. Every Tenant has an administrator. The Tenant admin controls everything within that Tenant. The Tenant admin can be either a person or a program/app, which are known as Principals of type User or Client respectively. A Client is usually used by a backend system/process like an app and has a Client ID and a Client secret. A User logs in using an email and password. It is this Client ID or User ID that defines what you have access to see on the platform. The Tenant admin is also a Principal (which is therefore either a Client ID or a User). Members are Clients or Users that are part of a Tenant but are not admins. Members also either have a Client ID or a User ID, however members cannot remove/add themselves or other members to a Tenant, only the Tenant admin has the right to do this.  

In each Tenant, the Tenant admin can onboard devices which we refer to as Entities. An Entity is added in the system via an onboarding request raised by a Principal with access, which also becomes the owner unless a different owner is specified in the request. Any sort of device that we onboard becomes an Entity and receives an Entity ID. Each Entity has an owner. The Entity owner has the right to change its properties. Members have reduced rights and can read the data but cannot alter the properties of an Entity.  

Entities can be grouped together in Collectives. A Tenant can have multiple Collectives, making it easy to separate different Entities into groups (depending on company they belong to, for example). Entities that are grouped together in Collectives can be displayed together. Each Collective has an owner that is assigned by the Tenant admin, and multiple members can be added to each Collective, all of whom then have rights to see the data of the Entities within that Collective. “Collective” refers to a group of Entities and of Users who are members of a Collective. A Collective of Entities has a Collective owner and Collective members. The data from all Entities in a Collective can be shared with a number of Principals (User or Client IDs). The owner of the Collective can set certain parameters on an Entity, such as its name. Members can only use the Entities (ie: read their data).  

The Collective is a powerful tool to link various Entities together and then share the data with other people or programs. For example, a fleet manager could use a Collective to conveniently see the data from all of their company’s vehicles in one place. However, a Collective could also refer to a household with multiple cars, a heat pump etc, and any member of that Collective could then view the data from all Entities within that Collective.  

The security principles are based on the domain model explained in the first part of this article. You must be the Tenant owner/admin or member of the Tenant, or the Collective owner or member of the Collective, to be able to see the data of a device. To authenticate against our platform, a Client ID or User ID is required. Once you have that, you must be the owner or member of a Tenant or Collective in order to access data. Every individual record, Tenant, Entity and Collective is secured with these security rights. The only way to access our platform is to have a Principal ID, which is either the Client ID (for programs) or the User ID (for people). This ID is either a member of a Tenant or a Collective, or the owner of an Entity. This determines whether you can see that Entity and its data and do something with this data or not. If you do not have rights to any Entities, Tenants or Collectives, you won’t be able to view any data. 

re.alto’s customer can have one Tenant on our platform but organise onboarded Entities into various Collectives within that Tenant. This means if Company A is working with various companies/fleet managers, for example, they can onboard the vehicles from various companies and organise each of these into their own Collective, meaning each company/fleet manager will only be able to see the data from the cars in their respective Collective and not the data from cars organised into a separate collective by Company A. Any vehicle added to the Collective later can also easily be viewed without any additional work – that is the power of the Collective. Company A is the owner of the Collective within their Tenant, but they can make Fleet Manager A a member of a Collective and assign them rights within that Collective, so that they can see data from vehicles within the Collective. But they will remain unable to view data from vehicles in the other Collectives within Company A’s Tenant. You have to be a member of a specific Collective to see the data from entities within that Collective – and that is where the domain model meets the security model.