Data model and access

Netilion Extension Platform permission concept

For the NEXT platform a new Netilion permission concept was introduced. The goal is to allow access to customer data with the explicit approval of the customers. It is designed for application access to provide additional services in the Netilion ecosystem. It allows fine grained access control, while keeping the scope of different tenants separated.

Netilion Addons

The permission concept is build on the existing addon concept. Addons are features that can be bought over the Netilion subscription and enrich the features of Netilion. Previously only the purchasing process of new features was handled with addons. Now they serve as anchor for the delegation of access rights to the backend applications. Users can assign data to the addons and therefore allow the applications implementing the feature to access this data. Currently either nodes or assets can be assigned directly to the addon. To assign other Netilion objects, the permission hierarchy of Netilion can be used. First the object can be assigned to a node and then the node to the addon.

Addons are like contracts with the customer. Every customer will have an addon with unique addon_id that documents that the customer bought the addon.

Netilion Platform Extensions

The applications implementing the features of the addons are called Platform Extensions. In Netilion applications are represented as “client_applications”. With a client_application one can configure technical users and the access to the netilion API. With the Platform Extensions a client_application can be configured to get access to the data that is assigned to an addon.

The data access is not directly granted to the technical user. The technical user of the Platform Extension can request access tokens to the addons that are scoped to the addon.

API access

With the configuration of a Platform Extension you will have a technical user with access to the Netilion API. To get access to the addon context of a user subscription, you will need to know the addon_id of the customer.

Get addon_ids as list

There is an endpoint to request a list of all addon_ids the technical user of the Extension has access:

GET {Netilion-API}/v1/extension_addons

The response is an array of objects that have the addon_ids as content. It is an array because the technical user can be used for multiple Platform Extensions and Platform Extensions can be connected to multiple addon references.

[
    {
        "extension": "name-of-extension",
        "external_reference": "addon-reference",
        "addon_ids": [
            22021,
            21413,
            21414,
            21488
        ]
    }
]

Get addon_id over Kafka events

If the Platform Extension is configured to receive values or other webhook events, the addon_id is part of the message.

Get access token with addon_id

With the addon_id the technical user of the Platform Extension can request an access token:

POST {{netilionCore}}/v1/access_tokens
// body:
{
    "add_on": {
        "id": 22021
    }
}

The token in the response then can be used to access the data which is connected to the user addon.

{
    "access_token": "<token>",
    "token_type": "Bearer",
    "expires_in": 660
}

To get more information about the user, also the subscription information can be queried with the token

GET {Netilion-API}/v1/subscriptions/