Feature suggestion: ACL username wildcards or regexp?

[arrowcircle]

Hi! I thought about wildcards for usernames in ACL and it looks like a good idea for me.
Example ACL looks like:

user abc_XXXX
pattern read abc/XXXX/#

In this case only one ACL entity is generated for a group of users (clients) inside abc prefix.
Is it a good idea?

[cmnstmntmn]

@arrowcircle not sure if this is what you're looking for, but
you can have wildcards to target the username %u or the client id %c

https://docs.vernemq.com/configuring-vernemq/file-auth#authorization

pattern write sensor/%u/data

[arrowcircle]

@cmnstmntmn as I understand, this is only for one user. My approach is about multiple users, which usernames start with abc_

[cmnstmntmn]

@arrowcircle did you manage to find a solution to this?

[larshesel]

Hi @arrowcircle I'm not sure yet I fully understand your idea. Could you show some examples of how this would work?

[arrowcircle]

@larshesel Idea is to use broker for multiple projects with static ACL and external user auth.
For example, I want to have 2 projects: ABC and CDE.
I have http API, that can handle authentication of users. I can send ACLs with auth data, but it will insert ACL for each user. I want to add one static ACL for all users of project ABC like in example

user abc_XXXX
pattern read abc/XXXX/#

[larshesel]

ok, so I think I understand: based on the username prefix the patterns/rules with that prefix applies are selected?

I don't think it's something we'd prioritize building as this seems (to me) a bit too specific for most use cases - anyway if this can be built in a simple and easy to understand way I guess we might accept this as a contribution? What do you think @dergraf @ioolkos

[jadbaz]

I think there's a use-case for this
This would help in reusing the same broker for multiple domains

[ioolkos]

@jadbaz While this is not possible with the file based ACL file, what you do in other plugins is entirely up to the plugin. That is you could match on ClientID prefixes by adapting the Lua scripts, or by implementing your own plugin hooks or WebHooks.

Also note that domain separation can sometimes be done by using different mountpoints (that is 1 mountpoint per domain).

[jadbaz]

We were hoping to do authorization based entirely on username and turn off authentication completely
We would rely on certificate common names for that (used as username)

[jadbaz]

Thanks again @ioolkos
While plugins add a lot of flexibility, they add the burden on the developer to write, maintain, scale etc...
I don't think domain separation by username patterns is a very special use case.
Akamai Edge Connect has support for such a use case.
Checkout Akamai Edge Connect auth documentation:

Once the car has been authenticated and the client ID is known, it’s time to determine the proper authorization groups. By just connecting, a device can be part of an authorization group. In this example, the device is a car, so all cars connecting will get the authorization group “car”. Additional groups can be extracted from the certificate, just as they can from the client ID. For example, a variety of groups can be extracted from our car’s VIN.
In this case, we already know the manufacturer because the manufacturer has already validated the client. But the brand and year can also be extracted from the certificate/VIN. In this case, the car would be assigned the authorization group “B-BH” (which stands for “Brand=BH”) and the group “Y-M” (which stands for “Year=M). Additionally, other fields that may present features can also be extracted and converted into groups. Assuming we extracted information out of some other field and determined that the car was a premium package with a navigation system, the car’s device-based authorization groups would be something like: car, B-BH, Y-M, NAV.

Is it possible this can be added to the roadmap?

[ioolkos]

add the burden on the developer to write, maintain, scale etc...

Jep, I know that one, for some reason 😄