Describe the feature you'd like and what it will do
Extend the API key model into a new identity type called a service account, representing a non-human user. A service account shares several properties with a regular user account, including an internally generated email and a name, but uses an API key as its primary authentication credential instead of a password.
While a service account is created within and managed by a single parent workspace, it is treated like a standard collaborator, allowing it to be added to one or more workspaces with scoped roles.
Restrictions: Service accounts cannot own workspaces, create other service accounts, or log in via the website.
Why is this feature important?
API keys have several drawbacks that service accounts would solve.
Simpler Authorization Logic: Currently, HydroServer relies on somewhat clunky branching logic to evaluate permissions because API keys and user accounts exist as completely distinct data models with no real overlap in properties. With a service account model that more closely mirrors or even extends regular user accounts, we'd be able to simplify our access control logic.
Cross-Workspace Capabilities: API keys are strictly locked to a single workspace. Service accounts would be treated as first-class collaborators. A single service account can be granted distinct roles across multiple workspaces, enabling cross-workspace workflows such as programmatically migrating or syncing private data from one workspace to another for example.
Better Auditability: Some tools, such as the QC app, require clear attribution data (name and email at a minimum) regarding who or what modified a resource. Service accounts would have an email and name, like a regular account, so attribution wouldn't have to have separate logic for dealing with API keys performing certain actions that require attribution.
Is your feature request related to a problem? Please describe.
No response
Any additional comments?
No response
Describe the feature you'd like and what it will do
Extend the API key model into a new identity type called a service account, representing a non-human user. A service account shares several properties with a regular user account, including an internally generated email and a name, but uses an API key as its primary authentication credential instead of a password.
While a service account is created within and managed by a single parent workspace, it is treated like a standard collaborator, allowing it to be added to one or more workspaces with scoped roles.
Restrictions: Service accounts cannot own workspaces, create other service accounts, or log in via the website.
Why is this feature important?
API keys have several drawbacks that service accounts would solve.
Simpler Authorization Logic: Currently, HydroServer relies on somewhat clunky branching logic to evaluate permissions because API keys and user accounts exist as completely distinct data models with no real overlap in properties. With a service account model that more closely mirrors or even extends regular user accounts, we'd be able to simplify our access control logic.
Cross-Workspace Capabilities: API keys are strictly locked to a single workspace. Service accounts would be treated as first-class collaborators. A single service account can be granted distinct roles across multiple workspaces, enabling cross-workspace workflows such as programmatically migrating or syncing private data from one workspace to another for example.
Better Auditability: Some tools, such as the QC app, require clear attribution data (name and email at a minimum) regarding who or what modified a resource. Service accounts would have an email and name, like a regular account, so attribution wouldn't have to have separate logic for dealing with API keys performing certain actions that require attribution.
Is your feature request related to a problem? Please describe.
No response
Any additional comments?
No response