Global data authorization
What is global data authorization?
Global data authorization is a terminology used to indicate that the integrator, when the integrator is authorized, can access the data supplied by the data endpoint but that the returned data can be restricted by the global data authorization.
This is a widely used concept that is crucial for most of the SCALAR customers and is mainly used to restrict the assets that can be returned to a specific integrator. An example is that for a big organization the integrator only gets access to a part of the assets (and not to the full range of assets).
Not all SCALAR data endpoints support global data authorization and per product (and per data endpoint) it will be clearly marked if data authorization is enabled or not. The reason why not all SCALAR data endpoints support this concepts is because it is not always relevant.
Global data authorization concept in SCALAR can be both used to restrict data access to an integrator or a user.
Assignees & teams - How does data authorization work?
SCALAR support today data authorization on three key business resources:
| Business resource | Description | Purpose |
|---|---|---|
| Assets | An asset is the trackable item. Mostly this is a commercial car, truck, van, bus, trailer, ... | Only give access to the selected assets that an integrator can see/manipulate. |
| Drivers | A driver is a resource that drives the asset and on which all data is collected about the driver. | Only give access to the selected drivers that an integrator can see/manipulate. |
| Places | A place is a POI with a geofence connected to it. | Only give access to the selected places that an integrator can see/manipulate. |
Each integrator or user gets assigned to assets/drivers/places he needs to see/manipulate. In this way, you restrict the data that an integrator can access/manipulate. The class 'assignees' steers exactly this behavior and defines who can see/manipulate the business entity.
The action to assign is a privileged action which can be set by the product Teams. The assignment can be done via the ZF | SCALAR portal or via SCALAR API endpoints.
How to assign a business resource to an integrator or user?
Each business resource (e.g. asset) has a property called 'assignees'. Assignees define who can get access to the business resource. The assignees property class has three properties that steer the visibility of the selected business resource.
Assignees property:
| Option | Resource | Effect |
|---|---|---|
| Option I - Business resource can be seen and manipulated by everybody | "assignees": { "all": true } | Every user or integrator can see the business resource. No restrictions |
| Option II - Business resource can only be seen by some selected users or integrators | "assignees": { "userIds": "h-0": "Optio } | Only the specified users (user 1 and user 2) or integrators can get access to the business resource. All the rest cannot see the business resource. |
| Option III - Business resource can only be seen by some selected teams | "assignees": { "teamIds": "h-0": "Optio } | Only the specified teams (team 1 and team 2) can get access to the business resource. All the rest cannot see the business resource. A team is nothing more than a group of users and/or integrators. |
| Option IV - A combination of option II & III - business resource can be seen by some selected teams and by some individual selected users | "assignees": { "userIds": "h-0": "Optio, "teamIds": "h-0": "Option" } | Only the specified teams & users can get access to the business resource. All the rest cannot see the business resource. |
What is a team?
A team is nothing more than a group of users and integrators. It is used in the assignees concept as it makes the administration when new assets/users come in or get transferred to use teams. Moving a user from one team to another team in combination with using teams in assignees can change visibility rights with one simple action of moving the user from one team to another.
See product Teams.
Use cases
There are a lot of possible use cases that really make this a valuable feature. By no means is the given set of use cases a full comprehensive list but it is rather to spark the mind of the developer to put the concept to the best use for the setup of the organization.
Use case 'restrict view for a 3rd party - fixed list':
The developer would like to give an integrator token to a 3rd party but only to a limited set of assets that the 3rd party is allowed to see.
Use case 'restrict view for a customer-like party - variable list':
The developer would like to give an integrator token to a 3rd party but only the assets that will deliver goods to him today. This list will change frequently and every day the assignee list is change to reflect which assets will deliver goods to him.
Use case 'high valuable transportation':
The developer only wants to give a view on people & integrators working in the highly secured chain of high-valuable transport. Only screened authorized users & integrators can see & manipulate these assets.
Use case 'Share data with a data party but only assets that were agreed upon':
The developer would like to give an integrator token to a data party that further process the data but only the assets that were agreed (maybe the asset can be a limited set of asset driving for a specific part of the business).
Updated 5 months ago