Sharing many distributed account streams with a server-side account

[brettinternet]

I have a "server account" in my Go server that I want to publish and consume messages from thousands of accounts (distributed IoT devices with multi-tenancy). With a URL account resolver or embedded NATS server, it's easy to import the "server account" into each distributed IoT device account JWT. However, to support streaming to the "server account", it's a little more cumbersome to import every single account public key into the "server account" JWT.

Am I approaching multi-tenancy correctly by having a "server account" on my server interface with thousands of accounts through export/imports? Is there a better way to support authentication and authorization with multi-tenancy?

[brettinternet]

My understanding of a system account is that it's not designed for this. My concept of a "server account" is distinct from this.

[derekcollison]

On approach is to reverse and have the server account export a single service that all new accounts import. Just means that when a new account sends to it the other side will respond for pure fire and forget, but makes management easier at those scales.

[brettinternet]

Thank you for the reply, Derek. Is it true then that the distributed accounts can publish on the imported stream? I had supposed they couldn't. Or does the agent reply to the server accounts inbox?

Does this look right to you at all?

serverAcctClaims.Exports.Add(
	&jwt.Export{
		Subject: "$JS.API.>",
		Type:    jwt.Service,
	},
)

distributedAcctClaims.Imports.Add(
	&jwt.Import{
		Name:         fmt.Sprintf("$JS.%s.API.>", organizationID),
		Type:         jwt.Service,
		Account:      serverAcctPK,
		Subject:      "$JS.API.>",
		LocalSubject: jwt.RenamingSubject(fmt.Sprintf("$JS.%s.API.>", organizationID)),
	},
)

And then the consumer would be on the agent side, but I'm not sure how it would response for "pure fire and forget" quite yet. If you have a Go test file or something else I could examine for this flow, that might help.

[derekcollison]

Publishing to a stream requires a response, so perfect for an exported service from the server account vs a stream export from the new account that forces an updated to the server account to import each new account.

[brettinternet]

Ah, I think I see what you mean now. If I understand you correctly you're suggesting a service like this on the server where the request is initiated by the agent: https://natsbyexample.com/examples/messaging/request-reply/go OR https://natsbyexample.com/examples/services/intro/go

I was able to get this to work. Thanks!

// server account export
serverAcctClaims.Exports.Add(
	&jwt.Export{
		Subject: "toserver.>",
		Type:    jwt.Service,
	},
)

// agent import
agentAcctClaims.Imports.Add(
	&jwt.Import{
		Name:         "server",
		Type:         jwt.Service,
		Account:      serverAcctPK,
		Subject:      jwt.Subject(fmt.Sprintf("toserver.%s.>", orgID)),
		LocalSubject: "toserver.>",
	},
)

// server
nc.Subscribe("toserver.>", func(m *nats.Msg) {
	fmt.Println("Received a message:", string(m.Data), string(m.Subject))
	res, _ := json.Marshal(ServiceResult{Message: "hello from server"})
	m.Respond(res)
})

// agent
msg, _ := nc.Request("toserver.fromagent", []byte("hello from agent"), 10*time.Second)
result := decode(msg)
fmt.Println("message!", result.Message)

type ServerResponse struct {
	Message string `json:"message"`
}

func decode(msg *nats.Msg) ServerResponse {
	var res ServerResponse
	json.Unmarshal(msg.Data, &res)
	return res
}

[derekcollison]

If you are trying to publish from a new account to a "central" account, you can export a stream from the new account, or export a service from the "central" account.. But services expect responses..