Today we announced the open sourcing of Baton: our connector ecosystem. Baton comprises three sets of tools:
- The Baton CLI: a command line interface that provides a set of commands to extract, compare, and explore identity, resource, and permission data in an app.
- The Baton SDK: a toolkit that makes building a Connector for any application or permission store easy.
- Baton Connectors: pre-built and supported integrations that work with common SaaS and IaaS apps to sync identity and permission data. Connectors generate data that the CLI consumes and/or they can connect directly to ConductorOne.
As a toolkit, Baton allows you to easily gain unified visibility into all identity, resource, and permission data in an application and to create workflows that manage identity and access.
We’re starting with open sourcing five of our pre-built connectors, but will slowly be releasing more of these integrations into the public in short order! Before we get into why we launched Baton, let me wind it back for a second. It’s important to understand how this fits into our overall mission…
Why we started ConductorOne
We started ConductorOne because we believe that securing identity requires a novel approach. Users are over-provisioned. Getting access is too hard and manual. Off-boarding is inefficient and error prone. Nobody has any idea why a user has access and if it’s still needed. These were just some of the challenges we heard, but they were symptomatic of a bigger problem: identity was missing a central security layer that could understand a customer’s environment and orchestrate access changes.
Broadly, we would hear these problems described as: identity and access visibility, permission management, authorization management, access requests, just in time provisioning, access reviews and the markets described as identity governance (IGA), modern privileged access (PAM), or identity threat detection and response (ITDR).
Gartner Magic Quadrant alphabet soup aside, the ultimate goal is the same: companies want to secure identity and achieve least privilege access control to ensure that users only get the sensitive access they need, when they need it.
Our platform, and why we built Baton
I’ll spare a deep dive on our architecture, but suffice to say that it very closely resembles what AirBnB built. For the purposes of this discussion, I want to deep dive on what we also call “Connectors”: the integration layer between our control plane and any permission store.
When we started ConductorOne, we recognized that one of the biggest technical hurdles to realizing our vision was to figure out how to enable our platform to “talk” to any permission store. There are literally thousands of SaaS, IaaS, and PaaS technologies out there. Furthermore, companies often have business critical, custom-built applications that they run on-prem or in their private clouds, not to mention legacy apps that don’t expose modern APIs. And, painfully, the authorization and identity layer of every one of these apps is unique. There are a proliferation of new technologies out there helping to solve the developer experience for building authorization into an app, but there will never be a singular winner. Platforms will always iterate faster than protocols.
Enter Baton: extensible connectors for any permission store
To realize our vision of securing workforce identity, we needed to be able to connect to any technology, anywhere – and this required a new approach. Our platform needed to bridge the protocol divide of the identity and authorization layers provided by apps.
Baton is our answer. Baton connectors can integrate with any permission store to export the user and permission data, and orchestrate access changes back. Because connectors can be natively written in any language, they are also not restricted to simply using APIs to integrate. They can manage identity and access using screen scraping or direct database calls. Furthermore, because connectors are standalone artifacts, they can be hosted anywhere: in our SaaS, in your private cloud, or on-prem alongside your app.
The Benefits
Today we announced open sourcing several of our ConductorOne supported connectors along with the Baton SDK and CLI. There are several reasons we did this:
- To create value for security and identity engineers by making their identity and permission data easily accessible [CLI + Connectors]. By open sourcing our connectors and providing the Baton CLI to interact with them, we make it dead simple to extract and work with identity and permission data in any application. The CLI can be used to significantly simplify any coding that requires interacting with the identity and permission layer of an app. For example, you can extract all resource, identity, and permission data from Okta with a single CLI command.
- To make it simple for any engineer to integrate with any permission store [SDK]. Many companies have back office apps, support portals, API-less software powered by MySQL databases, and so on. These apps might be essential to running a business but may not have even basic identity security controls due to lack of APIs or protocol (e.g. SCIM) support. With the Baton SDK, ConductorOne can integrate with any permission store for the purposes of providing identity visibility and managing authorization. With out of the box support for common primitives such as rate limiting, most connectors can be built in less than a day.
- To solve credential ownership and network access security concerns [Connectors]. Baton connectors can be built as docker containers and hosted anywhere. By self hosting connectors for sensitive permission stores, integration keys do not need to be shared directly with ConductorOne. Furthermore, connectors can be deployed next to the application without needing to expose that application to the cloud. For example, if your GitHub enterprise is hosted on prem, you can deploy the Baton GitHub Docker container on your network with a line of sight to GitHub. ConductorOne can orchestrate access control against this GitHub no differently than if you were using GitHub cloud.
Most importantly: creating standalone value for security and identity engineering
The most important of these goals was to create standalone value for security and identity engineering communities. We could have exposed our SDK and/or solved connector residency without open sourcing, but we believe something fundamental: identity and permission data should be easily accessible. There are too many hacky Python scripts floating around; too many engineers building the same tooling to solve the same problems. Our goal from this launch is to make a few engineer’s lives easier by providing some nice out of the box tooling for common use cases we see in the wild. We documented a few of those here.
If you have additional use cases you’d like to see or questions about the project, please reach out at baton@conductorone.com.
