Possibility to provide auth-ID pattern as tenant configuration

With introduction of auto-registration feature there’s possibility to configure device-id pattern, which is used during device registration process, see: #2664.

I think it would be also helpful to provide similar configuration for auth-id which is created during device registration process and used for device authentication. Currently auth-id for certificate based device authentication completely corresponds to subject-DN of device certificate.

I’ll try to explain it with the help of one example:

The client certificates of devices in the field can be renewed and updated. The renewed certificates can contain some changes in subject-DN, e.g. the department name is changed. In such case subject-DN of the client certificate will not be similar to the subject-DN from the old certificate. And when such device will try to connect with a new certificate the authentication will fail as auth-id (subject-DN) registered in Device Registry will not match with auth-id (subject-DN) from the new client certificate.

In such case it would be helpful to provide possibility to configure which parts from Subject-DN should be used for auth-id, which are not affected and changed by certificate renewal and stay stable and unique during the whole lifecycle of the device.

See below examples of possible auth-id patterns:

auth-id-pattern: "{{subject-CN}}" -> only use the subject CN from the device certificate

auth-id-pattern: "{{subject-DN}}" -> use the subject DN from the device certificate

WDYT?

[kaniyan]

With the former I disagree. FMPOV the opposite is true, i.e. when a new certificate is being issued to the same device, then the values for the place holders actually need to be identical to the values that were used when the device was (auto-)registered. Otherwise the auth-id determined for the device when it authenticates would not match the registered auth-id anymore, would it?

I disagree too for the first point. The values of the placeholders should remain the same.

@kaniyan Looks like we had already established the fact that the auth-id template must not be changed after registration.

Tried to make it resilent to template modifications. After analysis and considering the changes involved, it seems that we go ahead with the constraint. In future, if it has any practical disadvantages, we can still go back to the analysis that we discussed in #2968.

[b-abel]

when a new certificate is being issued to the same device, then the values for the place holders actually need to be identical to the values that were used when the device was (auto-)registered.

Sorry, my bad. That is what I actually wanted to say. I just messed up the sentence to say the exact opposite. I’ll fix it.