Understanding the different authentication types

Besides the secret that was mentioned in the previous article, a plugin has to authenticate the user that is trying to retrieve data from it. When a plugin is accessed, Luzmo sends authentication information to that plugin. Depending on the type of authentication you have selected, different fields can be expected.

Currently, there are three different types of authorization:

The authentication type will automatically generate another UI when a Luzmo user in your Luzmo organization tries to create a connection to that plugin via the New Dataset button.

For authentication type 'None', this screen is bypassed, they will immediately be forwarded to the dataset selection screen. The security properties that your plugin will receive depending on the endpoint and the chosen authentication type (below example is with authentication type = custom and properties key, token & host specified) are:

Where the /exchange endpoint is only relevant for the oauth2 authentication type.

Override security for embedded dashboards (Advanced)

This part is only relevant if you are embedding a dashboard and are building a plugin which will be called by the embedded dashboard. In that case, the users are users of your platform and might never log in to Luzmo. In such a scenario, the authentication options described above are only relevant for the person who will be using the plugin to create the dashboards.

In that case, there are even more security options available. To be clear, we are talking about the scenario where:

• Someone of your company has already added the plugin to Luzmo (with a specific authentication type)
• A connection to the plugin was created (either via the UI as shown above or via the API).
• A dashboard was built on top of the datasets from that plugin.
• The dashboard was embedded in the company's platform using a token.

For an embedded dashboard, the connection was probably made by one of your employees, and by default, those security rules will be applied. However, in the embedded dashboard scenario, the token that was used to securely embed the dashboard can be augmented with extra security rules or the authentication mechanism can be altered dynamically. From the moment you call your plugin from an embedded dashboard, you can either override values of these authentication mechanisms or define your own.

There are different options:

• don't add anything: the users of your platform can see the same as you did while you were dashboarding.
• add filters: at the moment you create a token, you can add row-level security by generating a token. In that case, your users will only see the data that matches that filter.
• add metadata: for an embedded dashboard, you have the option to add metadata to a token (e.g. user id, a temporary JWT token, etc). Your plugin will receive the metadata that was placed on the token and you can create your own security mechanism.
• dynamically select a different plugin to call

Below image shows an example of the properties that can be overridden by tokens in red (below example is with authentication type = custom and properties key, token & host specified), and added examples of extra properties which can be used in an embedded scenario.

There is a multitenancy blog post that explains this in more detail.