Design feedback for user auto-creation

[tardisx]

Hi all,

I'm new to NATS, and I've a limited amount of background with similar systems (MQTT, RabbitMQ).

I'm building a fairly traditional-looking client/server system, with many "edge" client nodes (running in untrusted end-user environments). Traditionally I'd just use something like REST over HTTP, but I can see the advantage of using NATS for everything (especially after reading https://nats.io/blog/nbn-building-natster/ ), even if I don't leverage much of what it enables in the first instance.

I'm looking for feedback on my approach to make sure I'm not "holding it wrong".

Any user can download the software and run it. I'd like to be able to (for low friction) automatically create a unique id for each new instance (perhaps a client-supplied UUID) so they can start using the system at some level, and have "fully" authenticated users which have more access.

My research so far leads me to think I can:

• use the auth callout to implement my own auth, including auto-creation of users
• use the same callout to authenticate "real" users
• use the permissions system to ensure those users can only access the subjects that they should

Is this approach sane?

I have done a little poking at the API, and one immediate question I have is that when I receive a message for a subscription (https://pkg.go.dev/github.com/nats-io/nats.go@v1.36.0#Msg) there does not seem to be any way to get the user that sent the message. Would this be usually be done by including it in the payload, and using the permissions system and appropriate subject paths to ensure that users could not spoof data for a different user?

[derekcollison]

Depends on how you "provision" new users of the system. You can use the NATS cli in operator mode to add users as part of the flow when onboarding. Meaning you might not need auth-callout..

[tardisx]

I’m intending the nats server to be embedded in the backend directly, doing auth against a postgresql database. The initial incoming nats client connection would be the first contact with the user, auto provisioning a (highly limited) user at that point.

I’d rather not maintain two user db’s, if possible.

[derekcollison]

Users are not centrally stored, they are simply presented on connection to a NATS server. That server needs to resolve the signing account and that account has to be from one of the operators the server trusts.

That all being said, yes you can have auth callout layer interface with the DB.

[brettinternet]

I'm still not too sure I understand auth callout, but how about this method: #3004 (comment)?

1. Provide the client installer with unique token (perhaps a split token to prevent timing attacks)
2. Register the client to your own endpoint with the token and a client generated public key (see nkeys library if you're using Go)
3. After client registration is complete, connect to the NATS server with client nkey and user JWT from registration
4. Implement URL account resolver or have your server push JWTs to the NATS server for account multitenancy

[gedw99]

Hey @brettinternet

this repo helped me heaps with nats auth callout. I think it will help you too.

https://github.com/jr200/nats-iam-broker/

it’s got create docs too explaining it all .

[brettinternet]

Thank you for sharing this!