Access Control Overview
SSO integration with ACUBETotal
Overview of SSO flow
SSO attempts to allow us to easily protect and introduce authentication to the different services provided by ACUBE. E.g. any service that is accessible via a reverse proxy can utilize the centralized authentication provided by the central authentication server.
NGINX Middleware
Apart from the reverse proxy functionality, we also utilize the different directives that NGINX has, to allow it to act as the middleware for every endpoint. This means that without the cookie, user will be redirected to the SSO login page
Submission flow
There are two ways to submit a sample to CAPE.
- Through ACUBETotal frontend (This would be done using CAPE APIs within a VPC)
- Directly through CAPE frontend
ACUBETotal frontend
When a user submits a sample from ACUBETotal, the sample is not immediately submitted to the sandbox, but is instead handled by the pipeline. When the pipeline submits the sample to the sandbox behind the VPC, it would not have a session token since it is not a user.
So when pipeline submits to sandbox, it would include the username and groups within the body of the request, which would be read by the CAPE API, and the task will be added to the groups accordingly. The rest of the APIs do not need to be edited, as we would not be enabling them.
Sandbox frontend
When submitting from CAPE frontend, CAPE retrieves the session token from the request and sends it to the auth server and receives a JSON response if the cookie is valid.
Sample of a JSON response:
{"user":{"name":"test","email":"test","image":null,"orgNames":["test"]},"expires":"2022-05-10T19:44:06.769Z"}
The username and group_id will be added to the Task table and Group table respectively, with the relation between group_id to task_id stored in the group_task table.
Enabling access control on sandbox
[access_control] turns access control on and filters the tasks shown based on the groups the users are in.
[access_control]
enabled = yes
auth_server = http://xxxxxxx
[display_user] and [display_groups] displays the task submitter and the groups a task belongs to in the recents page.
[display_user]
enabled = yes
[display_groups]
enabled = yes
Notable files
Submission
web/submission/views.py→ Handles the submission and render the submission page on CAPE frontend
web/apiv2/views.py→ Handles the submission from ACUBETotal via CAPE APIs
lib/cuckoo/core/database.py→ Handles all the tables and queries to the database
web/templates/submission/index.html→ Template for the submission page
Filtering
lib/cuckoo/common/web_utils.py→ Added a new function get_user_data_cookies that queries ACUBETotal auth server for user group details
lib/cuckoo/core/database.py→ Filters tasks on different pages, we added a new function access_to_task to check if a task can be viewed by a list of groups
web/analysis/views.py→ Filters the various analysis pages, such as recents, pending and search
web/templates/analysis/ → Contains all the templates for the analysis pages, such as recents, pending and search
API
These are the API endpoints used by ACUBETotal:
File upload → apiv2/tasks/create/file/
Task status → apiv2/tasks/status/
Task report → apiv2/tasks/get/report/ and /tasks/get/screenshot/
We would disable all other APIs in api.conf as we are not using them. Additionally, we have disabled access to the CAPEv2 admin page in web/web/urls.py.
When clearing the database in sandbox, use utils/cleaners.py --clean. This would clear both the postgres and mongoDB databases, together with all the analyses and binary files of the tasks. Double check if you need to keep the pyc files, and comment out the part that deletes it in cleaner.py if necessary.