Combination with MQTT and OGC Sensorthings API Standard

[paulau]

Hallo.

I find it very nice, how you incorporate the split of Data between users.

My Questions:

• Schould it also work with MQTT. If Yes, could acocrding docker-compose.yaml be also included into projekt?
• Will this Authentification be someday included into "OGC Sensorthings API Standard"

Thanks, Kind regards, Pacel

[hylkevds]

Currently the Read restrictions do not work in MQTT. Reason for that is that security checks in MQTT happen when a user subscribes, so the individual messages are not security-checked. So if a user can subscribe to v1.1/Observations, this user will receive all Observations.

To solve this we'll have to come up with a way to limit which topics a user can subscribe to.

We do plan on writing a longer security section for STA version 2, but I'm not sure it will go this much into implementation details. That may be more for a best-practice.

[paulau]

Thank you for response.

We do not use MQTT now to receive Observations/Messages.. But we definitely need it to use Tasking. To transfer events in Database to physical devices. There will be apparently the same problem. If it is resolved for observations, then it can be similarly resolved for tasks.

Another question, about use of Multi User-Functionality for Frost: Example of Data is given in your dataBatchPost.json If I request the Data from Frost Server(http://localhost:8080/FROST-Server/v1.1/Things) as user AdminProject1 in basic authentification, then  I should only see the things, which belong to Projects of  AdminProject1. In reality I see all things also, which belong to Project2.  Did I do something wrong? Or is it so? Would it be correct to show to user AdminProject1 only things, which belong only to his projects?

One more question:  I can use Batch requests in Web-Form: http://localhost:8080/FROST-Server/ But, it does not understand Syntax with Symbol "$" like   "$AdminProject1" or "$project1".

How can I really execute the batch request dataBatchPost.json? So that the subscribing client substitutes the id of project1 instead of "$project1"?

Thanks, Kind regards,Pavel

[paulau]

Would it be the possible solution:

To allow subscribtions to "/Datastreams($id)/Observations", but to switch completely off subscription to all "/Observations".

Also question: Would it be additional effort to implement Multiuser for tasking? Or would it work authomatically?

Greetings, Pavel

[hylkevds]

This demo does not limit requests to Things. secThings only defines Create, Update and Delete restrictions. It's not intended to be a finished, fully functional example.

In a Batch request, "$project1" is replaced with the ID of the entity created in the request with the id project1. See 11.2.2. Referencing new entities in a change set example in STAv1.1. Batch requests must be posted to v1.1/$batch. For JSON-Batch requests, the content type of the post must be set to application/json.

The MQTT security issue is not just with /Observations. The issue exist for every entity type. Since the details of the read-checks can be different for each use case, which topics are allowable must be fully configurable. For those allowable topics, FROST will have to check if the user that tries to subscribe can actually read that path. Currently it doesn't yet. Of course, the goal is to have something that works for all entity types, including tasking and tasks.

[paulau]

Thank You. Question: will this project be continued and brought to "fully functional example"? If yes, then when would we have chance to expect it to be ready? If yes, would every user see only his own things or also things of other users?

Thank You, Pavel

[hylkevds]

There are no plans to change this example project, unless a customer needs it. If you need support with implementing fine-grained authorization rules for your use case, we offer support contracts.