Collecting identity data, governing what it entitles, enforcing it at the door and automating all of it. Sold separately they become four consoles that disagree; here they are layers that hold each other up, with one canvas running through them.
Read from the bottom up: you cannot govern identities you have not collected, and you cannot enforce access rules nobody has defined.
A reliable view of who exists.
Collects identity data from the systems that already hold it, keeps records and attributes aligned, and gives administrators the tools to inspect identities and control the processes that update them. Provisioning and reconciliation run through connectors, on a two-level model: the connector definition stays stable while the concrete connection to a real system is configured separately.
Dedicated page comingThe rules about who should have what.
Collects entitlements from target systems alongside identity data from authoritative sources, and turns them into objects you can govern: roles, applications, account mappings, entitlement templates. Associations show what a person actually holds today and whether each one is direct, active, or derived from another governance object.
Go deeperThe runtime: who gets in, right now.
Single sign-on with multifactor authentication across the applications you connect, as identity provider, as service provider, or as a broker between the two. Users, groups and attributes on one side; SAML, OAuth and OpenID providers and FIDO configurations on the other.
Go deeperHow all three are automated.
A flow is a graph: each operation is a node, and directional links define both the execution path and the data that travels along it. Nodes cover transformation, validation, routing and integration with external systems, with conditional branching for the cases that differ. Flows are versioned, exported, imported and localised — and the node library itself can be extended with your own categories.
Go deeperIn most identity stacks, automation is a scripting corner attached to whichever tool needed it first. Here it is the other way around: the orchestrator is a layer the other three are built to be driven by.
Open the identity management console and there is a section for flows. Open governance and there is another one, driving assignment, removal, approvals and campaigns. The same canvas, the same node library, the same versioning — reaching into provisioning, into governance and into the login journey.
That is what makes a change a change to a diagram rather than a ticket for whoever owns the module in question.
See the Visual Identity OrchestratorEvery module exposes the same operational spine. It sounds like an implementation detail until the day you are running the platform, and it turns out to be most of the job.
The same integration layer feeds identity data in and pushes provisioning out. Connectors maintained by Monokee and those coming from community projects sit in one catalogue and are configured the same way.
Alignment jobs, identity matching rules and discrepancy analysis, defined once and scheduled rather than run by hand when somebody notices a drift.
Predefined reports over identities, access and governance state, plus the outputs generated by reporting flows.
Frequencies, time windows and priorities for recurring work: reconciliations, refreshes, batch operations.
The cryptographic material and sensitive parameters used by integrations, administered in one place instead of pasted into each connector.
Tenant-level options and the settings governing how administrators authenticate to the console and to the exposed endpoints.
A platform that only works once everything else is gone is a migration project with a product name on it.
Monokee acts as identity provider, as service provider, or as a broker between the two. An existing directory or IdP does not have to be replaced in order to be included in a journey.
The layers hold each other up, but they are adopted one at a time — most often beginning with the journey that hurts, and extending outward from there once the canvas is in place.
SAML 2.0, OpenID Connect, OAuth 2.0, SCIM, LDAP, RADIUS and WebAuthn are spoken natively. Connectors cover what standards do not — directories, cloud identity providers, business systems, databases and files.
Browse the connector catalogueThe properties that matter to whoever has to approve it: the security architect, the auditor, and the team that will be on call for it.
The platform is built as microservices: each virtualised container is constrained in what it can reach from outside, both at rest and while running, so a single component is not a way into the rest.
Strong authentication and authorization are enforced between components, not only at the perimeter. Internal traffic is traffic that still has to prove who it is.
Multifactor authentication combined with dynamic risk and trust assessment, so the amount of proof asked of a person tracks what the situation warrants rather than a fixed global setting.
Decentralised identity is native rather than bolted on: verifiable credentials can be integrated directly into single sign-on journeys, which lets part of the identity assurance be delegated to a trusted issuer.
We'll show you where it sits in the platform, what it needs from the layers underneath, and what it would take to run it.
Talk to an expert