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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: