Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Role Based Access Control / Organization Feature Request #339

Open
precise0 opened this issue Mar 26, 2025 · 0 comments
Open

Role Based Access Control / Organization Feature Request #339

precise0 opened this issue Mar 26, 2025 · 0 comments
Assignees
Labels
assess We still haven't decided if this will be worked on or not enhancement New feature or request

Comments

@precise0
Copy link

Is your feature request related to a problem? Please describe.
Not related to an existing problem this is more of a true enhancement/feature request to create new functionality.

Describe the solution you'd like
It would be very useful to implement true role based access control and the ability to silo samples and results by 'organizations'. We already have groups which are helpful and TLP levels which are great for classifying samples. However additional granular permission control, and the ability to allow certain users to only see samples or results from their own organization would be helpful.

For example, right now if a sample is submitted at a TLP:RED and then that same sample is seen again at a TLP:Clear it will then be visible to lowest classification level. This isn't always the desired behavior and doesn't protect the submissions of other users of the system that may not want their work to be 'public' or available at all to the lower classification levels.

To achieve this, I propose the following new account type: Organization Administrator, this would be assigned to a user along with the Organization that the user should administrate. Assemblyline should retain the Administrator account type to serve as the global context administrator capable of managing Organization permissions. The Administrator account type would have all rights over all Organizations, whereas the Organization Administrator would have rights to their organization.

With this new organizations feature unless configured otherwise a user in Org A couldn't see results or samples submitted by Org B users and vice versa. Ideally there would be a configuration setting, managed by the Organization Administrator account type, to allow organizations to share if they wanted. This would be tied to TLP level as well so for example if Org A wanted to share TLP levels below Amber with Org B the Org admin could configure that or a variation of that concept. There should also be an option to make submissions at a specified TLP level to be publicly available in the larger global context.

Similarly at the global context the Administrator account should be able to set limits for an organization. This should extend to quotas (api, submissions, etc) and roles. In the case of roles, it's more of a bounding set of roles, that the Org admin can assign the members of the Org. These limits should be extended to what services a user within the organization can use as well.

I have included a simplified diagram to describe the vision of a global admin vs. Organization admins and users. I know there was a lot laid out here and it probably doesn't cover all the facets of implementing something like this but I think it would be a desirable feature to add.

Describe alternatives you've considered
We are currently using the groups + classification method however this doesn't achieve the desired separation. And per the disclaimer in Assemblyline groups are not meant for access control.

Image

@precise0 precise0 added assess We still haven't decided if this will be worked on or not enhancement New feature or request labels Mar 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assess We still haven't decided if this will be worked on or not enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants