An introduction to connectors

Connectors allow the ConductorOne platform to connect to any SaaS, IaaS, on-prem, or infrastructure tool for the purposes of managing and automating access control. Connectors synchronize data for identities, resources, and access rights, and can orchestrate access changes (such as provisioning accounts) back to the system.

Connectors are also designed to integrate with any software stack. This includes software-as-a-service applications, infrastructure-as-a-service environments, on-premise apps and directories, cloud directories, and infrastructure such as databases.

How do connectors work?

Connectors are the connective tissue between a SaaS, IaaS, database, or other technology, and the ConductorOne access control plane. Connectors work by “talking” to a technology stack and extracting identity, resources, entitlements, and grants into a format that can be ingested into the ConductorOne platform. While extracting those different objects, a graph is built of the relationship between resources (parent-child relationship) and between identities and entitlements (grants). This provides a full picture of the current state of identity and access within the boundaries of an application or technology stack.

Connector types

ConductorOne offers two types of connectors:

• Cloud connectors are the built-in, no-code connectors hosted directly in the ConductorOne tenant and provided via our SaaS service. They are configured on the Connectors page of ConductorOne. To get started with cloud connectors, check out the cloud connectors library.

• Baton connectors are open-source Baton connectors that are hosted and run in your own environment. To get started with Baton connectors, go to the Working with Baton connectors page.

Should I use self-hosted Baton connectors?

You might want to self-host and deploy Baton connectors in your own environment if one or more of the following is true:

• The technology does not expose its APIs (as in the case of a PostgreSQL database, for example)

• The technology or application does not have a line of sight to ConductorOne’s platform and it would be inappropriate to expose that app to the internet

• You can’t or don’t want to provide ConductorOne with the API keys or credentials for the technology

• You need to control the sync schedule or some other aspect of the connector

• You wish to extend the connector’s capabilities, such as by supporting additional resources in a SaaS

In any of these scenarios, the best option is to deploy a connector in your own environment. All of our pre-built connectors are available via our open source Baton project. These connectors are provided as open source to allow for self-hosting and modification.

Data ingestion and the c1z file

Data from the application or technology needs to be ingested into the ConductorOne platform. Connectors sync and store data in a custom data format: the .c1z file format. This file contains all of the identity graph data for a system.

When using cloud connectors, the .c1z file is an implementation detail and is never seen or touched by the end user. When using Baton connectors, the .c1z file must be transported to the ConductorOne service to be ingested.

Connector modes

Connectors can be run in different modes depending on your goals and needs. All connectors can be run in read-only mode, which pulls identity, resource, and access rights data from the application. Some connectors can alternatively be run in read-write (provision) mode, which additionally allows ConductorOne to manage provisioning and deprovisioning for the connected technology.

All connectors support read-only mode, and certain connectors support read-write mode. Permissions needed to run the connector and connector-specific setup instructions are provided in the connector’s documentation.