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

Make visibility of auto-approval toggle configurable based on confidentiality #1221

Open
anushka-singh opened this issue Apr 25, 2024 · 4 comments · Fixed by #1223
Open

Make visibility of auto-approval toggle configurable based on confidentiality #1221

anushka-singh opened this issue Apr 25, 2024 · 4 comments · Fixed by #1223

Comments

@anushka-singh
Copy link
Contributor

Is your idea related to a problem? Please describe.
Users should be able to disable visibility of auto-approval toggle with code. For example, at our company, we require that shares always go through approval process if their confidentiality classification is Secret. We dont even want to give the option to users to be able to set autoApproval enabled to ensure they dont do so by mistake and end up over sharing.

Describe the solution you'd like
Add config in config.json and make changes in dataset import, create and edit forms.

P.S. Don't attach files. Please, prefer add code snippets directly in the message body.

@anushka-singh
Copy link
Contributor Author

AutoApproval480p.mov

Check the video for a feature demo.

@anushka-singh
Copy link
Contributor Author

Note:
Additionally, on the backend we have code to validate “auto_approval_for_confidentiality_level” value for Secret confidentiality. This is to ensure that if someone uses a proxy or curl command and sets the value auto_approval_for_confidentiality_level=true for the confidentiality level, in the backend side we still wont run the auto-approval workflow.

Would recommend anyone using this feature to use the following code to manage the backend side. I have not included it in the PR since this is only needed if one of the auto_approval_for_confidentiality_level is set to false. We keep all of them true by default.

Change in share_object_service.py https://github.com/data-dot-all/dataall/blob/main/backend/dataall/modules/dataset_sharing/services/share_object_service.py#L288

if dataset.autoApprovalEnabled: --> if dataset.autoApprovalEnabled and ConfidentialityClassification.get_confidentiality_level( dataset.confidentiality) != ConfidentialityClassification.Secret.value:

  • Instead of using ConfidentialityClassification.Secret.value use whatever confidentiality you want to disable.

@dlpzx dlpzx added this to To do in v2.5.0 via automation Apr 29, 2024
@dlpzx dlpzx removed this from To do in v2.5.0 Apr 29, 2024
noah-paige pushed a commit that referenced this issue May 1, 2024
…ased on confidentiality (#1223)

### Feature or Bugfix

- Feature


### Detail
- Users should be able to disable visibility of auto-approval toggle
with code. For example, at our company, we require that shares always go
through approval process if their confidentiality classification is
Secret. We dont even want to give the option to users to be able to set
autoApproval enabled to ensure they dont do so by mistake and end up
over sharing.

Video demo:
#1221 (comment)

### Relates
- #1221

### Security
Please answer the questions below briefly where applicable, or write
`N/A`. Based on
[OWASP 10](https://owasp.org/Top10/en/).

- Does this PR introduce or modify any input fields or queries - this
includes
fetching data from storage outside the application (e.g. a database, an
S3 bucket)?
  - Is the input sanitized?
- What precautions are you taking before deserializing the data you
consume?
  - Is injection prevented by parametrizing queries?
  - Have you ensured no `eval` or similar functions are used?
- Does this PR introduce any functionality or component that requires
authorization?
- How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  - Are you logging failed auth attempts?
- Are you using or adding any cryptographic features?
  - Do you use a standard proven implementations?
  - Are the used keys controlled by the customer? Where are they stored?
- Are you introducing any new policies/roles/users?
  - Have you used the least-privilege principle? How?


By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
@noah-paige
Copy link
Contributor

Pending a follow up PR for backend changes before closing this issue

@noah-paige
Copy link
Contributor

Hi @anushka-singh @TejasRGitHub - following up on this issue, I believe there may still be some work on the backend for this issue to handle input validation / not allowing autoapproval for the specified confidentialities in config.json

Is this to be picked up by you all? / Would this be a part of #1261 and can close this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants