OpenKM administration roles do not replace repository permission checks

OpenKM administration roles do not supersede repository permission checks. The administration interface and REST API serve distinct purposes. Users can access the application without being administrators, and nodes can possess permissions separate from an account's broader role membership. ZoomEye detected minimal application fingerprinting for OpenKM, but this does not imply the software's comprehensive presence.

Only users with the ROLE_ADMIN role can enter the administration zone. Permissions for document access are managed through node permissions and user or role assignments. The REST API accepts authenticated clients but still requires appropriate permissions for the targeted node. The API client holds the power to effectuate bulk modifications using a compromised session or service account.

It is crucial to validate public base URLs, authentication methods, and API routes. Administrators, service accounts, roles, and users capable of granting or revoking node permissions must be identified. For each repository or workflow, document which roles can read, write, delete, and alter security settings, including any inherited permissions and explicit overrides.

Perform tests with a non-administrator account trying to access documents the account should not view and then attempt to access documents they should be able to view. This should be done via both the web interface and the REST API. Verify that signed URLs cannot be reused once permissions have been withdrawn. Review the administration pages for user creation, role management, OCR templates, and activity logs.

Activity logs serve as evidence, not authorization controls, and an administrator who can modify or delete logs can alter the retention of that evidence. Minimize the authority exposed by placing administration paths behind a unique access policy, requiring strong authentication for administrators and service accounts, and rotating credentials used by integrations.

Each integration should have its own dedicated identity with the minimal node permissions required. Lastly, test backup restore permissions alongside document reads, as restores can overwrite existing documents and often pose a more severe risk than simple viewing.