Skip to main content
Version: Next

Dataspaces in FROST-Server

To configure the dataspace model of the platform in FROST-Server, we group the key entities of the FROST SensorThingsAPI model, e.g. things, into projects. To define the user's access to the entities within each project, users are assigned to project-specific roles. This ensures that data access and manipulation are tightly controlled through role-based permissions, allowing users to interact only with the entities relevant to dataspaces (i.e. projects) they have access to.

How the Platform's Dataspace Concept maps to FROST-Server​

For each Project in FROST-Server, users are assigned UserProjectRoles that define their access to sensors, data streams, and observations in the corresponding project (i.e. dataspace).

  • User: A person or system entity that accesses FROST-Server to manage FROST-Server entities. Users are assigned global and dataspace-specific roles that define what actions they can perform within a dataspace.
  • Project: A project represents a dataspace and serves as a grouping mechanism for all FROST-Server entities. Users must be assigned specific roles within a project to access and manipulate linked entities (see UserProjectRole).
  • Roles: Roles define a user's global permissions (CRUD) independently from projects/dataspaces. For example, the read role grants global read permissions, allowing the user to read all FROST-Server entities (e.g. Thing, Observation) in all projects.
  • UserProjectRole: UserProjectRole allows assigning a user a specific role within a specific project (dataspace), governing their ability to read, write, or manage sensor data streams and related entities in the project.
  • FROST-Server Entities: Core data objects in FROST-Server consist of Things, Sensors, DataStreams, Observations, FeaturesOfInterest, Locations, HistoricalLocations, and ObservedProperties. These elements form the FROST-Server SensorThingsAPI model, which is part of the FROST-Server.

Example for Keycloak and FROST-Server​

The following settings describe the dataspaces named "baumkataster" and "denkmalschutz" defined in Keycloak and FROST-Server:

  • Keycloak client "api-access":
    • Roles for dataspace "baumkataster": baumkataster__read, baumkataster__create, baumkataster__update, baumkataster__delete
    • Roles for dataspace "denkmalschutz": denkmalschutz__read, denkmalschutz__create, denkmalschutz__update, denkmalschutz__delete
  • Keycloak user "Max Mustermann" (max@mustermann.de)
    • User-Role-Assignments: baumkataster__read, denkmalschutz__read, denkmalschutz__create
  • FROST-Server projects: baumkataster, denkmalschutz
  • FROST-Server global roles: read, create, update, delete, admin (default roles, always existing)

If Max requests resource from FROST-Server and therefore logs into FROST-Server (via the Keycloak),

  • Keycloak sends an access_token: (user: max@mustermann.de, roles: [baumkataster__read, denkmalschutz__read, denkmalschutz__create])
  • FROST creates a User: max@mustermann.de (if not already existing)
  • FROST creates three UserProjectRoles: (max@mustermann.de, baumkataster, read), (max@mustermann.de, denkmalschutz, read), (max@mustermann.de, denkmalschutz, create)
  • FROST checks the concrete HTTP request with the created UserProjectRoles.

Mapping illustrated​

The mapping between platform components and FROST-Server’s data model is illustrated in the diagram below, using colors to represent corresponding objects.

FROST-Entities

Setting up Dataspaces in FROST​

Based on the roles assigned in Keycloak, global and project-specific roles are created in the FROST-Server. These roles define the user's permissions within the dataspace, enabling them to interact with FROST-Server's Entities associated with the project (dataspace).

For more information about how to administrate the FROST-Server, please refer to the Admin Guide.