Permissions Deconstruction

[zprebosnyak-lm]

Current Behavior

Hello, our team at Lockheed Martin has deployed and been playing with Hyades for a little bit (very cool product!) and we wanted to start a discussion on contributing back some permission updates we have made. Before dropping a giant PR on your team we wanted to make sure we weren't conflicting any of your future work / roadmap you all had in mind. It aligns with the ACL issue we have asked about before. Currently the permissions do not give granular enough control to scope users to different levels of access

Proposed Behavior

Deconstructing the permissions would allow users to be scoped to a role that they fit and align better with the CRUD operations each permission can perform. Below is the proposed permissions deconstruction.

export const BOM_UPLOAD = 'BOM_UPLOAD';
export const VIEW_PORTFOLIO = 'VIEW_PORTFOLIO';
export const PORTFOLIO_MANAGEMENT = 'PORTFOLIO_MANAGEMENT';
export const PORTFOLIO_MANAGEMENT_CREATE = 'PORTFOLIO_MANAGEMENT_CREATE';
export const PORTFOLIO_MANAGEMENT_READ = 'PORTFOLIO_MANAGEMENT_READ';
export const PORTFOLIO_MANAGEMENT_UPDATE = 'PORTFOLIO_MANAGEMENT_UPDATE';
export const PORTFOLIO_MANAGEMENT_DELETE = 'PORTFOLIO_MANAGEMENT_DELETE';
export const VIEW_VULNERABILITY = 'VIEW_VULNERABILITY';
export const VULNERABILITY_ANALYSIS = 'VULNERABILITY_ANALYSIS';
export const VULNERABILITY_ANALYSIS_CREATE = 'VULNERABILITY_ANALYSIS_CREATE';
export const VULNERABILITY_ANALYSIS_READ = 'VULNERABILITY_ANALYSIS_READ';
export const VULNERABILITY_ANALYSIS_UPDATE = 'VULNERABILITY_ANALYSIS_UPDATE';
export const VIEW_POLICY_VIOLATION = 'VIEW_POLICY_VIOLATION';
export const VULNERABILITY_MANAGEMENT = 'VULNERABILITY_MANAGEMENT';
export const VULNERABILITY_MANAGEMENT_CREATE = 'VULNERABILITY_MANAGEMENT_CREATE';
export const VULNERABILITY_MANAGEMENT_READ = 'VULNERABILITY_MANAGEMENT_READ';
export const VULNERABILITY_MANAGEMENT_UPDATE = 'VULNERABILITY_MANAGEMENT_UPDATE';
export const VULNERABILITY_MANAGEMENT_DELETE = 'VULNERABILITY_MANAGEMENT_DELETE';
export const POLICY_VIOLATION_ANALYSIS = 'POLICY_VIOLATION_ANALYSIS';
export const ACCESS_MANAGEMENT = 'ACCESS_MANAGEMENT';
export const ACCESS_MANAGEMENT_CREATE = 'ACCESS_MANAGEMENT_CREATE';
export const ACCESS_MANAGEMENT_READ = 'ACCESS_MANAGEMENT_READ';
export const ACCESS_MANAGEMENT_UPDATE = 'ACCESS_MANAGEMENT_UPDATE';
export const ACCESS_MANAGEMENT_DELETE = 'ACCESS_MANAGEMENT_DELETE';
export const SYSTEM_CONFIGURATION = 'SYSTEM_CONFIGURATION';
export const SYSTEM_CONFIGURATION_CREATE = 'SYSTEM_CONFIGURATION_CREATE';
export const SYSTEM_CONFIGURATION_READ = 'SYSTEM_CONFIGURATION_READ';
export const SYSTEM_CONFIGURATION_UPDATE = 'SYSTEM_CONFIGURATION_UPDATE';
export const SYSTEM_CONFIGURATION_DELETE = 'SYSTEM_CONFIGURATION_DELETE';
export const PROJECT_CREATION_UPLOAD = 'PROJECT_CREATION_UPLOAD';
export const POLICY_MANAGEMENT = 'POLICY_MANAGEMENT';
export const POLICY_MANAGEMENT_CREATE = 'POLICY_MANAGEMENT_CREATE';
export const POLICY_MANAGEMENT_READ = 'POLICY_MANAGEMENT_READ';
export const POLICY_MANAGEMENT_UPDATE = 'POLICY_MANAGEMENT_UPDATE';
export const POLICY_MANAGEMENT_DELETE = 'POLICY_MANAGEMENT_DELETE';

We left the top level permission available. It acts as a catch all to perform any CRUD operation and remain backwards compatible with the current permission set.

We have implemented all the changes in the frontend and API server to test backwards compatibility and that the reactive views in the frontend still work as expected.

Thanks for taking the time to consider this and look forward to discussing!

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[nscuro]

@zprebosnyak-lm Thanks a lot, this is awesome news!

I understood the original issue as a request to integrate object level access control (where CRUD permissions could be assigned to individual projects). Is that covered with the work you did? If not, is that still something you need?

Splitting the existing permissions according to CRUD makes sense to me, and it would not conflict with any future plans. If I understand the proposed changes correctly, it wouldn't even be a breaking change, since existing deployments could continue to function.

Happy to have a look if you'd like to raise a PR.

[zprebosnyak-lm]

@nscuro Great! I will get a PR opened then.

The ACL work from that other issue is not covered here, but ACL work is also something we want to contribute back. Long term goal is to leverage the ACL to scope teams to projects and then the permissions here would allow users to be scoped to different roles within that team. For example, some users in a team can manage access control for only their team. Others may have more developer type permissions such as creating tags or updating information about their team's projects without being able to delete/create projects, etc. The permission deconstruction is just a first step in that direction.