Skip to main content

Administration guide for TideCloak

This section is for anyone setting up or running a TideCloak deployment. That includes the admins who create realms, manage users and apps, set policy, and govern sensitive changes in production, and it equally includes developers trying TideCloak out, evaluating it, or implementing it. If you are an end user signing in to an app rather than operating TideCloak yourself, this section is probably not for you.

This page explains what the admin console is, what it lets you do, and why it works the way it does, so the guides that follow make sense. To create your first realm, follow the Quickstart; the rest of this section links out to a guide for each task.

What the tide-console is​

The tide-console is the reference web admin console for a TideCloak deployment: the single browser-based place administrators work, instead of editing server configuration files or calling raw APIs. It is where you create realms, manage users and apps, define roles, operate keys, and approve changes. It is a "reference" web admin console because it is also an example implementation for developers that are looking to integrate TideCloak administrative capabilities into their own apps.

TideCloak itself is an IIAM (Identity, Immunity and Access Management) system, the layer that controls who can sign in to your apps, what they can do once they are in and under what authority. The console is the human-facing surface over that system. What makes it more than a generic admin panel is what it sits on top of: TideCloak's authority engine is decentralized, with no central store of secrets and no single party holding user or system keys. Operating that engine directly would mean orchestrating distributed key operations and governance by hand. The console exists to make that humane: it turns decentralized key operations, quorum governance, and licensing into ordinary screens any administrator can work in.

What it lets you do​

The console covers the full lifecycle of running a TideCloak deployment. Each capability below is a thing you can do from the console; the linked guide is where the actual procedure lives.

  • Provision and manage realms. A realm is an isolated operating environment with its own users, apps, roles, and settings. In most scenarios, you don't need more than one working realm. The console provisions a working realm and is where you manage it from then on. See the Quickstart.
  • Manage users, apps, roles, and groups. The everyday IAM surface: who exists, which applications (AKA "clients") trust the realm, and what permissions roles and groups carry. This is woven through the guides below, most directly the QEA governance guide.
  • Operate Tide's decentralized keys and the realm's sign-in. Tide is wired in as the realm's identity provider (IdP), the service that actually authenticates users, so the realm signs people in through Tide rather than a local identity store. See Tide as your IdP.
  • Manage licensing. A TideCloak realm carries a Tide license; the console is where you view, renew, and manage it. See Manage your Tide license.
  • Run quorum-enforced governance over sensitive changes. Security-sensitive changes pass through QEA (Quorum-Enforced Authorization) rather than taking effect the instant one admin saves. See Set up QEA governance and the Tide-less QEA demo for the change-request lifecycle.
  • Add end-to-end encryption. You can gate encrypt and decrypt of specific data fields behind realm roles and OIDC scopes, so the realm governs not just sign-in but access to data. See End-to-end encryption.
  • Wind a realm down. Offboarding backs a realm up and detaches it from Tide, returning it to local key management. See Ragnarok offboarding.

Why it works the way it does​

This is the part worth slowing down for. TideCloak's console behaves differently from a conventional IAM admin panel, and the differences follow directly from the security model underneath.

Why there is a console at all​

TideCloak's authority engine is decentralized. Authoritative keys are not held in one place, and operations over them are distributed by design. Exposed raw, that model would be close to unusable for a human operator: provisioning a realm would mean coordinating distributed key generation, governance would mean assembling and checking approvals by hand, and licensing would be another out-of-band process. The console collapses all of that into a single surface. Its job is not to hide the decentralized model but to make operating it, the keys, the governance, the licensing, something any administrator can do seamlessly.

Why changes go through QEA governance​

In a conventional IAM, an admin edits a setting and saves, and the change is live. Even in systems requiring multiple provisioning admins, there are singular database admins that carry identical authority. Whoever holds the admin account, holds unilateral power over the realm, which makes that one account, or one compromised session, a single point of trust.

TideCloak rejects that. Security-sensitive changes go through QEA, a two-step Authorize then Commit flow that requires a quorum of admins. An admin authorizes a change, but it does not take effect until enough approvals are gathered, and the change can be committed. No single administrator can silently alter a realm. This is the zero-trust, no-single-point-of-trust posture made concrete: the integrity of the realm does not rest on any one person, one system or any one account staying uncompromised. The cost is that some actions take more than one click and more than one person; that cost is the point.

Why there are no central secrets, and what that means for the admin​

A traditional IAM concentrates secrets: password hashes, signing keys, and credentials sit in a central repository (database or a vault) that the server, and by extension its admins, can read. That repository is a honeypot, valuable precisely because compromising it compromises everyone.

TideCloak has no such store. There is no central vault of user secrets to steal, and each user owns their own root key, their CMK (Consumer Master Key), rather than trusting the server to hold it. The payoff is that there is no honeypot to breach. The consequence for the administrator is a changed role: you govern and approve, you do not custody everyone's keys. You cannot read user secrets because they are not yours to read, and you cannot unilaterally impersonate a user because you never held the material that would let you. Administration here is oversight and authorization, not key custody.

Why it is built on Keycloak yet differs underneath​

TideCloak is a fork of Keycloak, the widely used open-source Red-Hat's IAM. That lineage is deliberate: it means TideCloak speaks the same standard protocols, OIDC (OpenID Connect) and OAuth, and easily be adopted by applications that already integrate with Keycloak. Apps do not need to learn a new identity system to benefit from Tide.

Underneath, the engine is different. Where stock Keycloak holds keys and secrets centrally, TideCloak performs decentralized Tide key operations and routes sensitive administration through QEA. The compatibility lives at the protocol surface; the security model lives below it. That split is why an app integration looks familiar while the operational model an admin works in does not.

For the security model administrators operate within, see Governance and the Threat Model in the Tide whitepaper.

Where to go next​

The guides in this section each go deep on one part of running a deployment, in roughly the order you will meet them: