Security controls and the evidence to review

SkyRoster uses a separate Keycloak realm for each tenant and signed OAuth2/OIDC tokens for authenticated API access. The gateway verifies token signatures using an identity provider's signing keys. The trusted issuer configuration, token lifetime, audience and identity-provider policies must be checked for the environment being deployed. Standard single sign-on is part of Core; tenant setup and any custom identity work are confirmed in the written offer.

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.

The product uses several authorisation mechanisms. Their coverage needs to be verified for each workflow, including direct API calls:

1. Endpoint permissions. Protected controllers check the resource and membership tier required for an operation.
2. Command and query permissions. Protected handlers can enforce the same operation permissions when a call reaches them through another application path.
3. Record scope. Secured repositories apply employee and unit restrictions. Other persistence paths need explicit checks for the records an operation can access.

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.

The deployment model uses HTTPS for public application traffic and a gateway cross-origin policy for permitted browser origins. Certificate renewal, exposed endpoints, internal transport and operational-tool access must be checked against your chosen hosting setup. A source-code description alone does not establish those running-environment controls.

Ask for the assessment scope, tested product version, outstanding findings and remediation evidence relevant to your deployment. Regression tests should cover authenticated roles, record ownership, cross-tenant access and historical data as well as normal user journeys. This page does not assert that every security finding is closed or that source inspection proves the security of a running environment.