Who is using the per application user authorization / can it be deprecated?

I’m interested to learn if people are using the per application user authorization. This feature allows to give specific users access to specific applications, instead of access to all applications within an organization.

For a current feature I’m working on, I’m running into the issue that this feature would either add a lot of extra complexity or would limit me in the way I would like to implement this new feature. Therefore I’m thinking of deprecating this per user application access feature.

(In the past the per user application access feature was implemented since there was no such concept of organizations. Then we added organizations (with per user organization access) and kept both ways of giving users access to these resources).

1 Like

That will be interesting.

On different note, when are you going to release lora 1.1 compliant network and app server.

That will be interesting.

That doesn’t really answer my question :wink:

On different note, when are you going to release lora 1.1 compliant network and app server.

That is not really what this topic is about :wink: Also there are no LoRaWAN 1.1 specs available yet.

Hi. I’m not using it right now and I’m not sure I’ll need it in the future, but for months now all my work is being done in a forked version so I can live with changes like that (if we do end needing the feature, I can always reimplement it). That said, I’m more interested in what you are working on that need the deprecation. Care to share?

Hello Orne,

In my view the notion of organizations and user authorization per application is useful mostly for commercial users where there could be a need for such features. I remark “could be a need” because even on corporate networks with thousands of end points, the management of the network (the issuing of keys and alike) will still be handled by a one or two persons, probably in the IT department. And they will have admin rigths anyway…

Furthermore, if somebody (probably a corporate user) needs such a feature, can always contact you to ask for commercial support on the matter.

So, if you are interested in my opinion, just drop the feature.

NB.: Perhaps some limited functionality could be retained on the API access, but this is just vague idea, I really don’t know how difficult this would be to be implemented.

Drop it, avoid complexity, focus on what is really needed. Migration script or procedure would be appreciated, I’d the one is needed.

1 Like

I personally think “per application user authorization” is an excellent feature. im Praying you may leave as it is and maybe later develop it further. The feature is good for commercial deployment. Also one of the features which actually makes our use this software.

Cmon, pray for souls of the dead and keep the ground. Can you breakdown your requirement in detail?

Hello,

I agree with the following:

Which means @brocaar can at least make some income after spending so many months of his valuable time in this project. If someone needs this feature, she/he can always ask commercial support from him, I am sure he will be able to provide the necessary customization services.

Well, if there is an organization at the top that is fine to me.
I’d be more interested in the possibility to have one network per organization.

Yesterday I secured completely my mqtt server, including lora-app-server users auth (previously I was using websockets with the jwt token to check who could listen to incoming data), and It reminded me about this topic.

For now, mqtt is secured by acls on /application/app_id/node/+/+, where a user is associated with an application in order to be granted privileges on those topics. Of course, if application/user association went away, it could just be replaced by organization/user association to secure this, with topics like /organization/org_id/application/+/node/+/+.

The thing is then applications become just a superfluous grouping of nodes, with no actual use in their current state. In fact, they can be ditched and nodes could relate to organizations only. But then again, some versions ago there were no organizations, only applications, which are effectively the same if only one of them exists.

So I’m guessing it’s the hierarchy of associations that mess with the desired feature (still intrigued). If so, is there anyway we could help you with the implementation? If not, are you considering “reverting” and ditching organizations instead of applications (makes more sense because it means less work), or are you planning on just leaving applications as a grouping without authorization? Just an opinion, but I think it is better to just leave one relevant grouping (call it organization, application or whatever) that authorizes users, and whatever other grouping and authorization needs someone should encounter (it can get arbitrarily complex, like organization -> application -> location -> room, etc.), is left as a task for the user to implement.

Thanks for all the feedback. I’ve decided to remove the application users. For some this might be bad news, however it removes a lot of complexity that would else slow me down in going forwards. Please see for the latest release (just released):

It still provides authentication on a per organization level (and this functionality will stay :slight_smile: ).

Please note that you could also implement your own version of LoRa App Server in case you need customized functionality like different layers of authentication.

The thing is then applications become just a superfluous grouping of nodes, with no actual use in their current state. In fact, they can be ditched and nodes could relate to organizations only.

Please note that you can setup per application HTTP integrations. Also in the new version, the application is linked to a service-profile. In the future an application will also define how the payload of these devices will be decoded into meaningful data.

1 Like

Hi, Orne.

Remember to modify the mqtt auth documentation to account for this change (https://docs.loraserver.io/install/mqtt-auth/). Specifically, the acl query should change from:

auth_opt_aclquery select distinct 'application/' || a.id || '/node/+/+' from "user" u left join organization_user ou on u.id = ou.user_id left join organization o on o.id = ou.organization_id left join application_user au on u.id = au.user_id left join application a on au.application_id = a.id or a.organization_id = o.id left join node n on a.id = n.application_id where a.id is not null and u.username = $1 and $2 = $2

To something like this:

auth_opt_aclquery select distinct 'application/' || a.id || '/node/+/+' from "user" u left join organization_user ou on u.id = ou.user_id left join organization o on o.id = ou.organization_id left join application a on a.organization_id = o.id left join device n on a.id = n.application_id where a.id is not null and u.username = $1 and $2 = $2
1 Like

Yes, you’re completely right. I forgot about that. Will fix this this week :slight_smile: The query would not fail with the latest version as the update does not drop the tables (yet).

Yep, it doesn’t fail because both tables are still present, though of course it doesn’t secure mosquitto correctly, as it relies on a deprecated association and refers to nodes instead of devices. But those are just docs anyways, easy to fix and not that critical.

In a similar note, the Downlink Queue API still uses the /api/nodes/devEUI/action convention, instead of /api/devices/devEUI/action (though the internal/api implementation does use the Device Queue model). Is this deliberate or just a missing change? Also, Node and DownlinkQueue almost preserve their names on the API side (both file names, node.proto and downlinkQueue.proto, remain the same, though the former exposes the Device service, while the latter still exposes the DownlinkQueue service), but change to Device and DeviceQueue on the storage side. Is this kind of a transition thing, or will they remain to be like that?

Yep, it doesn’t fail because both tables are still present, though of course it doesn’t secure mosquitto correctly, as it relies on a deprecated association and refers to nodes instead of devices. But those are just docs anyways, easy to fix and not that critical.

Fixing it right now :slight_smile: (I was in France the past days for a conference + visiting a company)

In a similar note, the Downlink Queue API still uses the /api/nodes/devEUI/action convention, instead of /api/devices/devEUI/action (though the internal/api implementation does use the Device Queue model). Is this deliberate or just a missing change?

Good catch! I need to fix that :slight_smile: Regarding the file names, I kept them the same (and will rename them later) as these changed had been in development for quite a while in a separate branch and it would cause a lot of merge conflicts if I would have renamed them.

@iegomez I just released 0.14.1 with a couple of fixes and cleanups. Including your findings. Please let me know if you spot more naming inconsistencies :slight_smile:

Great! Thanks, Orne.
I’ll keep checking while I merge and let you know about any findings. :wink:

1 Like

EDIT: See next message.

I found one more case: at the ui, NodeStore not only keeps the file and class name, but also points to /api/nodes/… for some cases, particularly the DownlinkQueue ones, which are also missing name changes. Also, though some functions correctly point to /api/devices/…, their names remain like createNode, updateNode, etc., even in new ones such as those involving nodeKeys.

Of course, this means that all calls to the store’s functions from other places should be refactored, and file names and classes (e.g. class and file CreateNode) too.

I forgot that the DownlinkQueue frontend bits were not part of the original lora-app-server, but custom views I implemented some time ago, so that may be omitted. So really what needs some work is file, classes, store and methods naming conventions, which keep referring to Node instead of Device.