Features of the OMAP

This page lists some important features of the OMAP platform.

User Management and Single-Sign-On

The platform uses Djangos well known User Management. For production usage we recomment the usage of a more scalable solution like Keycloak. Any OAuth2 capable provider is suitable but single-sign on is crucial when one wants to use services that run under another web context like Monitoring.

We strongly distinguish Authorization and Authentication.

Authentication is the process of ensuring a User is who he claims to be (by checking his password). This step is delegated to the OAuth2 provider.

Authorization means to provide each User the proper rights to do only the actions he or she is allowed to do and only see the appropriate data. As an example consider the creation of a new Asset which should normally only be done by users with elevated rights. The whole authorization process is done in Django and based on the OMAP data model.

Asset Management

Besides users and user management another core functionality of the platform is the management of assets. Assets can be all kind of things, not just machines. Other examples are robots or other inventory used together in a production context.

Assets use UUID s as primary keys so they can be shared easily between separate instances. As assets are at the heart of the OMAP they contain a many properties that are used throught many apps. There is even to possibility to share an asset between separate Organizations where each organization has another role, e.g. one is the producer, one is the owner and so on.

Customer Management

The third crucial component of the OMAP is the management of customers. In many situations emploees of the customers are also users (thats what the platform is for!).

End to End (E2E) Encrypted Messages

End to End Encrypted messages or telemetry values are a rather new feature of the OMAP. The idea is, that some telemetry values can be encrypted by the edge device before being send to the platform. Then, the values can be consumed by another application or user on the platform and are then decrypted. So the operator and owner of the platform can technically never read the values.

Why can such a feature be useful? Its an approach towards zero-trust. Producers may be uncomfortable by sharing sensible data like concrete production numbers with any third party. But in scenarios like e.g. progressive payment models like pay-per-use they may have the need to share the data with a bank or any other financial provider. In this scenario E2E telemetry comes in handy. As the Machine Owner can be sure that only he and the receiving party, the financial provider can access and understand the data and the operator of the platform cannot read or modify the data in any way.

In the OMAP E2E is implemented based on the OLM / MEGOLM protocol used in popular open source messaging solutions like Signal and Matrix. The OLM Algorithm is based on the Signal Protocol developed initially by Trevor Perin and Moxie Marlinspike at OpenWhisperSystems.

A major difference between a messaging protocol and the telemetry use case is that handshakes are not possible or at least very rarely possible. Thus, we base the E2E on the MEGOLM algorithm which was developed for securing group chats over the matrix protocol and needs no handshakes but only the secure transmission of a secret key.

Edge to Cloud Messaging

tbd