Support additional authentication mechanisms #113

New Issue

joshuaboniface · 2020-11-25T01:43:33-05:00

JoshuaBoniface commented

2020-11-25 01:43:33 -05:00

(Migrated from git.bonifacelabs.ca)

The simple key-based authentication on the API works fairly well, but more advanced authentication is a good idea for expandability and management within a larger environment, where multiple users and classes of users may require specific permissions.

This feature is twofold:

Implement RBAC into the API, allowing the limiting of different "groups" to different functions. Allow these permissions to be granular and administrator-manageable with some sane defaults. This will likely require a bit of work, but shouldn't require extensive code refactoring and can be built on top of the existing authentication system.
Implement additional mechanisms for authentication, as alternatives to keys. The first one that comes to mind is user + password authentication, but LDAP integration, and potentially some form of OAuth is a good idea too. This is likely the harder, longer part that will involve building an authentication subsystem into the API, of which keys will be only one option.

The simple key-based authentication on the API works fairly well, but more advanced authentication is a good idea for expandability and management within a larger environment, where multiple users and classes of users may require specific permissions. This feature is twofold: 1) Implement RBAC into the API, allowing the limiting of different "groups" to different functions. Allow these permissions to be granular and administrator-manageable with some sane defaults. This will likely require a bit of work, but shouldn't require extensive code refactoring and can be built on top of the existing authentication system. 2) Implement additional mechanisms for authentication, as alternatives to keys. The first one that comes to mind is user + password authentication, but LDAP integration, and potentially some form of OAuth is a good idea too. This is likely the harder, longer part that will involve building an authentication subsystem into the API, of which keys will be only one option.

JoshuaBoniface commented

2020-11-25 01:43:33 -05:00

(Migrated from git.bonifacelabs.ca)

changed milestone to %4

JoshuaBoniface commented

2020-11-25 01:47:00 -05:00

(Migrated from git.bonifacelabs.ca)

mentioned in issue #114

JoshuaBoniface commented

2020-11-25 01:53:26 -05:00

(Migrated from git.bonifacelabs.ca)

At this point I'm leaning towards this being configuration-based, rather than being based in the API, but will have to give this more thought.

Config file

Pros

Simple to deploy
Static
Easy to understand
No CLI integration required

Cons

Difficult to change dynamically/inflexible
Can become obsolete quickly if dynamic config aspects (e.g. #114) change

Dynamic (API-based, in-database)

Pros

Fully dynamic
Reconfigurable via the API/CLI (useful with a WebUI or an authenticated CLI client)
Easier to view and change

Cons

Harder to implement (multiple layers)
Have to deal with storing passwords in the DB
Slightly harder to understand, requires menu system or similar

At this point I'm leaning towards this being configuration-based, rather than being based in the API, but will have to give this more thought. # Config file ## Pros * Simple to deploy * Static * Easy to understand * No CLI integration required ## Cons * Difficult to change dynamically/inflexible * Can become obsolete quickly if dynamic config aspects (e.g. #114) change # Dynamic (API-based, in-database) ## Pros * Fully dynamic * Reconfigurable via the API/CLI (useful with a WebUI or an authenticated CLI client) * Easier to view and change ## Cons * Harder to implement (multiple layers) * Have to deal with storing passwords in the DB * Slightly harder to understand, requires menu system or similar

joshuaboniface commented

2022-10-07 23:39:30 -04:00

I think from a backend perspective, the best solution is the simplest solution.

API keys should remain, and we can define at least 3 discrete roles that any given API key can be given.

First thought for discrete roles would be:

admin: can do everything
user: can do common tasks involving VMs, Networks, and Storage but nothing whole-cluster affecting
readonly: can only obtain data but cannot make changes

From the API perspective this seems like a fairly ideal way of doing things. It keeps management and implementation of the authorization quite simple (a given function would require at most 2 flags) while still providing some good granularity. And any more advanced user control could be implemented in the frontends (specifically, web frontends) using whatever RBAC mechanisms make the most sense.

I think from a backend perspective, the best solution is the simplest solution. API keys should remain, and we can define at least 3 discrete roles that any given API key can be given. First thought for discrete roles would be: 1. admin: can do everything 2. user: can do common tasks involving VMs, Networks, and Storage but nothing whole-cluster affecting 3. readonly: can only obtain data but cannot make changes From the API perspective this seems like a fairly ideal way of doing things. It keeps management and implementation of the authorization quite simple (a given function would require at most 2 flags) while still providing some good granularity. And any more advanced user control could be implemented in the frontends (specifically, web frontends) using whatever RBAC mechanisms make the most sense.

joshuaboniface referenced this issue

2023-02-23 22:46:38 -05:00

Revamp/rewrite CLI client and reogranize #162

Sign in to join this conversation.