Half-baked pseudonym service
The original pseudonym service (as implemented in !85 (merged) and documented in !101 (merged)) was designed as a separate entity within castellum. The idea was not to use the full model interface but to use a limited set of helper functions instead. There were several reasons for that:
- interoperable: We wanted to be able to eventually replace it with 3rd party services such as mosaic gPAS
- generic: The service should be able to handle a lot of different scenarios.
- DB split: We wanted to be able to optionally store pseudonyms in a separate database to protect them from administrator access
- security in depth: By enforcing limitations on a lower level we wanted to ensure that security properties would not get lost in the complexity of the full application. Examples for actions that would not be available: check whether a subject has a pseudonym in a domain; get all pseudonyms of a subject; search for pseudonyms across domains.
In the following month, the focus shifted a bit. Interoperability was not a major concern, we only really needed pseudonyms for ParticipationRequests, the DB split idea turned out to be less effective than we had hoped, and the low level limitations turned out to be too restrictive for the kind of UX we wanted to have.
So starting with !491 (merged) we changed the architecture. The Subject
model which had previously been hidden inside of the pseudonym service was exposed and even got its own UI. This was only meant to affect internal structures. The (not yet implemented) way in which external services would interact with the pseudonym service was not supposed to change.
While the Subject
model is now deeply embedded in the castellum monolith, we still use the helper functions for anything related to pseudonyms. We still uphold some of the initial restrictions even though the whole architecture has changed. This is an awkward in-between situation. I am not really sure at the moment which restrictions are actually still in place. I think we should decide to go in either of the following directions:
Drop "security in depth"
We have much more powerful security mechanisms in upper layers, e.g. permissions. We could lift limitations for some groups of users while keeping them for others. So the security of the whole system does not change, but it does get more complicated to argue about the security.
In practice this would mean to remove the helper functions and use the model interface directly.
Restore "interoperability" and "DB split"
The main aspect about the architecture change was to use foreign keys instead of pseudonyms for internal relations. It was not actually necessary to use the Subject
model from the pseudonyms app as the central piece.
In practice this would mean to add a new model to the pseudonyms app and link Subject
to this model using a pseudonym, much like with Contact
.
Why not drop "generic"
In !1014 (merged) we changed the pseudonym model so that pseudonyms are not reused after a subject is deleted. Even though we don't really need the "generic" part anymore, it has very similar requirements as this feature: Pseudonyms need to be stored independently from the specific subject data. So we would not gain any complexity reduction from dropping this requirement.