Part of the primary identity path and intended for routine production use.
Implemented and usable with documented authority and environmental boundaries.
Implemented but intentionally gated, disabled by default, or restricted to test and pilot scope.
A deliberate integration direction that is not represented here as already shipped.
Capability matrix
The identity bridge first. Everything else stays in its proper lane.
The matrix below reflects the operating contract rather than simply counting routes or modules.
| Capability | State | What FreeSCIM does | Boundary that matters |
|---|---|---|---|
| SCIM user lifecycle | Core | List, read, create, replace, PATCH, active-state lifecycle, limited filtering, paging, structured errors, identifier mapping, and concurrency-aware behavior. | FreeIPA remains the downstream directory and Linux enforcement authority. |
| SCIM groups | Bounded | Group list, read, filtering, and create are implemented. | Full group replacement and deletion remain intentionally outside the public SCIM group contract. |
| SCIM conformance and secret safety | Proven | Discovery, response contracts, error shapes, password write-only semantics, redaction, and controlled probes are part of the verified service path. | Conformance does not imply every optional SCIM feature or every downstream mutation is enabled. |
| Okta provisioning | Core | Bearer-authenticated SCIM provisioning, profile mapping, assignment-aware lifecycle, safe app policy, and operator diagnostics. | Broad profile sourcing, force sync, and password sync remain disabled in the safe posture. |
| FreeIPA integration | Core | LDAP/LDAPS or agent-mediated operations, directory health, lifecycle operations, group visibility, and policy-aware workflows. | Kerberos, POSIX identity, groups, HBAC, sudo policy, and host authorization remain FreeIPA responsibilities. |
| Canonical identity provenance | Operational | Separates upstream login, contact address, SCIM username, canonical Linux username, FreeIPA uid, and Kerberos principal across dashboards and replay evidence. | Contact identity is not silently reused as Linux identity. |
| Attribute authority matrix | Operational | Tracks authoritative, observational, derived, blocked, and deprecated fields plus transformation rules and precedence. | Mapping configuration is allowed without implying an approved directory overwrite. |
| SAML SSO | Operational | Okta SAML login, assertion handling, session creation, role mapping, logout, readiness, and correlated event evidence. | SAML remains the preferred human SSO path and does not replace SCIM or Linux authorization. |
| OIDC relying-party path | Governed | Authorization-code, PKCE, discovery, JWKS validation, claims, role mapping, readiness, and session services are implemented. | The path is environment-gated and secondary to SAML. It is not a claim that FreeSCIM is the institutional IdP. |
| Federation governance | Operational | Application registry, onboarding governance, maturity states, health, key intelligence, drift, readiness, lifecycle, replay, and stewardship services exist. | Framework registration never equals live provider proof. |
| Password observe and dry-run | Proven | Password payload detection, redaction, in-memory handling, observe mode, dry-run evidence, readiness checks, and guarded adapter paths are implemented. | Real identity-provider password origin, a real password write, and rollback proof remain separate milestones. |
| Real password write | Blocked | Write guards and adapter machinery exist, but the canonical proof chain does not mark the real write as proven. | No public copy should describe password convergence as end-to-end complete. |
| Rollback execution | Implemented, not proven | Rollback candidates, dry-run execution, evidence, and operator restoration workflows exist. | The real post-write rollback milestone remains incomplete until a governed write and rollback drill are performed. |
| Linux trust and login validation | Proven | Linux trust, HBAC, Kerberos, SSSD/PAM, and login evidence are represented in the controlled proof path and operator dashboards. | This proves the Linux enforcement path, not the unproven password-write milestone. |
| Persistent sync and reconciliation | Operational | Persistent comparison, change tracking, snapshots, plans, history, reconciliation, and operator-visible evidence are implemented. | Broad execution, legacy queue processing, and bulk writes remain policy-blocked. |
| Drift and replay | Operational | Drift artifacts, snapshot comparison, read-only replay candidates, correlation IDs, action history, and recovery context support investigation before mutation. | Replay is not mutation and automatic drift repair remains blocked. |
| Runtime survivability | Operational | Degraded-state labeling, cached truth surfaces, dependency fault boundaries, and operator-safe failure responses are implemented. | A degraded dependency must remain visible rather than being converted into a false green status. |
| Evidence integrity and retention | Operational | Evidence-chain completeness, retention controls, secret stripping, export identifiers, and integrity checks support audit reconstruction. | Evidence remains useful only when sensitive payloads are excluded or redacted. |
| Operator dashboards | Operational | Landing, FreeIPA, Okta, Sync, Mapping, and Admin surfaces have dedicated operational summaries, exports, blocked-state UX, and browser verification. | Operator-ready does not mean institution-wide write authority is enabled. |
| TeamDynamix handoff | Governed dry-run | Ticket previews, persistence scaffolding, correlation, ownership context, and operations-center integration are implemented. | Live institutional ticket creation and webhook authority are not production claims. |
| Database operations | Needs attention | Schema audit, backups, retention, maintenance, migration controls, and survivability tooling exist. | The latest runtime audit reports missing expected schema objects, an index finding, and maintenance pressure, so the site must not imply uniformly healthy database posture. |
| OIN preparation | Preparation only | Readiness and conformance preparation services exist for evaluating future catalog submission. | FreeSCIM is not being represented as OIN certified or marketplace-ready. |
Provider maturity
The platform already knows about more providers than it currently connects.
The provider registry and onboarding framework are real functionality. Live integrations still have to earn higher maturity through configuration, reachability, authentication, read/write capability, and production evidence.
Live pathsCurrent identity foundations
Okta, FreeIPA, SCIM 2.0, SAML, and the governed OIDC relying-party path have implemented runtime behavior and evidence models.
Declared frameworksFuture provider onboarding
Microsoft Entra ID, Active Directory, generic LDAP, Google Workspace, Canvas, Shibboleth, CAS, OAuth 2.0, and additional application patterns are registered or templated without being marketed as live connections.
Next adapterGitHub Enterprise SCIM
GitHub Enterprise has federation-framework presence today. A dedicated SCIM destination adapter, organization and team mapping, deprovision semantics, reconciliation, retry controls, and live enterprise proof are still required before it becomes a current connector.
Runtime interaction
Compare, preview, and keep writes visibly gated.
The sync surface below follows the real runtime pattern: capture state, compute drift, generate a plan, and keep apply separate from observation.
Proof chain
A successful HTTP response is only the beginning.
A production claim should survive the full path from identity intent to downstream state and recovery.
Strong claims need visible limits
FreeSCIM is more credible when “not enabled yet” is allowed to be an answer.
Governance state is part of the product. Pilot scopes, intentionally unsupported group mutations, password redaction, OIDC enablement, and future connectors are surfaced instead of hidden behind broad marketing language.