You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Emo currently stores all rules in a flat namespace. This has worked well under the assumption that a single user, the administrator, is responsible for managing and assigning roles. However, the current move is toward a delegated administration system, where the administrator can create trusted API keys which themselves can create roles with limited permissions and assign those to API keys (see #63). To support this each API key must have a safe sandbox for creating and managing roles; it would be dangerous to have a flat all-or-nothing system where any user with permission to update roles could update any role in the system.
The issue being documented here is a perquisite to the permissions aspect. There should be the ability to group related roles by a common namespace. With this in place it would be possible to grant an API key permission such as "manage roles in namespace X" or "assign roles in namespace X". This way the API key would have a safe sandbox for role administration without permission to manage or assign roles outside of that sandbox.
Risk
By itself the ability to group roles by namespace is low. The riskiest aspects of this change are:
Ensuring backwards compatibility with existing role permissions and/or an upgrade/migration procedure which can be performed with no downtime.
Ensuring that roles with the same name in different namespaces do not collide.
Level
Medium
Issue Checklist
Make sure to label the issue.
Well documented description of use-cases and bugs.
The text was updated successfully, but these errors were encountered:
What is the Issue?
Emo currently stores all rules in a flat namespace. This has worked well under the assumption that a single user, the administrator, is responsible for managing and assigning roles. However, the current move is toward a delegated administration system, where the administrator can create trusted API keys which themselves can create roles with limited permissions and assign those to API keys (see #63). To support this each API key must have a safe sandbox for creating and managing roles; it would be dangerous to have a flat all-or-nothing system where any user with permission to update roles could update any role in the system.
The issue being documented here is a perquisite to the permissions aspect. There should be the ability to group related roles by a common namespace. With this in place it would be possible to grant an API key permission such as "manage roles in namespace X" or "assign roles in namespace X". This way the API key would have a safe sandbox for role administration without permission to manage or assign roles outside of that sandbox.
Risk
By itself the ability to group roles by namespace is low. The riskiest aspects of this change are:
Level
Medium
Issue Checklist
Make sure to label the issue.
Well documented description of use-cases and bugs.
The text was updated successfully, but these errors were encountered: