Apikey on device level does only effect outgoing traffic

[tstorek]

Hi,

It took me a while to figure this out, but I still don't see any reason for this design decision.
Please, help to understand.
As documented for changing the API key we have three options in the IoT-Agent:

1. adjust the default API key in the Agent (this is a global setting and not really interesting)
2. create a service_group (This will change the API key for all attached devices)
3. adjust the API key on the device level (This only adjusts the API key for the outgoing traffic (commands), for all incoming traffic the next level above is used)

The docs say only this, but it does not really help:

All the topics subscribed by the agent (to send measures, to configuration command retrieval or to get the results of commands) are prefixed with the agent procotol, /json in this case, followed by APIKey of the device group and the Device ID of the device involved in the interaction; i.e.: there is a different set of topics for each service (e.g: /json/FF957A98/MyDeviceId/attrs). The API Key is a secret identifier shared among all the devices of a service, and the DeviceID is an ID that uniquely identifies the device in a service. API Keys can be configured with the IoTA Configuration API or the public default API Key of the IoT Agent can be used in its stead. The Device ID must be provisioned in advance in the IoT Agent before information is sent. All topis published by the agent (to send a comamnd or to send configuration information) to a device are not prefixed by the protocol, in this case '/json', just include apikey and deviceid (e.g: /FF957A98/MyDeviceId/cmd and /FF957A98/MyDeviceId/configuration/values ).

I do not find it intuitive that the last option (device configuration) only affects the outgoing traffic.
I was thinking about for quite a while now, but this does not appear reasonable to me and it is definitely not what a user would expect. The lower level configuration (device) should always overwrite the level above.

Even from a security point of view, this does not have any advantages. Just think of a scenario where a service_group API key would be stolen. This would affect all other devices as well for incoming traffic. And you even have no chance to make it more secure based on the APIKEY only by using the device_id as well. However, the latter would make the APIKEY obsolete.

Hence, this should maybe be changed in the next version because it is quite annoying that you have to create a service_group even if you maybe have only one device in it.

[tstorek]

I now also found the related section in the nodelib
https://github.com/telefonicaid/iotagent-node-lib/blob/master/doc/api.md#relationship-between-service-groups-and-devices

But even from that i would expect a different behavior. @fgalan is this related to the agent or the library. Please feel free to move the issue there.

[mapedraza]

@fgalan is this related to the agent or the library. Please feel free to move the issue there.

Yes, as you indicated, this is related withe the iotagent-node-lib, since the behavior is the same for all the IoT Agents using the library. I just transfer it to the iotagent-node-lib repo.

Even from a security point of view, this does not have any advantages. Just think of a scenario where a service_group API key would be stolen. This would affect all other devices as well for incoming traffic. And you even have no chance to make it more secure based on the APIKEY only by using the device_id as well. However, the latter would make the APIKEY obsolete.

The idea behind of this is to provide a service group once (usually you provide it for an specific manufacture/integrator), and then, it is possible to add devices with the same APIKEY automatically when data arrives to the IoTA (this functionality is called autoprovision). In case of the APIKEY stolen, you just need to change once the device group APIKEY (and also, on the devices).

[mapedraza]

I am going to explain you a bit of history to put you in context how IoTA works with service groups and devices.

At the beginning, the IoTA agent was operating in a different way than it does today.

• There was the information contained on the service group, containing, among others, the APIKEY
• There was the information contained on the device provision, containing, among others, the device ID and entity ID

Merging both, we have all the information to store the data from the measurement.

With this scenario was quite simple, flexible and powerful. But there was some problems. You need the APIKEY when sending a command through MQTT (the topic contains the APIKEY), and also, since you have a common service group in which you can define the commands of all devices on a group. And the way chosen to include a device within a service group was the APIKEY.

And... why APIKEY is not mandatory for devices?, because backward compatibility reasons (previously provisioned devices did not have it). So, the usage of the APIKEY in the device is not like a real APIKEY with all the functionalities, it is just needed to reference the service group. That is the reason why service groups are mandatory and the APIKEY on device level is useless at incoming traffic.

Even if it is hackable, the recommended scenario while using the IoT Agents is:

1. To have a service group for each APIKEY you want use
2. Create a device ID that contains the parameter APIKEY with the value of the APIKEY of the service group attached.