Category: User Provisioning

Connector

Simply put

In identity and access management, a connector is a software component that links an identity system (such as a provisioning or governance platform) to a target system, application, or directory so that account and access data can be exchanged between them. It acts as the adapter that lets one system read from or write to another using that target's specific interface. Note: the evidence packet supplied for this entry describes only electrical, electronic, and dental connectors and contains no IAM-specific sources, so the IAM definition here is unverified against the provided evidence.

Formal definition

In IAM, a connector is an integration module that mediates between an identity platform (for example an IGA provisioning engine, an identity provider, or a directory synchronization service) and a managed target system such as an application, database, operating system, or directory. Connectors typically translate the identity platform's canonical operations (create, read, update, delete, enable, disable account, and attribute/entitlement reads) into the target's native protocol or API, and may implement standards-based provisioning (for example SCIM) or vendor- and application-specific interfaces. Behavior varies significantly by product and connector type, including whether the connector supports full lifecycle write operations or read-only reconciliation, and whether it runs in agent-based or agentless deployments. This definition could not be substantiated by the supplied evidence, which addresses only electromechanical and dental connectors; it should be re-verified against IAM-specific sources before publication.

Why it matters

Connectors are the integration backbone of most provisioning and identity governance deployments. Because an identity platform rarely speaks the native protocol or API of every application, database, directory, and operating system it must manage, connectors provide the adapters that make automated account lifecycle operations possible at scale. Without reliable connectors, organizations fall back on manual account creation and deprovisioning, which typically increases the risk of orphaned accounts, delayed offboarding, and inconsistent entitlement data across systems.

The security stakes are concentrated in what a connector can do and how it authenticates to its targets. A connector that supports full lifecycle write operations usually holds privileged credentials to the target system, so a compromised or misconfigured connector can become a high-value path to broad account manipulation. Conversely, a read-only reconciliation connector limits blast radius but cannot enforce remediation directly. Because behavior varies significantly by product and connector type, teams that misunderstand a given connector's scope may assume enforcement or cleanup is happening automatically when it is not.

Connectors also sit at the boundary between identity governance and administration (IGA) lifecycle concerns and the runtime interfaces of managed systems. Provisioning, access reviews, and reconciliation depend on connectors accurately reflecting the true state of accounts and entitlements in each target. When a connector drifts, silently fails, or maps attributes incorrectly, the governance data that access certifications and segregation-of-duties analysis rely on can become untrustworthy, undermining the very controls the identity program is meant to provide.

Who it's relevant to

IAM and provisioning engineers

These engineers select, configure, and maintain connectors between the identity platform and each managed target. They need to understand whether a given connector supports full lifecycle writes or read-only reconciliation, whether it is agent-based or agentless, and how attribute and entitlement mapping is defined, since these choices determine whether automated provisioning and deprovisioning behave correctly.

Identity governance leads

Governance leads depend on connectors to feed accurate account and entitlement data into access reviews, certifications, and segregation-of-duties analysis. When connectors drift or reconcile incompletely, the underlying governance data becomes unreliable, so these stakeholders care about connector coverage, reconciliation frequency, and how faithfully each connector reflects the true state of its target.

Security architects

Architects evaluate the trust and privilege implications of connectors, particularly those holding privileged credentials to write accounts and entitlements in target systems. They weigh blast radius, authentication models, and agent-based versus agentless deployment against the organization's threat model, treating write-capable connectors as high-value components that require corresponding protection.

System administrators of managed targets

Administrators of the applications, databases, directories, and operating systems being managed must expose the interfaces or endpoints a connector uses and provision the credentials it authenticates with. They are affected by connector behavior because create, update, disable, and delete operations initiated by the identity platform act directly on the systems they operate.

Inside Connector

Connector (IAM sense)

An integration component that enables an IAM or IGA platform to communicate with a target system (such as a directory, HR system, database, SaaS application, or on-premises app) to read and write identity data. In most deployments it abstracts the target's native API or protocol so that provisioning, deprovisioning, and attribute synchronization can be orchestrated by the identity platform.

Provisioning logic

The create, update, enable, disable, and delete operations a connector performs against the target system to keep account state aligned with authoritative identity data. This is an IGA lifecycle concern rather than a runtime access-enforcement concern.

Protocol or API binding

The specific mechanism a connector uses to reach the target, for example LDAP for directories, SCIM for standards-based provisioning to SaaS, or vendor-specific REST/SOAP APIs and database interfaces. The available binding depends on the target system and the connector implementation.

Attribute mapping

Configuration that translates identity attributes from the source or identity platform schema to the target schema (for example mapping a canonical username or email to the target's corresponding field). Mapping behavior and transformation support vary by connector and vendor.

Credentials and connection configuration

The service account, secrets, endpoints, and connection parameters the connector uses to authenticate to and reach the target system. These are typically privileged and require secure storage and rotation.

Directionality

Whether the connector reads from the target (inbound, for example identity reconciliation or HR-as-source), writes to the target (outbound provisioning), or both. Supported directions depend on the connector and target capabilities.

Common questions

Answers to the questions practitioners most commonly ask about Connector.

Is a connector in IAM just an electromechanical or hardware component?

No. In an identity and access management context, a connector is a software integration component, not a physical or electromechanical device. It is the piece of code or configuration that enables an IAM platform (for example, a provisioning engine or IGA system) to communicate with a target system such as a directory, application, database, or cloud service. The hardware meaning of 'connector' is unrelated to this usage and out of scope for user provisioning.

Does a connector handle authentication of end users at runtime?

Typically no. A provisioning connector is most commonly used for identity lifecycle operations such as creating, updating, disabling, and deleting accounts and their attributes in a target system, which is an identity governance and administration concern. This is distinct from runtime authentication (verifying who a principal is) and from runtime authorization enforcement. Some platforms bundle additional integration capabilities, so behavior depends on the specific connector and deployment, but the core provisioning connector role is lifecycle management rather than authenticating users at sign-in.

What operations does a provisioning connector typically support against a target system?

Depending on the connector and the capabilities of the target system, common operations include create, read, update, enable/disable, and delete of accounts, along with attribute synchronization and group or entitlement assignment. Some connectors also support reconciliation, where the IAM system reads existing accounts from the target to detect and correct drift. The exact operation set varies by connector, target, and configuration, and not all targets expose every operation.

How does a connector authenticate to the target system it manages?

A connector generally uses a service account or dedicated credential to connect to the target, and the mechanism depends on what the target supports. This may include directory bind credentials for LDAP-based systems, API keys or tokens for cloud services, or delegated authorization flows. Because the connector often holds privileged access to create and modify accounts, its credentials are typically treated as sensitive and secured accordingly. Specific credential types depend on the target and the connector's supported options.

What is the difference between an agent-based and an agentless connector?

In many deployments an agentless connector communicates with the target directly over a network protocol or API from the IAM platform, while an agent-based connector relies on a locally installed component near or on the target system to bridge connectivity, often for on-premises or network-isolated systems. The choice frequently depends on network reachability, the target's interface, and vendor-supported options. Terminology and behavior vary by product.

How do standards like SCIM relate to connectors?

SCIM is a standard for provisioning and managing identity data between systems, and a connector may implement or consume SCIM to communicate with a target that exposes a SCIM interface. In that case the connector acts as the integration layer that maps the IAM platform's internal identity model to SCIM operations against the target. Where a target does not support SCIM, a connector typically uses a target-specific interface instead. The relationship depends on whether the target and the connector both support SCIM.

Common misconceptions

A connector authenticates end users to the target application.

In its IAM/IGA sense a connector typically manages account lifecycle and attribute data (provisioning, deprovisioning, synchronization). That is distinct from runtime user authentication, which is generally handled by federation or authentication protocols. Managing an account is not the same as authenticating the person who uses it.

SCIM and 'connector' mean the same thing.

SCIM is a standardized provisioning protocol that a connector may use to talk to a compatible target. A connector is the broader integration component and may instead use LDAP, a vendor API, or a database interface when SCIM is not available. Using a SCIM-based connector depends on the target supporting SCIM.

Deploying a connector automatically enforces access decisions in real time.

Connectors are primarily about lifecycle administration and data synchronization (an IGA concern), not runtime authorization enforcement. Real-time access decisions are typically the responsibility of enforcement components (such as a PDP/PEP and token validation), which are out of scope for what a provisioning connector itself does.

Best practices

Use a standards-based connector such as SCIM where the target supports it, and reserve vendor-specific or API-based connectors for systems that lack standardized provisioning interfaces.

Store connector service-account credentials and secrets in a secured secrets store, apply least privilege to those accounts, and rotate them on a defined schedule.

Document and validate attribute mappings between the identity platform and each target schema, and test transformations before enabling outbound writes.

Define connector directionality explicitly (inbound reconciliation versus outbound provisioning versus bidirectional) so the authoritative source for each attribute is unambiguous.

Enable logging and monitoring of connector provisioning and deprovisioning actions to support access certification, reconciliation, and audit needs.

Verify each connector's supported operations and limitations against the specific target and vendor documentation rather than assuming uniform capability across systems.