Skyrsoft CertOps console sign-in supports a local password and any number of OpenID Connect providers side by side — Microsoft Entra ID, Okta, AD FS, Google Workspace, or a generic OIDC issuer such as Keycloak or Authentik. A second factor, TOTP or a passkey, applies to local accounts and can be required outright. Every session carries one of three roles, enforced on the server rather than only hidden in the console’s own navigation, and a locked-out installation can still be recovered directly on the server itself, with no console access and no service restart required.
How it works
Each identity provider is configured as its own object, not a single shared setting, so a deployment can run an internal AD FS and a contractor’s Okta tenant at once, each with its own group mapping and idle-account policy. Adding, editing or removing one takes effect on the very next request — no service restart. The five presets above are display labels only: every one of them configures the same generic-OIDC fields underneath, so a provider your identity team runs that isn’t in the list still works as Generic OIDC.
Just-in-time provisioning
The first successful sign-in from a given identity provider creates the local account automatically, with a role resolved from that provider’s group mappings or its default role if none match. If a local account already exists with a matching email address, that first SSO sign-in converts it to an SSO account rather than creating a duplicate — from the account’s perspective this is still its first provisioning, which matters for what happens next.
The role is set once, then administrator-owned
Role assignment happens only at provisioning. After that, changing a user’s role is something an administrator does deliberately from Settings → Users, and it stays changed — a later sign-in never re-resolves the role from the identity provider’s current group membership and overwrites it. What a provider’s group mapping keeps doing on every login is deny: a default role of Deny still refuses the sign-in outright before anything is written, so tightening a mapping remains a live way to lock an account out even though it can no longer silently change what an allowed account is assigned.
Idle SSO account lifecycle
Each provider can auto-disable its own accounts after a configurable number of days without a sign-in (default 90), then auto-delete them a further configurable number of days after that (default 30). The policy is per provider, not global, so a contractor’s tenant can run a tighter policy than an internal one. It never touches local accounts, and it will not disable or delete the last remaining administrator account regardless of how idle it looks.
Multi-factor authentication
Two second-factor methods are available, and a user picks one — or both — the first time they set up MFA: a TOTP authenticator app, or a passkey (WebAuthn). Either can be the sole factor; a password is still always required first, so this is not passwordless primary login. Setting up either one for the first time activates MFA on the account and issues one-time recovery codes. Enforcing MFA account-wide, and restricting that enforcement to local accounts only, are both policy switches under Settings → Authentication.
Roles
Three roles exist, and access is checked on the server, not just in what the console’s navigation shows: Admin reaches every setting, including user management and role changes. Approver reaches the certificates, devices, enrolments, templates, CAs, approval rules, AD domains, alerts and audit log — read-only except for approving or rejecting requests — with no access to Settings and none to public certificates, deployment targets, SCEP, device groups, CRL configuration or other integrations. User gets the self-service portal only: requesting and managing their own certificates.
Break-glass recovery
A sysadmin with access to the server itself can run a command directly on the box to recover the built-in administrator account without going through the console at all — a forgotten password, a lost authenticator and every recovery code, a lost passkey, or a deactivated account are all the same case. It resets the password, clears every MFA method and any lockout, and reactivates the account, all with the running service left up the whole time. It is scoped to the one built-in account; recovering a different admin who is locked out, while at least one other admin can still sign in, is a Reset MFA action against that account from Settings → Users instead.
Limits
An identity provider’s current group membership only ever decides a role at first provisioning. CertOps has no ongoing sync between a person’s group membership and the role stored for their account; a promotion or demotion made through the identity provider afterwards has no effect until an administrator changes the role by hand. The one lever that does stay live is Deny — a role resolving to it still blocks the sign-in every time.
Google Workspace cannot supply group membership to CertOps at all. No scope puts Workspace group membership into the ID token Google issues, so group-mapping rules can never match for a Google-provisioned account; assign a default role instead of relying on mappings for that provider.
MFA lockout is per-installation, not distributed, and resets on a restart. Five consecutive wrong codes within 15 minutes locks the attempt out, but the counter lives in memory — it does not survive a service restart and does not coordinate across multiple instances of the console.
Passkeys are a second factor, not passwordless sign-in. A password is required first in every case; a passkey only replaces the authenticator-app step.