Fine grained authentication system

[cryptk]

This issue is to track the proposal for a fine-grained authentication system to LocalAI. In addition to deciding if we actually want to do this, we need to determine what features it should have. Once this is determined, this will serve as a tracking issue for the various requirements. Here are some ideas that have been tossed around in Discord:

Required initial features:

• Role based access
  • Baked in support for an admin role which can do everything and a user role that can only use models (cannot install from gallery, etc) and an unauthenticated role (can access a very limited set of things, maybe the home page with the swagger docs, health check endpoints, etc).
• API key management (users can have API keys assigned to them, and can re-generate their own API keys if needed)
• Store user data securely within a database, initially sqlite would be a good option.
• This system should be optional, and compatible with the existing API keys system, with those keys being assigned the admin role, keeping them functionally identical to what they are today.

Future goals:

• Custom roles allowing users to define additional roles that users could be assigned to
• OAuth support (this would allow passing authentication off to other systems, for example, goauthentik.io)
• Integration with the in-progress rules engine
• Additional database system support maybe MySQL and/or PostgreSQL.

Decisions that need to be made:

• Do we actually want this?
• What authentication system library should we use (as a rule, we should not implement our own auth, it's almost as hard to get right as encryption):
  • Authboss has modules to cover basically every feature we want, or could want, but it's by far not the only option, and there is a partial list of things we could look at on Awesome Go.
• what database library should we use. I'm personally a fan of sqlc, but there is a partial list of options on Awesome Go
• What other features should it support, are there features currently listed that we do NOT want to support?
• How will the initial admin key be generated (we could just leverage the existing CLI flag/files configs for API keys as those will be admin keys).
• Should the system be opt-in or opt-out (likely opt-in, just like the current API keys system, but we should at least have this be a conscious decision).

We should keep in mind that this would be the first feature utilizing a database, so decisions made implementing this feature will set the standard for how to leverage a database in future updates to LocalAI.

[localai-bot]

Hello cryptk,

This is the bot, an experiment of @mudler. Thank you for opening the issue "Fine grained authentication system" (#2102) in the "LocalAI" repository.

Based on your proposal, let's break down the discussion into different aspects:

1. Initial required features:

   • Role based access: This would include establishing an admin role with complete access and a user role limited to using models only.
   • API key management: Users should have the ability to generate and manage their own API keys.
   • Secure user data storage: A secure database, such as sqlite, would be used to store user data.

2. Future goals:

   • Custom roles: This would allow users to define and assign additional roles as needed.
   • OAuth support: This would enable the passing of authentication to other systems like goauthentik.io.
   • Integration with the in-progress rules engine: This would be an additional feature for future implementation.

3. Decisions to be made:

   • Decide if the project wants to implement this authentication system.
   • Choose a suitable authentication system library. It's recommended to not implement a custom auth system.
   • Determine any other features that should be supported or removed from the current list.

Please let us know what you think about these points and if there's anything else you would like to add. We'll be happy to discuss and come to a decision.

Thanks,
The bot - an experiment of @mudler

[jtwolfe]

related #2046

my vote is to keep it simple for now and work on compatibility, not saying I wouldn't appreciate built-in UAC, but at scale you would externalize that I think
rbac - yes
db - yes maybe
oauth - yes please
web admin interface - god no ;)

[jtwolfe]

related #1869

[jtwolfe]

related comfyanonymous/ComfyUI#3365

this would be quite a big change to implement on both the ComfyUI and LocalAI side but I think this is an example the value of a more complete authentication system.