Skip to content
SkyRosterBook a working session

Trust · Security

Six mechanisms, not one adjective

Secure is an adjective. Below is what actually happens between a login and a query result: which protocol, which layer, which check, and in what order. Nothing here is a certification claim; it is a description of the code path.

1 · Authentication

Your identity provider decides who you are, not us

Every customer gets its own realm in Keycloak, an open-source identity server. All API traffic is authenticated with short-lived, signed JSON Web Tokens issued through the standard OAuth2/OIDC flow. The gateway validates every request's token signature against the issuing tenant's realm before the request reaches any business logic, and it keeps no session or cookie state of its own: the backend is a stateless OAuth2 resource server, so there is nothing sitting in server memory for an attacker to hijack between requests.

verified

Your staff do not need a second password. SkyRoster federates login against the identity provider you already run:

  • Microsoft Entra ID (Azure AD), through Keycloak's built-in Microsoft OIDC identity provider. An optional "autologin" mode skips SkyRoster's own login screen entirely and redirects straight to your Microsoft sign-in, while administrative accounts can be kept on a standard username-and-password screen for break-glass access if your identity provider is ever unreachable.
  • On-premises Active Directory, through Keycloak's LDAP federation, with optional Kerberos for a fully passwordless login from inside your own network. A separate, one-directional sync job can also read your Active Directory to create matching employee records automatically as people join, though it does not remove someone from SkyRoster when they leave your directory; that step stays with whoever administers your organisation here.
configured

2 · The internal call gate

An internal call cannot claim a trust it was not issued

Only the gateway is reachable from outside the platform. Every one of the backend services behind it sits on an internal network a browser cannot reach directly. That alone is not the control: the gateway also strips any inbound marker that claims to be an internal call, so an external caller cannot forge one and present itself as trusted traffic. Every internal service-to-service hop then re-evaluates the same real end-user permissions that would apply if that user had called the API directly. There is no internal "system" identity that bypasses authorisation because a request originated inside the network rather than from a browser.

verified

3 · Authorisation

Checked at the endpoint, checked again in the handler, checked a third time at the database

A single access-control decision is enforced three times, independently, rather than once at the door:

  1. At the endpoint. Before a controller method runs at all, it checks whether the calling user holds the membership tier the action requires.
  2. At the command or query itself. The same check runs again inside the handler that actually does the work, which matters because not every internal call arrives through an HTTP endpoint; a handler invoked from a background job or another service is checked exactly the same way a browser request would be.
  3. At the database. See below: the query is scoped to what the caller may see before it runs, not filtered afterward.

The full model behind what "the membership tier the action requires" means, the sixteen areas it applies to and how read and write are scoped independently, is on the access control page.

4 · The secured repository layer

The query is scoped, not the screen

A user's accessible units and employees are injected directly into the underlying database query, at the repository layer, before it runs. A roster manager scoped to their own primary unit does not get a greyed-out menu item for other units while the underlying data is still reachable through a different route: the query for other units' records is structurally excluded at the point the data is fetched. Calling the same endpoint directly, bypassing the interface entirely, returns the identical, scoped result.

verified

5 · Transport

Encrypted in transit, and the gateway is the only door

A wildcard certificate is installed independently in every namespace that serves traffic over HTTPS, so transport is encrypted for the application itself and for the operational tooling around it alike. The gateway enforces an explicit allow-list of origins per environment and restricts request headers to exactly the ones the application needs. It is also, by construction, the only externally reachable service: every one of the platform's backend services sits behind it, not beside it.

verified

6 · Stored documents

Encrypted before they are written, decrypted only to be read

Employees attach documents under five categories: personal, managerial, qualification, leave and duty. That covers IDs, licences, medical certificates and qualification proofs. File content is encrypted at the point of storage and decrypted only at the moment it is read; this has been true for every document uploaded since the product's 4.11.0 release, and a small number of files uploaded before that version are recognised and read through a separate, backward-compatible path rather than silently treated as encrypted when they are not.

Confidential personal fields, a fiscal number, an ID or passport number, a home address, are not returned by the general employee or roster endpoints most roles can already read. They are served only through a separately gated endpoint that requires write-level access to the employee's primary unit. Viewing your own confidential fields through self-service needs only individual-level read access; nothing more is required for that one case.

verified

Tested, not just designed

Security testing that leaves a regression test behind

SkyRoster has undergone third-party security testing. Every finding from that testing has been remediated, and each remediation shipped with its own automated test that fails the build if the same gap ever reopens. We describe this generically and do not publish the specific findings or internal ticket references; the point that matters to a reviewer is that hardening is tested and regression-checked, not that a list of past weaknesses is public.

Read next

The rest of the trust section

Bring us a month that went wrong.

A working session is 45 minutes with your own roster on screen, not a canned demo. Bring a pattern that fought you and we will walk through what the engine would have done with it.