@Rich I have run into effectively the same problem, but I think I have determined the reason/cause.
Either there is either a flaw with the automatic provisioning system, or I am severely missing something!
So I’m using an X.509 cert to spec, with a unique CN (Common Name) comprising a UUID, guaranteeing uniqueness. The provisioning handshake works as expected, with each derivative X.509 cert (with a unique UUID) being validated by the master X.509 cert in the “Auto provisioning” screen.
After the provisioning handshake, OpenRemote creates a ServiceUser, a copy of the Asset, and links the Asset to the ServiceUser, as expected.
But that’s where the good news comes to an end.
So in the X.509 authentication, the following all must be true:
- The MQTT ClientID must match the X.509 CN (Common Name), which in this case is a UUID
- The 2nd MQTT topic parameter must match the ClientID ( {realm}/{clientId}/writeattributevalue/{attributeName}/{assetId} ) as per User Guide: Manager APIs · openremote/openremote Wiki · GitHub
- The 2nd MQTT topic parameter must ALSO match a ServiceUser in the corresponding Realm in order to be granted the necessary permissions to access the permitted Asset or Attribute. (“…authentication requires a ‘Service user’ username and secret”, [same link as in #2](User Guide: Manager APIs · openremote/openremote Wiki · GitHub, first paragraph)
Step #3 is where the problem is. Yes, OpenRemote generates a ServiceUser in the corresponding Realm, and assigns the newly created Asset to the ServiceUser…BUT! When generated, the ServiceUser’s name is prepended with “ps-” (https://github.com/openremote/openremote/blob/d07cc300538028eaab285100f8a3e9da0769dd92/manager/src/main/java/org/openremote/manager/mqtt/UserAssetProvisioningMQTTHandler.java#L312 with reference to https://github.com/openremote/openremote/blob/d07cc300538028eaab285100f8a3e9da0769dd92/manager/src/main/java/org/openremote/manager/mqtt/UserAssetProvisioningMQTTHandler.java#L107)
This means that step #3 results in the OpenRemote authenticator failing with “User: {realm}:{user} does not have permission=‘SEND’ on address {MQTT topic}”.
Result: it’s impossible for an X.509 automatically-provisioned field MQTT device to be able to actually access its OpenRemote Asset!
(If the Assets are manually configured per each device, then this is not a problem. But “manual != automatic.”)
I banged my head against the wall for several hours trying to figure this out, as the auto-provisioning MQTT handshake with the X.509 was working correctly–but no matter what, any attempt to write to the corresponding Asset Attribute would result in OpenRemote terminating the MQTT connection and popping the above error into the logs.
Finally, I manually created a ServiceUser (as the auto-generated ServiceUser name field is disabled and cannot be edited) with the direct UUID (i.e. the X.509 CN). Then I set the appropriate permissions (well, in frustration, this was “full write”, same as on every other ServiceUser and Asset)…and voila, if the “writeattributevalue” Publish didn’t go right through for the first time in forever, and OpenRemote didn’t kick the MQTT client off.
Interestingly (and fortunately!) the auto-generated Secret for the ServiceUser does not seem to matter: the MQTT connection username/password used are the ones for the auto-provisioning ServiceUser (as we do have to go through the X.509 authentication sequence anyway).
Am I missing something here?
