Clashing when creating a device and a gateway with the same ID

[cdupont]

When creating a gateway, and then a device with the same ID, the gateway resource created in Keycloak gets overwritten. This leads to authorization problems afterwards.

For example, in this image the ID of the resource is gateway-00155d00641b (in the URL), which identifies it as a gateway. But the data in the resource corresponds to a device.

[cdupont]

When creating the device resource in Keycloak, a POST is performed with the name of the resource=MAC address. It seems that Keycloak uses the name to find the existing (gateway) resource and overwrite it.
For legacy reasons, Keycloak IDs for devices are randomly generated by Keycloak upon creation (instead of using a fixed ID such as "device-00155d00641b"). This Keycloak ID is then stored in a field "keycloak_id" in the device structure in the mongo DB, for future references.
Using Keycloak IDs prefixed with "gateway" or "device" would solve the problem: #20 .
However this requires a complex data migration.
A quick fix could be to give different names to devices (not only the MAC address).

[cdupont]

Keycloak works a bit strangely regarding ID/names. Both ID and names are unique and can be used to identify a resource.

• POSTing a resource without an ID will return a randomly generated ID
• POSTing a resource with an ID will use this ID (if unique).

But POSTing a resource without an ID and the same name as a previous resource will update that resource.

[cdupont]

This is the current status regarding IDs and names:

	Devices	Gateways
Mongo	ID = A KC_ID = X	ID = A
Keycloak	ID = X name = A	ID = gateway-A name = A

Permission: resourceName=A

In this example, both a device and a gateway share the same Id A.
In devices, for legacy reason the Keycloak ID is generated randomly (X) and stored as a field KC_ID = X in the device structure in Mongo.
On the opposite, for gateways the Keycloak ID is given after the device ID: gateway-A. Thus we don't need to store it in the device structure in Mongo.
The Keycloak name gets the device ID A directly for both. This causes the clash.
The permissions uses the Keycloak name as the resourceName. This allows to compare permissions for both devices and gateways.

[cdupont]

1. change device creation for using Keycloak ID = device-A.
2. change all KC names for name = device/gateway-A
3. change Permission resourceName=A. This requires some case analysis:

• if Keycloak ID begins with device/gateway-A, take A.
• If not, take the name (legacy case).

The target case is:

	Devices	Gateways
Mongo	ID = A KC_ID = device-A	ID = A
Keycloak	ID = device-A name = device-A	ID = gateway-A name = gateway-A

Permission: resourceName=A

This solves the name clash problem. The legacy devices are still supported: the Keycloak ID can still be recovered using the KC_ID field. The permission checking works as before.

After the data migration, the KC_ID field will be removed, and the permission resourceName analysis will be simplified.

[cdupont]

Done: https://github.com/Waziup/waziup-api/tree/KC_ID