Authenticating and authorizing microservice against nucleus

[brad_f]

I’ve been able to use the info from here:

Is the sdk/runtime for omni.services actually "farm" rather than "kit"?

Hi Brad, Sorry for the delay in getting back to you, things are a little hectic with Siggraph coming up. You are right, the majority of the omni.services extensions are not shipped with the Kit SDK, they used to be but to improve startup and size we have removed them and have been shipping them where necessary (OV Farm, which still uses the Kit runtime but has an additional folder with all of the needed extensions) and in Code. We ideally would prefer you not having to depend on Create, Code …

To get a basic microservice up and running with Kit. Which is great.

I’ve also been able to get basic authentication mechanisms in place as per the documentation here:

Authorization Facility — Omniverse Developer documentation (nvidia.com)

As the docs describe, the basic auth service only really checks for the existence of the header var, it doesn’t check its contents. So it’s not a security mechanism on its own.

Further, the only real implementation of a validation function within the module seems to be one that loads a set of unencrypted keys into memory from a .toml config setting to check against. Which is very basic. It’s more demo code than a useful implementation. And I’d argue, maybe even a security problem.

There are a few options here to pursue. One would be: pass the buck! Just spin up an HTTP Client and authenticate against some other WebAPI somewhere with the token I’ve been passed. Which doesn’t really match my use-case I don’t think.

Another option would be: Connect to a database backend (probably found via the db facility) and check the api key against the User records in there. That’s pretty standard methodology that you’d expect running a DB via DJango or the like. There seem to be plenty of examples of doing that via FastAPI through something like SQLAlchemy. This is do-able of course. But less desirable than some other options. Maintaining multiple parallel auth datastores seems redundant.

In this case, I’d want to be able to authenticate against Nucleus. Especially since Nucleus already uses api tokens. Infact, I kinda expected there’d be an existing implementation for that. And I was surprised it wasn’t there. A second desire would be to also be able to authorize via the same mechanism.

Am I correct in noting that there isn’t an existing implementation for checking an API key against Nucleus from the perspective of a privileged server daemon?

Am I correct in noting that there isn’t real support for implementing such a thing from omni.client right now, because omni.client seems to be written from the perspective of a user, not a trusted daemon with auth responsibilities? Or is there a good way to do it with the existing API?

Somewhere in the docs, I saw a note that Nucleus’ auth database is just a sqlite db. I’m 99% sure I shouldn’t touch it. Presumably, the nucleus server itself has it open and has it (the file) locked. I shouldn’t really be able to open it form a microservice. Or am I supposed to go down that route (I hope not)?

I’ve dug pretty deep into the farm-queue code to see if I can find some kind of implementation there. But I only really found some usage of a setting that reads:

exts.“omni.services.farm.management.jobs.store”.api_key = “change-me”

So maybe I’m looking in the wrong place.

Any guidance would be appreciated.

-brad

[mati-nvidia]

Hi @brad_f. Thanks for continuing to dig into our microservice features and asking great questions. I’ve reached out to the dev team on this.

[jeenbergen]

Hi Brad,

Correct, that authorization facility is mostly for authorization rather than authentication and as you mentioned should definitely not be used in a production environment because of the security implications.

This is mostly an example of the concept of facilities as you could use that authZ facility to prototype your service and when it is ready deploy it into an environment where there is a more advanced solution.
Internally we are hooking this up to NVIDIA’s internal Auth services and we are looking at potentially shipping an Oauth based version later in the year. That is what we are doing internally for Farm.

We are very much of the thought that using existing standards and services rather than designing our own is the right approach and why we are aligning on things like oauth to pass this on and facilities allows you to do this fairly easily by swapping them in and out without having to change the service itself.

Nucleus is currently in the process of exposing API keys that users can consume, I am not 100% on the exact public timeline for this but can inquire about this. We are planning on providing the facilities for this once that becomes available to us.

In omni.client there is a way to intercept the authN callback and inject your own handling of this but the current implementation of omni.client is currently a singleton and so you’d need to make the authN callback request session/context aware which isn’t great. I know that the omni.client team are however working on a different solution there as well as we’ll need this for pretty much any service to talk to Nucleus.

Nucleus does support service accounts and those can be passed to your service via the OMNI_USER and OMNI_PASS environment variables. Also not very secure but is probably the easiest way to get you going for now until the other features go into GA.

Thanks,
Jozef