Allow Anonymous

[WilliamBradee]

As a integrator of legacy application I want to use go-auth with blank username and password so that I can support passing credentials in the Client ID.

In a legacy application the authentication information is carried in the client ID and username/password are blank.

MQTT does allow authentication without username/password.

Mosquitto config already has flag "allow_anonymous"

Proposal: add flags :

• "auth_opt_allow_anonymous" true/false
• "auth_opt_anonymous_username"
• "auth_opt_anonymous_password"

Change code at https://github.com/iegomez/mosquitto-go-auth/blob/5dc063f1041b94dd67ededf47f79fa58b0968c68/auth-plugin.c line 90

if (username == NULL || password == NULL) { printf("error: received null username or password for unpwd check\n"); fflush(stdout); return MOSQ_ERR_AUTH; }

Consider the config. If auth_opt_allow_anonymous is true and auth_opt_anonymous_username/password are set, replace NULL username and password with auth_opt_anonymous_username/password. If auth_opt_anonymous_username/password are not set, replace NULL username and password with "anonymous". If auth_opt_allow_anonymous is not set or is false, keep current behavior.

[WilliamBradee]

The username/password are to avoid having anonymous/anonymous as an attack vector. So maybe simpler and safer to have: auth_opt_anonymous username password

So you HAVE to provide values, and have only one flag to configure.

[iegomez]

How are the credentials being passed in the client id for checking? If we allowed anonymous users but don't correctly define the client id checking for this case, then we might effectively allow access to resources that might not be supposed to be accesible.

But maybe I'm missing something, so if you can provide a full fledged example I can take a look into it.

[WilliamBradee]

The client ID has the credentials, for instance, copied from link, Object Key with suffix example: apikey:7021e880-f2ad-56e8-b482-3340ef03a4bf:my-client-103df

OAuth Token with suffix example:

bearer:BzlLgdFpfj2ChLSBsZmgyK46tV1cA0bK:my-client-104df

In effect, the apikey/bearer is the password and the "my-client" part is the user name.

the username/password is ignored, and in this case, not sent. The device lacks ability to set these to dummy values.

Question is -- is it a generally useful thing for other users, or an edge case? I could modify and build my own version, passing "null" for username and password (as long as clientId is not null), and let my authenticator take care of it. In general case null/null will not be valid username and password and will be rejected. I picked "anoynmous" before base on mosquitto flag, but "null" is more descriptive.

[iegomez]

Thanks for the explanation, I think I get the case better now: if we allow anonymous users, we'll set their username and password to fixed ones provided by the conf options. Then you'll use some backend that allows you to forward the clientid to your user defined authenticator, e.g. an HTTP service or the JS interpreter, and extract username and key/token to check upon it. You'll be losing the ability to check super users as that only deals with username, but maybe that's fine for your case. The expectation would also be that any other configured backend would fail to auth an anonymous user because there won't be any record/rule/etc. allowing access (or there'll be something explicitly denying it) to this predefined username/password combo for the anonymous users.

Is my understanding correct?

[WilliamBradee]

Yes I think you get it. If an authenticator wants to use ClientID to embed username/password, allow username and password to be null.

And do it the simplest way possible. It didn't occur to me, but can you just pass NULL down the stack and let the authenticator deal with it? and will MQTT's flag "allow_anonymous false" provide the same filter anyway? So only if someone sets "allow_anonymous true" will NULL for username and password even get to the plugin.

I am thinking I can build this and try it first. And my need is transitory (will be fixed in eventual firmware update) so if it doesn't fit in the spirit of the project, I get it.

[iegomez]

Iḿ sorry, I absolutely lost track of this issue. Is this something that's still worth pursuing, @WilliamBradee?

[WilliamBradee]

No I built a custom version to handle this situation.

---

From: Ignacio Gómez @.> Sent: Friday, February 17, 2023 12:55:16 AM To: iegomez/mosquitto-go-auth @.> Cc: BRADEE, WILLIAM @.>; Mention @.> Subject: Re: [iegomez/mosquitto-go-auth] Allow Anonymous (Issue #240)

Iḿ sorry, I absolutely lost track of this issue. Is this something that's still worth pursuing, @WilliamBradeehttps://urldefense.com/v3/__https://github.com/WilliamBradee__;!!BhdT!jYWZ7JzM1ZMAZlLSsdxQT9azOD91gjw-VzmVn0Kv0vI986WC02HvjzbTHAqdK_z6RUvx41VbxBtPydJZyNS4E9U$?

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/iegomez/mosquitto-go-auth/issues/240*issuecomment-1434176750__;Iw!!BhdT!jYWZ7JzM1ZMAZlLSsdxQT9azOD91gjw-VzmVn0Kv0vI986WC02HvjzbTHAqdK_z6RUvx41VbxBtPydJZo6CkQyM$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABJK5EJCOC7QOD54NAJFTC3WX4OFJANCNFSM556H7UVQ__;!!BhdT!jYWZ7JzM1ZMAZlLSsdxQT9azOD91gjw-VzmVn0Kv0vI986WC02HvjzbTHAqdK_z6RUvx41VbxBtPydJZYreMmFM$. You are receiving this because you were mentioned.Message ID: @.***>

[iegomez]

Cool, thanks for your response.