SORMAS exposure begins with role rights and REST user privileges
SORMAS supports outbreak surveillance, contact tracing, laboratory workflows, and data exchange between public-health systems. Its REST interface is used by the web application, the Android app, partner instances, and external services. The project's REST documentation says access is restricted by HTTP Basic authentication by default, with OAuth2 or bearer authentication possible through Keycloak, and the user must have a role containing the SORMAS_REST right.
That single right is a useful starting point, but it is not the whole authorization decision. The same user may have other rights that permit case creation, contact changes, laboratory data access, or export. A REST-enabled account should be reviewed against the integration's actual data flow.
What the count shows
The count-only observations on 10 November 2026 used sub_type=all, page 1, and page size 1:
-
app="SORMAS": 0 -
title="SORMAS": 6 -
http.body="SORMAS": 136
The small title population makes manual confirmation practical. A title match is not proof of a live surveillance database. Public documentation, test systems, and regional project pages can use the same name.
Review the rights behind role names
SORMAS documents standard roles and custom roles built from rights. Record the user's role, the included rights, the jurisdiction or region where those rights apply, and the data objects the role can reach. A role named for a surveillance officer may still include a broad export or user-administration right.
Include the REST right in the review. Then check whether the account can create or modify cases, contacts, samples, tasks, events, or persons. Review read-only integrations separately from bidirectional synchronization.
Examine the Keycloak path
The project documentation describes Keycloak as an authentication provider and a synchronization path for users and roles. Map the Keycloak realm, client, role, and user to the SORMAS account and role. Confirm what happens when the identity provider is unavailable or the synchronized user loses a role.
Review client secrets, redirect URIs, token lifetimes, and the user-info mapping used by the proxy. A valid Keycloak login is not proof that the SORMAS role is least privileged. Test the complete path from provider login to the restricted SORMAS action.
Follow external data exchange
Partner synchronization and citizen-facing interfaces can carry sensitive case or contact data. For each interface, record the endpoint, authentication, data fields, direction, retry behavior, and audit evidence. Verify that a retry does not duplicate a case or send data to the wrong jurisdiction.
Logging should include authentication, role changes, case changes, exports, and synchronization failures. Store the records outside the account that can administer SORMAS.
Build a small, high-confidence inventory
Use the title count to identify candidate deployments, then confirm the product with the API, login page, version, and owner. Record the country or public-health agency, hosting model, authentication path, Keycloak realm, REST users, and data classification.
The count is small enough that each confirmed instance can receive a named review. The security question is not whether SORMAS has roles. It is which rights, jurisdictions, and data paths the deployed roles actually grant.
