A connector is how Monokee reads from and writes to one of them. The catalogue covers directories, cloud identity providers, business systems, databases and files — and where it does not, the generic connectors do.
Connectors differ enormously in what they talk to and not at all in how they are described. That is the point of having a connector layer: the answers change, the questions do not.
A connector declares the kinds of object it manages — accounts and groups almost always, sometimes organizational units, roles or licence assignments. Which ones are enabled is decided per instance, and that decision controls what appears in mappings and lifecycle events.
Create, read, update, delete and search, expressed the same way whatever sits on the other side. A journey that provisions an account does not change shape because the target changed from a directory to a REST API.
Attributes and object classes are read from the target where the target can describe itself, and configured explicitly where it cannot. Systems with non-discoverable schemas can be given one.
Bind credentials, client credentials, API tokens, OAuth 2.0 flows: whatever the target expects. Secrets are held as encrypted values rather than as configuration text.
A connector exists twice. The definition says what this kind of system is and what properties it exposes — it is versioned and it rarely changes. The instance is one concrete connection: this host, this tenant, these credentials, these object types enabled.
Separating them is what keeps twelve environments from becoming twelve slightly different connectors. Add the thirteenth and you are configuring a connection, not re-describing a system.
Two families: the connectors maintained by Monokee, and those coming from community and third-party projects. Both are configured, mapped and scheduled in exactly the same way.
| Connector | Connects to | Typically manages |
|---|---|---|
| Active Directory | Active Directory domains over LDAP and LDAPS | Accounts, groups, organizational units, service accounts |
| LDAP | LDAP directories | Accounts, groups |
| Entra ID | Microsoft Entra ID through the Graph APIs | Users, groups, licence assignments |
| Google Workspace | Google Workspace APIs | Users, groups |
| Google Cloud Platform | Google Cloud APIs | Identities |
| SCIM 2 | Any SCIM 2.0 compliant REST API | Accounts, groups |
| REST | Any HTTP or HTTPS API | Configurable per instance |
| Database table | Relational databases over JDBC | Accounts held in a table |
| Scripted JDBC | Relational databases over JDBC, with scripted logic | Configurable per instance |
| CSV file | A single CSV file | Accounts |
| CSV directory | A directory of CSV files | Accounts |
| SAP | SAP business systems | Accounts |
| RACF | IBM RACF on the mainframe | Accounts |
| Monokee | Monokee itself, as a source or a target | Accounts, groups |
| Connector | Connects to | Typically manages |
|---|---|---|
| Okta | Okta APIs | Identities, with provisioning and synchronisation |
| Auth0 | Auth0 tenants through the official Java client | Identities |
| AWS | AWS IAM Identity Center through the AWS service APIs | Users, groups, group memberships |
| Salesforce | Salesforce APIs | Users and other Salesforce objects |
| ServiceNow | ServiceNow REST API | Users, groups, related records |
| GitHub | GitHub organizations through a GitHub App and the REST API | Organization members, teams |
| GitLab | A GitLab instance through the REST API | Users, groups, memberships |
| Atlassian Guard | Atlassian Guard protected environments | Identities, groups |
| Box | Box APIs | Users, groups |
| Webex | Cisco Webex REST APIs | Users, groups, roles, licences |
| Zoom | Zoom REST APIs | Users, groups, Zoom Phone resources |
| CyberArk Privilege Cloud | CyberArk privileged access management | Privileged accounts |
| FreeIPA | Red Hat FreeIPA through its REST API | Users, groups, roles |
| Oracle Database | Oracle databases | Database user accounts |
| MongoDB | MongoDB document databases, through a scripted connector | Database users |
The connector model Monokee builds on is an open one, and around it sits a much larger body of connectors — roughly 40 more targets beyond the two tables above. These are available to a deployment rather than shipped and supported with it: treat the list as evidence that your system is probably reachable, and confirm the specific one with us before it becomes a plan.
Most integration work is not a missing connector. It is a system nobody wrote one for because it only exists at your company — and for that there are three routes.
If the system exposes SCIM 2.0, use the SCIM connector and configure it. Standards exist so this case does not require code, and it is worth checking before assuming it does.
The generic REST connector covers systems with an HTTP interface: endpoints, authentication, headers and schema are configuration rather than a new bundle to build and deploy.
A table over JDBC, a scripted variant for the cases where a plain table is not enough, or a CSV drop for the systems whose only integration surface is an export somebody schedules overnight.
The catalogue reflects the current product documentation and grows with each release. What a given connector supports depends on the target system and on how the instance is configured, so treat this page as the map and the per-connector documentation as the reference. If the system you need to reach is not here, ask — it is a question about effort, not about possibility.
Bring the list of systems that hold your identities. We'll tell you which are covered today and what the rest would take.
Talk to an expert