Creating dynamic permissions within an account JWT in Go

[brettinternet]

I have an account resolver that gets the account JWT by the public key. I'm trying to implement dynamic permissions so I don't have to update the user JWT.

// URL account resolver looks up the account JWT by public key
akp, _ := nkeys.CreateAccount()
askp, _ := nkeys.CreateAccount()
ac := jwt.NewAccountClaims(publicKey)
ac.SigningKeys.Add(aspk)
ac.Tags.Add(fmt.Sprintf("org:%s", org))
ac.DefaultPermissions.Pub.Allow.Add(
	"$JS.{{tag(org)}}.API.>", // dynamic tag permission not working here ❌
	"$JS.hardcodedOrgID.API.>", // does work ✅ (issue with scoped key implementation?)
)
return ac.Encode(akp)

The dynamic tag doesn't appear to work. I believe it needs to be a scoped signing key, but I'm still stumped after reading through the nsc source and trying to implement:

ac := jwt.NewAccountClaims(publicKey)
ac.Name = myacct
ac.SigningKeys.Add(aspk)
scope, _ := ac.SigningKeys.GetScope(aspk) // signing key's public key
if scope == nil {
	scope = jwt.NewUserScope()
	scope.(*jwt.UserScope).Key = aspk
	scope.(*jwt.UserScope).Role = "myrole"
	scope.(*jwt.UserScope).Template.Limits.Subs = -1
	scope.(*jwt.UserScope).Template.Limits.Payload = -1
	scope.(*jwt.UserScope).Template.Limits.Data = -1
	scope.(*jwt.UserScope).Template.Permissions.Pub.Allow.Add(
		"$JS.{{tag(org)}}.API.STREAM.UPDATE.>",
	)
}
ac.SigningKeys.AddScopedSigner(scope)

Am I missing something?

[brettinternet]

I found a test which helped me debug this issue:

nats-server/server/jwt_test.go

Lines 4388 to 4398 in 60589da

	kp, _ := nkeys.CreateAccount()
	aPub, _ := kp.PublicKey()
	claim := jwt.NewAccountClaims(aPub)
	aSignScopedKp, aSignScopedPub := createKey(t)
	signer := jwt.NewUserScope()
	signer.Key = aSignScopedPub
	signer.Template.Pub.Deny.Add("denied")
	signer.Template.Pub.Allow.Add("foo.{{name()}}")
	signer.Template.Sub.Allow.Add("foo.{{name()}}")
	claim.SigningKeys.AddScopedSigner(signer)
	aJwt, err := claim.Encode(oKp)

I found some limitations with the templating that I'll document here.

The culprit of my issue was having a template function in the stream name. For example, my stream name was "MYID-test" where jwt.Name = "MYID", which required publish permissions for "$JS.{{account-name()}}.API.STREAM.UPDATE.{{name()}}-test". The subject tokens are split by "." in the template function, so I believe using template functions in a stream with another value is impossible:

nats-server/server/auth.go

Line 469 in 89b042d

tokens := strings.Split(list[i], tsep)

Something else I noticed is that tag values result in lowercase values despite the original casing. I was using a ULID which is typically uppercase.

Thanks!

[aricart]

@brettinternet scoped signing keys allow you to have additional macros on the templates associated with the signing key:

• subject() - id of the user in the JWT
• account-subject() - the id of the account
• tag() - a tag in the user JWT
• account-tag() - a tag in the account
• name() - name of the user in the JWT*
• account-name() - name of the account in account JWT*

(*)name() and account-name() shouldn't be used in subject building constructs - if the process creating the JWT adds a space to these values, it could create difficult to diagnose issues (like subscriptions that don't seem to work - they do they are just using the subject up-to-the space, and inadvertently use a queue group with the remainder.

Instead if you want to permission, you should be attaching to subject() and account-subject()

With that said, tags in JWT (account, user, etc) are lower-cased in JWT, so if you have some application id, this must be lower case in the tag.

For the $JS.API you are using, you shouldn't use account-name/name() for sure.

[brettinternet]

I see, thank you for the warning. I'll switch to use tag() and account-tag() to build the subjects with my application IDs instead.