Automated user provisioning and deprovisioning is a cornerstone of modern IAM, but SCIM support remains patchy across the software landscape and provisioning fails in multiple distinct ways. Some products lack SCIM entirely, for example, a time tracker like Kimai has no user or group provisioning support. Some open source solutions have it built in but lock it behind expensive enterprise tiers, for example, GitLab confines SCIM to its paid Premium and Ultimate plans, scoped to groups. And entire categories like mail and groupware platforms such as Open-Xchange expose mature native provisioning APIs but don't speak SCIM at all and only provide CLI interfaces. In every case the fallback is the same: manual account management, onboarding tickets, forgotten or incomplete offboarding, and orphaned accounts that quietly become security liabilities.

This talk introduces scimd, an open-source Rust framework for building SCIM 2.0 servers as sidecar services. Instead of waiting for a vendor to implement SCIM, you deploy a small companion service that speaks SCIM (RFC 7643/7644) with your identity provider and translates it to the target interface. The target side is deliberately unconstrained. The sidecar drives the service however it is reachable, a REST API, a command-line tool, direct database writes, a SOAP/RMI provisioning call, even another directory service, while presenting one clean, standards-compliant SCIM surface to the IdP. The framework handles the tedious, error-prone parts of the specification: resource schemas, attribute filtering, PATCH semantics, pagination, bearer-token auth, discovery endpoints, and error formats, leaving only the business logic for you to implement.

The core idea is that a SCIM resource is generic. RFC 7643 treats `User` and `Group` as two predefined resource types, with providers expected to define their own and advertise them via `/ResourceTypes` and `/Schemas`. scimd mirrors this directly: you declare a resource as a plain struct, a macro derives its SCIM schema, and you implement only the operations the product actually supports. Adding a brand-new resource type, for example, a device, an application, or an organization, requires no framework changes. Register it, and scimd automatically serves it and advertises it through the standard discovery endpoints that identity providers rely on.

We'll walk through the architecture using two deliberately different targets, each also reaching its product through a different mechanism. On a smaller product with no native SCIM, a sidecar over a REST API turns "no provisioning" into "plugs into any SCIM-capable IdP" in a few dozen lines. And mail provisioning - modeling mailbox lifecycle on a groupware platform like Open-Xchange, driven through its command-line tooling - shows the generic-resource machinery reaching a resource that isn't a user or a group at all, where one SCIM operation from your IdP creates, suspends, or deletes a mailbox.

Attendees will leave understanding how SCIM provisioning works under the hood, the practical pitfalls of implementing it correctly, and how to add standards-based lifecycle management to products and resource types that were never designed for it using an open-source framework they can pick up and run the same day.