Supported account roles

[nhoening]

Motivation

During our work on #2176 (users creating accounts in the UI), we saw the need to discuss account roles - something we mention in the docs and support in authorization, but we do not yet support specific account roles, as we do for user roles.

I am documenting these thoughts here mainly for documentation. Thoughts are also welcome.

So, about users creating accounts in the UI / API: Obviously, site-admins can do that.
But for others, how should we authorize?

The "Consultancy" role

• First, you should be limited to making accounts that will be clients of your account, no others.
• But who should be able to do this? The current PR uses an account-role (e.g. "Consultancy", at least a test of ours uses that, name can be different), plus you have to have the "consultant" role yourself.

So the site admins would be in control to decide who gets to create clients - by assigning this role to accounts. (alternatively, it could be a boolean attribute on the account - but a role does play better in our authorization framework). As later steps, we can add limits to the number of clients in the account settings, next to other limits we'll need later, like number of daily schedules.

Or should everybody be able to create clients? I don't think so.

Actually, if the Consultancy account role would exist, it could have two use cases:

• Only those accounts are available to be chosen as consultancy accounts for clients (currently, the asset form and API allow all accounts)
• Only members of these accounts can create accounts (aside from site-admins)

Other roles? "MDC" (Meter Data company)

I then thought about other account roles we might want to support. I came to our recent refactoring so that data sources will be account-bound.
Is it useful to support the MDC role (meter data company), thereby enabling dedicated accounts to also add data to accounts where the user's accounts is neither equal to the account of the sensor, nor its consultancy?

Proposed actions

• A PR which improves/introduces account-role handling (with the Consultancy role)

  • let site admins edit account roles in the account editing form. Q: Only supported roles? Free-form? Or can plugins add to the list of supported roles? I believe the latter would be better and fits with the user role handling.
  • The Consultancy role is used for populating the list of potential consultancy accounts in the same form (used when clients are edited). Replaces using the complete list of accounts
  • The second bullet (Only members of these accounts can create accounts) is handled by Feat: Create Accounts on UI #2176 (which also adds the role to the official list already)
  • add some documentation about supported roles

• A PR for supporting MDC account role officially

  • The role is added to the list of supported roles
  • Authorization on asset level is amended to let accounts with this role send data (to be further desribed, we might need to add a relationship account.meter_data_company_id)

[Flix6x]

Only those accounts are available to be chosen as consultancy accounts for clients (currently, the asset form and API allow all accounts)

I like it. It might then make sense to have a db migration to grandfather existing consultancy accounts (those mentioned by other accounts as being ther consultancy) to get the new role.

Q: Only supported roles? Free-form?

I share your preference for only supported roles, extendable by plugins.

A PR for supporting MDC account role officially
Authorization on asset level is amended to let accounts with this role send data

This indeed needs further consideration. For instance, we could limit write permission to only users within the MDC account with some dedicated user role (e.g. meter-data-publisher or just publisher). So then similar to how we give only consultants within consultancies read permission on time series data and write permission on structural data, we'd give only publishers within MDCs write permission on time series data and (?) read permission on structural data.

One limitation of this role-based approach is that it doesn't support fine-grained access rights. For instance, a publisher could write on any sensor in their client's account. That seems like too strong of a permission if you ask me.

[nhoening]

We could limit write permission to only users within the MDC account with some dedicated user role (e.g. meter-data-publisher or just publisher). So then similar to how we give only consultants within consultancies read permission on time series data and write permission on structural data, we'd give only publishers within MDCs write permission on time series data and (?) read permission on structural data.

Probably a good idea.

One limitation of this role-based approach is that it doesn't support fine-grained access rights. For instance, a publisher could write on any sensor in their client's account. That seems like too strong of a permission if you ask me.

How about that MDCs are not assigned to accounts, but to assets?

[Flix6x]

That seems like a decent choice. It's then quite similar too how an asset also has an owner.

So that makes me think of an alternative, which is to just have the asset owned by the MDC altogether. That's similar to how at home your smart meter is owned by the DSO rather than by you the resident. (The smart meter is then still a child asset of the home.) The resident still needs read permissions on the child asset, though.