Feature request: be able to use CN/Subject/SAN/whatever into a X.509 cert as the client_id

[dblas]

Hello to all.

Maybe I'm wrong but here it is.

From the broker point of view,
to be able to extract information from the certificate like CN/whole subject/SAN and assign it to the client id with a directive like use_identity_as_clientid.

Advantage?
No need to manage thousands of users when you have thousands of devices. That's really a pain in the ass! Don't understand you tolerate that people.

The use of %c mark in ACL will be sufficient to forbid a client to see other clients' queues and every client will be under the same username.
If I understand right, use_username_as_clientid does exactly the opposite.
db

[ptjm]

How is that different from use_identity_as_username and putting %u in the ACL?

[dblas]

Because doing this way you don't avoid managing usernames.
In a IoT context you manage devices not usernames!
Devices have their own properties, clientID for example and that has nothing to do with usernames which is more a human concept.
Of course, you can merge both in order to identify your devices through an LDAP or a DBMS system but, sincerely, that's insane in a TLS context since you already manage deviceIDs in the CA.
Speaking about AuthN now, it's better to forward the clientID into the AuthN workflows rather than the username.
db

[ralight]

If you're ignoring usernames anyway, combining use_identity_as_username and use_username_as_clientid would first put the certificate details into the username, then second put the username into the clientid.

There is a definite advantage in using clientids rather than usernames in that a clientid must be unique on the broker, whereas usernames could be shared.

[ralight]

Writing this a different way - I think the feature already exists.

[dblas]

Hello and thank you.
I don't think so.
There is a difference between saying that clientid will play the username's role and saying that clientid AND username will play their own role apart.
db

[ralight]

I don't understand what you want the username for. Having a shared username for thousands of devices is basically the same as no authentication at all.

So you have the clients require a certificate, their username and client id are identical and come from the certificate, the username isn't used for anything and your ACLs are defined based on the client id.

Or did you want some different behaviour that requires all clients have the same username for another reason?

[dblas]

In fact I don't want to use the username at all (except if I have to and I think at least 1 user must exist in MQTT).
Why? Because I do not want to have to manage thousands of users in a database (whatever it is an LDAP dictionary or a flat file) since I'll already these users in the CA - I'm speaking about a TLS context -.
That's a double management: adding username on both side and removing it on both side in case of compromission.
Conclusion: in a TLS context I do not want to use the username as an id. This told what do we have that could be used as an id (in MQTT and in a TLS context)? The clientID!
But, in a TLS context, there is no way, as now, to extract it from the certificate.
Of course it's possible to map it onto the username. But, again, you need to declare the username, etc, etc.
For TLS contexts the sole database that should exist would be the CA. That's all. And every device should then be under the same username (since we need at least one).
That's a statement.
Now, it could be useful to use the username for other things: partitionning the devices (by region, by customer, etc).
It could also be useful to integrate the clientID into the same authentication workflow as the username.
That's not my current request: using the same username for all the devices is enough for me.
But, others may have other needs.
db

[ralight]

Thank you for the clarification. I am still convinced that this already exists for you.

Use the config:

listener 8883
certfile <server.crt>
keyfile <server.key>
cafile <ca-for-clients-only.crt>
require_certificate true
use_identity_as_username true
use_username_as_clientid true

Then give your client their certificates. You clients should connect with no username, and no client id. If their certificate is accepted, the broker will extract the CN and copy it to the username of the client, and to the client id of the client. You do not need to manage any usernames. You can use the client id in your ACL.

You do not need to have at least one username.

[dblas]

I think you know better than I do about mosquitto used as a broker AND in a TLS context.
What I see is that we have 2 ids that can be used to identify an object ad that it would be better to consider them apart from each other rather that saying that one can be the other.
That would lead for sure to problems in the future even if I cannot foresee them by now.
Whatever, if you're sure there is no username management needed using these keywords that's fine for me.
You can close the ticket.
Thank you for this great exchange, that was useful. Really;
db