Add collaborators to all gateways current and future through console

[chamele0nla]

Summary

Would like a way to give collaborators access to any and all current and future gateways through the console. Currently you can add collaborators to applications thereby giving them access to end nodes, but giving access to collaborators to gateways using the console requires adding collaborators one by one to each gateway.

Current Situation

Currently this can be done through cli and scripting, but this is not a workable solution for an environment where we are constantly adding gateways and have multiple support agents that need to view the gateways.

Why do we need this? Who uses it, and when?

Organizations with multiple support agents to end users. We use these on a daily basis. Currently we all have to use the same login which is a security issue.

Proposed Implementation

No response

Contributing

• [ ] I can help by doing more research.
• [ ] I can help by implementing the feature after the proposal above is approved.
• [X] I can help by testing the feature before it's released.

Code of Conduct

• [X] I agree to follow TTN's Community Code of Conduct.

[eggfriedrice]

Hi You can add all your support agents to an organisation, and then simply add the one organisation to each gateway as a collaborator.

If you add everyone in your company to the organisation then they'll be able to see everything. The bonus here is that if someone joins or leaves you can add or remove them from the org once, rather than having to go through each gateway and change the collaborators.

See: https://www.thethingsindustries.com/docs/getting-started/user-management/org/

[chamele0nla]

How do I “simply add” an organization to over 1000 gateways?

Sent from my iPhone

On Aug 2, 2022, at 5:19 AM, Nicolas Mrad @.***> wrote:

 Closed #5633 as not planned.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[adriansmares]

The organization is meant to be added as a collaborator either via Console, CLI or directly using the API during the gateway enrollment, or later on for existing gateways. Since it is not possible to register a gateway without a collaborator, for newer gateways this is basically a no-op (since you would provide the organization as the initial collaborator, instead of a specific user).

Any subsequent access controls (providing new users with access or removing the access of older users) should be done to the organization. In effect, all of the gateways that have the organization as a collaborator will transitively provide access (or remove access) to the newly added organization collaborators.

[chamele0nla]

Yea, so now that I have say 1000 gateways already registered, how do I “simply add” the organization to all of them? Also; how would my technicians register a gateway to our account?

Sent from my iPhone

On Aug 2, 2022, at 8:35 AM, Adrian-Stefan Mares @.***> wrote:

 The organization is meant to be added as a collaborator either via Console, CLI or directly using the API during the gateway enrollment, or later on for existing gateways. Since it is not possible to register a gateway without a collaborator, for newer gateways this is basically a no-op (since you would provide the organization as the initial collaborator, instead of a specific user).

Any subsequent access controls (providing new users with access or removing the access of older users) should be done to the organization. In effect, all of the gateways that have the organization as a collaborator will transitively provide access (or remove access) to the newly added organization collaborators.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[adriansmares]

Yea, so now that I have say 1000 gateways already registered, how do I “simply add” the organization to all of them?

Using the CLI it is possible to manually delete the existing user and set the organization as a collaborator. Note that this is a one time operation - any further add / remove operations from the organization require only editing the organization (you don't need to do it for each gateway).

Also; how would my technicians register a gateway to our account?

Via the Console, the users may choose an organization as the initial collaborator:

Same effect can be achieved via the CLI using the --organization-id flag.

[chamele0nla]

I think you are oversimplifying what needs to be done and not considering how a business with multiple agents would use your product. I don’t see a workable solution here. Your solution seems to keep my agents as the “owner” of new gateways in their account and adding my company/organization simply as a collaborator. Unless I’m missing something.

And again, your solution for managing existing gateways requires scripting / manual work and no real solution for gateways using the console, when you have a very simple and easy console based solution for managing sensors/end nodes. And this was the original request, a simple way to add collaborators to gateways like I can add collaborators to all my sensors/end nodes in 1 simple step

Sent from my iPhone

On Aug 2, 2022, at 8:46 AM, Adrian-Stefan Mares @.***> wrote:

 Yea, so now that I have say 1000 gateways already registered, how do I “simply add” the organization to all of them?

Using the CLI it is possible to manually delete the existing user and set the organization as a collaborator. Note that this is a one time operation - any further add / remove operations from the organization require only editing the organization (you don't need to do it for each gateway).

Also; how would my technicians register a gateway to our account?

Via the Console, the users may choose an organization as the initial collaborator:

Same effect can be achieved via the CLI using the --organization-id flag.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[adriansmares]

Your solution seems to keep my agents as the “owner” of new gateways in their account and adding my company/organization simply as a collaborator. Unless I’m missing something.

There is no ownership concept in The Things Stack - applications and gateways have collaborators, which may be users or organizations. Registering a gateway with the organization as the initial collaborator (or adding the organization as a collaborator later on) has the effect of allowing the members of the organization to interact with the gateway retroactively.

If the users themselves have to lose access to a gateway fleet later on, removing their collaborator status from the organization will immediately cut their access. Similarly, adding an 'agent' as a collaborator to the organization will grant them access to the gateways which have the organization as a collaborator.

When you have a dynamic set of users that may join and leave your deployment, the organizations functionality is meant to act as an access proxy - you don't need to edit anything in individual gateways while adding new gateways or users.

Consider the following situation:

• One organization, example-org with 3 collaborators user1, user2 and user3.
• Two gateways, gateway1 and gateway2 which have the example-org as a sole collaborator.

If you remove user1 from the organization, he will automatically lose access to the two gateways. If you add a new gateway, gateway3, which has the example-org as a collaborator, all 3 users will gain access to the gateway. If you add a new user, user4, as a collaborator to the organization, he will gain access to gateway1 and gateway2 immediately.

For newer gateways there is nothing to be scripted here - adding a gateway with an organization as a collaborator is something that can be done via the Console, and the management of the collaborators of an organization is also possible via the Console. The only friction is indeed the migration of the existing gateways from the 'direct user access' to 'organization access' collaborator usage, but the organizations functionality was what should have been used here in the first place.

[chamele0nla]

Right, but what if user2 needs to a new gateway.. is user2 going to have the organization example-org in his/her account? And if user2 adds the gateway via their account what happens to the gateway when they delete their account?

Also you say there's no "ownership concept" but there's literally a column named "Owned Gateways"

[image: image.png]

On Tue, Aug 2, 2022 at 9:06 AM Adrian-Stefan Mares @.***> wrote:

Your solution seems to keep my agents as the “owner” of new gateways in their account and adding my company/organization simply as a collaborator. Unless I’m missing something.

There is no ownership concept in The Things Stack - applications and gateways have collaborators, which may be users or organizations. Registering a gateway with the organization as the initial collaborator (or adding the organization as a collaborator later on) has the effect of allowing the members of the organization to interact with the gateway retroactively.

If the users themselves have to lose access to a gateway fleet later on, removing their collaborator status from the organization will immediately cut their access. Similarly, adding an 'agent' as a collaborator to the organization will grant them access to the gateways which have the organization as a collaborator.

When you have a dynamic set of users that may join and leave your deployment, the organizations functionality is meant to access as an access proxy - you don't need to edit anything in individual gateways while adding new gateways or users.

Consider the following situation:

• One organization, example-org with 3 collaborators user1, user2 and user3.
• Two gateways, gateway1 and gateway2 which have the example-org as a sole collaborator.

If you remove user1 from the organization, he will automatically lose access to the two gateways. If you add a new gateway, gateway3, which has the example-org as a collaborator, all 3 users will gain access to the gateway. If you add a new user, user4, as a collaborator to the organization, he will gain access to gateway1 and gateway2 immediately.

For newer gateways there is nothing to be scripted here - adding a gateway with an organization as a collaborator is something that can be done via the Console, and the management of the collaborators of an organization is also possible via the Console. The only friction is indeed the migration of the existing gateways from the 'direct user access' to 'organization access' collaborator usage, but the organizations functionality was what should have been used here in the first place.

— Reply to this email directly, view it on GitHub https://github.com/TheThingsNetwork/lorawan-stack/issues/5633#issuecomment-1202509253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQBOWV5WCNC5X5C3FXATS33VXEMNLANCNFSM54H3BWOA . You are receiving this because you authored the thread.Message ID: @.***>

[adriansmares]

Right, but what if user2 needs to a new gateway.. is user2 going to have the organization example-org in his/her account?

The organization is a standalone entity - it does not have an owner. It is created by a user that will be the initial collaborator, and users enter (or leave) the organization. The initial user is not some kind of owner - it is simply the initial collaborator which has full rights over the organization and may add other users as collaborators. It is possible to remove the initial user as a collaborator later on if that is needed.

And if user2 adds the gateway via their account what happens to the gateway when they delete their account?

Nothing happens as long as the organization is still a collaborator to the gateway. The user does not have a 'direct link' to the gateway.

Also you say there's no "ownership concept" but there's literally a column named "Owned Gateways"

The applications and gateways tables refer to the gateways that a user has access to as 'owned' for simplicity reasons. A user which may lack experience expects that after he adds a gateway that he 'owns' the said gateway. I can agree that perhaps 'owned' is not a perfect description when you take into account the collaborators systems, but at the same time 'accessible gateways' is not adding more clarity either.

[chamele0nla]

Ok I just did a quick test. I added a collaborator to the organization and then using that collaborator account added a gateway. It did add the organization and I can indeed see the gateway from the main account. However when I removed the collaborator accounts access they still have access to the gateway they registered. The only way I see to remove their access to the gateway is to remove them as a collaborator on each individual gateway they have added themselves. This would be an issue if they registered many gateways.

Sent from my iPhone

On Aug 2, 2022, at 9:35 AM, Adrian-Stefan Mares @.***> wrote:

 Right, but what if user2 needs to a new gateway.. is user2 going to have the organization example-org in his/her account?

The organization is a standalone entity - it does not have an owner. It is created by a user that will be the initial collaborator, and users enter (or leave) the organization. The initial user is not some kind of owner - it is simply the initial collaborator which has full rights over the organization and may add other users as collaborators. It is possible to remove the initial user as a collaborator later on if that is needed.

And if user2 adds the gateway via their account what happens to the gateway when they delete their account?

Nothing happens as long as the organization is still a collaborator to the gateway. The user does not have a 'direct link' to the gateway.

Also you say there's no "ownership concept" but there's literally a column named "Owned Gateways"

The applications and gateways tables refer to the gateways that a user has access to as 'owned' for simplicity reasons. A user which may lack experience expects that after he adds a gateway that he 'owns' the said gateway. I can agree that perhaps 'owned' is not a perfect description when you take into account the collaborators systems, but at the same time 'accessible gateways' is not adding more clarity either.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[adriansmares]

Did you add the collaborator during registration, or did you add the organization as a collaborator after you registered the gateway ?

Please do note that during gateway registration you have the option to select the organization as an 'owner':

If you do this the sole collaborator of the gateway after you press register will be the organization:

As such, the user will not retain access after he is removed from the organization.

[chamele0nla]

Ok that worked. Thank you. Still don’t have an easy way to add the organization to all the existing gateways.

Sent from my iPhone

On Aug 2, 2022, at 9:53 AM, Adrian-Stefan Mares @.***> wrote:

 Did you add the collaborator during registration, or did you add the organization as a collaborator after you registered the gateway ?

Please do note that during gateway registration you have the option to select the organization as an 'owner':

If you do this the sole collaborator of the gateway after you press register will be the organization:

As such, the user will not retain access after he is removed from the organization.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.