castellum merge requestshttps://git.mpib-berlin.mpg.de/castellum/castellum/-/merge_requests2021-09-21T12:03:45Zhttps://git.mpib-berlin.mpg.de/castellum/castellum/-/merge_requests/2045prevent adding/removing guardians without global change_subject permission2021-09-21T12:03:45ZBengfortprevent adding/removing guardians without global change_subject permissionreplaces !2044
This prevents leaking the subject ID to users who would otherwise not
have access to it.replaces !2044
This prevents leaking the subject ID to users who would otherwise not
have access to it.https://git.mpib-berlin.mpg.de/castellum/castellum/-/merge_requests/1971Expose pseudonym existence2021-07-27T15:33:20ZBengfortExpose pseudonym existenceBased on !1911
With study domains, the participation object gives us information about whether data for a subject exists in this domain. With general domains, there is no such object. That is unfortunate for deletion and export, becaus...Based on !1911
With study domains, the participation object gives us information about whether data for a subject exists in this domain. With general domains, there is no such object. That is unfortunate for deletion and export, because it puts the task on data protection coordinators to check all general domains.
I believe the existence of the pseudonym itself can provide the information because it is created on demand. If data for a subject has been stored with a pseudonym, that pseudonym obviously has to exist. On the other hand, if a subject has never had any relation with a specific domain, it is very unlikely that there was any reason to create a pseudonym. While this is not a perfect match, it can help reduce the workload for data protection coordinators.
So far we do not expose the existence of pseudonyms in the UI. My approach here is to only allow it to few privileged users (essentially data protection coordinators). See also #88
With this change, the condition for subject deletion would no longer be "there are no participations" but "there are no pseudonyms".https://git.mpib-berlin.mpg.de/castellum/castellum/-/merge_requests/1925WIP: two factor authentication2021-06-28T19:24:58ZBengfortWIP: two factor authenticationThis implements two factor authentication based on FIDO2, using the [python-fido2](https://github.com/Yubico/python-fido2/) library.
We could use [django-mfa2](https://github.com/mkalioby/django-mfa2) which already provides large parts ...This implements two factor authentication based on FIDO2, using the [python-fido2](https://github.com/Yubico/python-fido2/) library.
We could use [django-mfa2](https://github.com/mkalioby/django-mfa2) which already provides large parts of the django integration. However, on first glance I had very mixed feelings about the code quality.
Note that FIDO2 is only available in "secure contexts", so you need an https proxy in order to test this. You also need to set the settings `DOMAIN = '{your actual domain}'` and `CASTELLUM_REQUIRE_FIDO2 = True`.
Still to do:
- FIDO2 is probably not feasible for everyone (because it requires expensive hardware keys), so it would be good to provide an OTP fallback. This is also the approach that gitlab and github have taken.
- There is no proper UI to register a key yet.
- General refactoring and polishing.https://git.mpib-berlin.mpg.de/castellum/castellum/-/merge_requests/1549Refactor logging 22021-02-02T11:25:09ZBengfortRefactor logging 2This builds on !1548 and makes some more drastic changes:
- Move the logging config from `settings/default.py` to `example_deployment/settings.py`. This puts the burden of coming up with a useful configuration on the system administrato...This builds on !1548 and makes some more drastic changes:
- Move the logging config from `settings/default.py` to `example_deployment/settings.py`. This puts the burden of coming up with a useful configuration on the system administrators. Monitoring logs will no longer show up in development.
- Remove special handling of `django.server`. The development server is only used in development. Since the configuration was moved to the documentation it is no longer used in development anyway, so this is no longer relevant.
- Remove the separate log file for monitoring and log to console instead. Since the name of the logger is included in the log message you can easily find monitoring messages using `grep monitoring`. Depending on where the logs are propagated to, this might be a privacy issue though.
If this is accepted we need to adapt the documentation.https://git.mpib-berlin.mpg.de/castellum/castellum/-/merge_requests/1480prevent subject enumeration2020-08-05T10:33:20ZBengfortprevent subject enumerationIn !564 we switched from using contact pseudonyms to subject IDs in subject URLs. This was part of a larger refactoring that got us from the confusing early days of castellum to the current structure: Subject management with subject IDs,...In !564 we switched from using contact pseudonyms to subject IDs in subject URLs. This was part of a larger refactoring that got us from the confusing early days of castellum to the current structure: Subject management with subject IDs, recruitment/execution with participation IDs. This also is in line with the concept to use IDs within castellum and pseudonyms when communicating with the outside world.
Using IDs in URLs of course has security implications:
1. IDs are incrementing, so it is possible to derive a rough creation date from it
2. It is possible to enumerate objects, i.e. systematically try numbers to get all object (permissions still apply though)
Both were not considered an issue. Create dates are not secret and enumeration was seen as discouraged but not forbidden.
Recently this came back up and the argument was that while enumeration in this specific case may not be bad, preventing it is not that bad either.
So this is a possible implementation that prevents enumeration. It uses the [query_pk_and_slug](https://docs.djangoproject.com/en/3.1/ref/class-based-views/mixins-single-object/#django.views.generic.detail.SingleObjectMixin.query_pk_and_slug) mechanism which was specifically designed for this. The idea is to use both an ID and slug in the URL. The ID is guaranteed to be unique, but can easily be guessed. The slug does not need to be unique, but is hard to guess. As both are required, the combination is both unique and hard to guess. Note that the ID is still included in the URL, so it still leaks a rough creation date.
The diff is large, but the conceptual change is not that big. It is a bit hard to validate that all subject views actually check the slug though, and this whole effort could be rendered futile by a single faulty view.
I cannot decide if I am for or against this change. It is a really small security improvement at the cost of a small amount of complexity.