Skip to main content
Version: 1.1

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​

For each Project in FROST, 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 to manage FROST 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 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 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 Entities: Core data objects in FROST consist of Things, Sensors, DataStreams, Observations, FeaturesOfInterest, Locations, HistoricalLocations, and ObservedProperties. These elements form the FROST SensorThingsAPI model, which is part of the FROST-Server.

Example for Keycloak and FROST​

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

  • 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 projects: baumkataster, denkmalschutz
  • FROST global roles: read, create, update, delete, admin (default roles, always existing)

If Max requests resource from FROST and therefore logs into FROST (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’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 FROST. These roles define the user's permissions within the dataspace, enabling them to interact with FROST Entities associated with the project (dataspace).

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