Register MenshenAuthentication as the menshen_token auth method to record
room operations made with a token exchanged through Menshen as an authentication
acting for its user
core/auditing.py both declared the actions that emitters import and
registered the models and authentication classes: it made it impossible
for authentication class to emit an audit event without an import cycle.
Keep the actions and transit_code_target in core/auditing.py and move the
model and authentication method registrations to core/audit_registry.py, the
module the audit app now autodiscovers.
Trace the login flow of the embedded iframe frontend flow.
An application minting a transit code for its delegated user should
logs the transit_code issuance and it's exchange for a user access
token. The transit_code can be identified and with a
SHA-256 to audit eventual replay attacks.
Emit audit events across the recording lifecycle: recording.start,
recording.stop and recording.delete from the API, recording.end when
LiveKit reports the egress ended, recording.transcript.request when the
backend sends a recording to the summary service, and
recording.transcript.report and recording.summary.report when that
service calls back.
recording.end has an unknown outcome when LiveKit reports an egress
status the backend does not map, and recording.transcript.request names
the summary service as service.target.
Small bugfix: AuditViewMixin keeps a copy of a deleted target, since deleting an
instance clears its primary key.
Every ModelAdmin now emits an ECS audit event when an object is created,
changed or deleted, and when a bulk action runs. Actions are templated
as admin.<target>.<verb>, after the model name. A signed-in account
without staff access reaching the admin is recorded as a denied
admin.access.
The wiring is a custom AdminSite installed through AdminConfig.default_site:
it mixes the auditing into every admin class at registration, including the
ones Django declares, so a new ModelAdmin is covered without doing anything.
It hangs off log_addition, log_change, log_deletions and get_actions, which
Django calls in every path, rather than off save_model. Deletions noted by
log_deletions are emitted from delete_model and delete_queryset, once their
outcome is known.
Changed field names are always reported; their values only for the
admin_values each model is registered with, and never for anything that
looks like a secret. An account acted upon is reported as user.target:
the target itself when it is a user, else the account its model
registers as user_target, as the user an access grants a role to. The
emitter derives it for every event, so user.provision names the user it
creates as well.
Describe the audit event shape, the catalogue, how views and other code
emit events, the environment variables configuring them, how the
project registers its actions, models and authentication classes.
briquet