Developers
FreeSCIM exposes standards-shaped lifecycle behavior while keeping Linux authority, mutation safety, reconciliation, and proof visible. The goal is not a clever API. It is a predictable identity control plane that can live beside the rest of an enterprise application estate.
The public developer surface keeps protocol behavior separate from environment-specific base URLs, credentials, and directory details. Your deployment chooses the base path. The resource contracts stay recognizable.
Discover supported SCIM behavior before assuming filters, patch semantics, bulk behavior, or authentication shape.
Inspect resource schema instead of hard-coding every attribute assumption into a client.
Understand how resources are represented and which schemas apply.
Create, read, replace, patch, filter, page, and lifecycle-disable identities through the governed user path.
Use bounded group behavior where the current capability matrix marks it available; do not infer unsupported mutation breadth.
export FREESCIM_BASE="https://your-freescim.example/scim/v2"
export FREESCIM_TOKEN="replace-with-a-deployment-token"
curl -sS \
-H "Authorization: Bearer $FREESCIM_TOKEN" \
"$FREESCIM_BASE/Users?filter=userName%20eq%20%22demo.user%22"The hostname and base path above are intentionally generic. Production routing, secret storage, and trust configuration belong to the deployment, not to public example code.
FreeSCIM is strongest when it behaves like a well-bounded application: it accepts defined inputs, delegates authority to the right systems, persists only what it should, exposes health and evidence, and can sit beside normal business applications rather than replacing them.
Reverse proxying, external identity, a database, directory connectivity, health checks, and logs are conventional enterprise concerns. FreeSCIM does not require every neighboring application to adopt its authority model.
SCIM ingress, human SSO, directory mutation, database access, and remote operational paths remain separate trust concerns with separate evidence.
Readiness, drift, snapshots, structured errors, audit context, and degraded-state labels are treated as runtime product behavior rather than afterthoughts.
Clients and operators should be able to tell what FreeSCIM accepted, what it rejected, which authority made the final decision, and what evidence remains after the transaction.
Schema, identifiers, filters, lifecycle transitions, concurrency expectations, and policy gates should fail explicitly instead of degrading into ambiguous partial writes.
Request context, mapping decisions, downstream operations, drift checks, and operator-visible outcomes should be traceable without logging secrets.
Creating or updating an identity does not bypass Kerberos, HBAC, sudo policy, group policy, or the downstream Linux enforcement model.
Snapshots and persistent comparison make source-versus-directory drift visible before remediation is considered.
Structured status and error behavior should tell a client whether the problem is syntax, policy, authority, readiness, or downstream execution.
High-risk transitions remain staged until the proof chain includes a credible rollback or recovery path.
The architecture is adapter-oriented, but extension should remain contract-driven. A future provider or destination belongs in FreeSCIM only when its inputs, privileges, mutation semantics, failure modes, and evidence can be described precisely.
Normalize protocol and provider-specific identity data into the canonical lifecycle model.
Translate approved intent into the destination system without pretending the adapter owns authentication or authorization it does not control.
Capture health, drift, audit, correlation, and downstream proof in a way that survives handoff and incident review.
This browser-only simulation is derived from the current runtime UI. It uses synthetic public data and does not connect to production systems.
FreeSCIM deliberately keeps implementation, governed enablement, and blocked proof states distinct so developers do not have to reverse-engineer confidence from marketing language.
Implemented behavior with direct operating or conformance evidence.
Implemented path that remains staged, environment-gated, or policy-limited.
Not yet entitled to a production claim; prerequisites or end-to-end proof are still missing.
Use the next surface that matches the question you are trying to answer.
Discovery, users, groups, filters, paging, passwords, and errors.
Open API docs →Trace authority boundaries and system responsibilities end to end.
Trace the model →See what is proven, governed, needs attention, or remains blocked.
Open truth ledger →Review secret handling, mutation boundaries, and evidence controls.
Review trust →Walk the synthetic operator surfaces without production access.
Launch preview →Navigate identity, federation, operations, topology, database, and evidence topics.
Browse docs →