Application level user rights

Hi Orne,

  1. What do you think about further providing organization admins, to give application level rights to users (read / write)? This way, devices (grouped by application) can be separately managed by different organization users.
    Of course I could add different organizations for every user but then
  2. I have to repeatedly recreate gateways, service profiles and device profiles for every organization which would be almost the same for every organization / application.
1 Like

I would support finer grained access controls. I have people who I would like to give more than readonly access to, but not admin rights.

Now the question is: Is an application level access control sufficient for a start or should it be generalized to all kinds of entities from the beginning ? Personally I am ok with just the application rights. The rest could be managed by an organization admin.

I do understand the use-case, but for now I would not see this as a priority. Something like this existed in the past, but I remember that it made the authentication / authorization code a lot more complex (also in terms of maintainability).

For now I just want to discuss a possible design without any intention to prioritize any implementation efforts and I do not have plans for an immediate implementation. Depending on which requirements might be implemented together it is probably advisable to first evaluate useful changes regarding the authorization functionality in app-server.
And first I would just wait for others to participate so that more perspectives might introduce further aspects that weren’t considered by us so far.

Some thoughts:

  • Are there more requirements and access modes than just simple read/write.
  • How fine grained should this access be. Up to which detail level.
  • How should this be reflected in the RestAPI: Since some values in a rest api call might require several different authorization rights on the properties in the call to be valid before it is accepted / the request is authorized.
  • API keys: Does it make sense to limit api keys in the same way as users’ rights.
  • Data sharing and isolation on several layers like integration: Would it make sense and if so how to derive authorization for certain data in app-server to be reflected in an integration. This is mostly affecting the global broker config since app-level integrations are already separated.
  • Do just a simple static extension to the current authorization model or consider maybe a dynamic and extensible one ?
  • Minimize complexity and maximize maintainability, so that the authorization model easy to understand and use and will not result in inadvertently data leaks by misconfiguration and future code changes do not require too much depending changes.
  • decision: keep it simple or provide a future rich authorization ?

Personally I like it to keep it simple and minimize the implementation effort, to not blow it up out of proportion. I’d like to try to extend the current model with a minimal amount of code change to have read/write access on application level.