generated from coulomb/repo-seed
tegwick
1c1b5c9bc6
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
133 lines
6.3 KiB
Markdown
133 lines
6.3 KiB
Markdown
# SCIM RFC 7643 and RFC 7644
|
|
|
|
## Source Type
|
|
|
|
Standard. RFC 7643 defines the SCIM 2.0 core schema; RFC 7644 defines the
|
|
SCIM 2.0 protocol for provisioning.
|
|
|
|
## Domain
|
|
|
|
Identity provisioning and directory synchronization.
|
|
|
|
## Why This Source Matters
|
|
|
|
SCIM 2.0: RFC 7643 schema and RFC 7644 protocol.
|
|
|
|
SCIM is the dominant platform-neutral provisioning baseline. It defines
|
|
resource types, attribute schemas, and CRUD/search operations for users and
|
|
groups without prescribing authentication or authorization semantics.
|
|
|
|
## Key Concepts
|
|
|
|
- **Resource**: a provisionable object with a `schemas` array, `id`, `meta`,
|
|
and typed attributes.
|
|
- **User resource**: a person-oriented identity record with `userName`,
|
|
`name`, `emails`, `phoneNumbers`, `addresses`, `groups`, `roles`, and
|
|
`active` lifecycle state.
|
|
- **Group resource**: a named collection with `displayName`, `members`, and
|
|
optional `type` (direct or indirect membership).
|
|
- **Enterprise User extension** (RFC 7643 §4.3): adds `employeeNumber`,
|
|
`costCenter`, `organization`, `division`, `department`, and `manager` for
|
|
workforce semantics.
|
|
- **Service Provider Config**: exposes supported features, authentication
|
|
schemes, and bulk limits.
|
|
- **Meta block**: `resourceType`, `created`, `lastModified`, `version`,
|
|
`location` — lifecycle and versioning metadata on every resource.
|
|
- **Operations**: Create, Read, Update, Delete, Search (POST /Users/.search),
|
|
and Bulk (RFC 7644 §3.7).
|
|
- **PatchOp**: partial updates via `add`, `remove`, `replace` on paths.
|
|
- **ExternalId**: cross-system correlation identifier supplied by the client.
|
|
|
|
## Relevant Terminology
|
|
|
|
| Term | Source meaning |
|
|
| --- | --- |
|
|
| User | A provisionable identity record; not necessarily a login account in the consuming system. |
|
|
| Group | A named collection of members; may represent authorization, organizational, or mailing-list grouping. |
|
|
| userName | Unique identifier within the service provider's namespace; often used as login handle. |
|
|
| externalId | Client-supplied correlation key for linking to an upstream system of record. |
|
|
| active | Boolean lifecycle flag; inactive users retain the record but should lose access. |
|
|
| member | Reference (`value`, `display`, `$ref`) to a User or Group in a Group's membership list. |
|
|
| organization (extension) | Free-text employer or org name on a user; not a structured org resource. |
|
|
| manager | Reference to another User who manages this user. |
|
|
| roles | Application-specific role strings on the User resource; not RBAC policy. |
|
|
| Service Provider | The system receiving provisioned resources. |
|
|
| Client | The system sending provisioning requests. |
|
|
|
|
## Modeling Assumptions
|
|
|
|
- A **User** is the primary provisionable identity record; there is no separate
|
|
Account or Person resource type in core SCIM.
|
|
- **Groups** absorb membership semantics; there is no first-class relationship
|
|
tuple beyond group membership references.
|
|
- **Organization structure** is flattened into user attributes (department,
|
|
division, organization) rather than modeled as org entities.
|
|
- **Lifecycle** is binary (`active` true/false) with soft-disable semantics;
|
|
deletion is a separate operation.
|
|
- **Uniqueness** is scoped to the service provider; `userName` must be unique
|
|
within the SP namespace.
|
|
- **Authorization** is out of scope; `roles` and group membership are hints
|
|
that downstream systems may map to policies.
|
|
- **Multi-tenancy** is not defined; tenant isolation is an implementation
|
|
concern of the service provider.
|
|
|
|
## Identity-Canon Implications
|
|
|
|
- SCIM **User** maps to **Identity Record** (and often **Account** when the
|
|
SP uses it for login), not to **Natural Person**.
|
|
- SCIM **Group** maps to **Group** collective actor with **Membership
|
|
Relationship** edges to member records.
|
|
- `userName` and `externalId` are **Identifiers** within the SP **Scope**.
|
|
- `active` maps to **Lifecycle State** on the Identity Record.
|
|
- Enterprise extension `manager` suggests a **Representation** or reporting
|
|
relationship, but SCIM does not type it beyond a User reference.
|
|
- `organization`, `department`, `division` are attribute-level hints, not
|
|
**Organization** actors; canon should not treat them as structured org graphs.
|
|
- SCIM reinforces **P2** (person ≠ account) and **P5** (membership explicit)
|
|
but lacks actor-layer primitives.
|
|
|
|
## Terminology Conflicts
|
|
|
|
- **User**: SCIM User is a record, not a human being. Conflicts with
|
|
application "user" meaning login session holder.
|
|
- **Group**: SCIM Group may mean LDAP security group, mailing list, or org
|
|
unit depending on deployment; conflicts with social **Community**.
|
|
- **Role**: SCIM `roles` are opaque strings; conflicts with Cedar/OpenFGA
|
|
relationship-based roles and IAM permission bundles.
|
|
- **Organization**: SCIM extension `organization` is a string attribute;
|
|
conflicts with **Organization** collective actor in IAM products.
|
|
- **Active**: boolean disable vs. full lifecycle states (suspended, archived)
|
|
used in enterprise directories.
|
|
|
|
## Candidate Canonical Mappings
|
|
|
|
| SCIM concept | Candidate canonical concept |
|
|
| --- | --- |
|
|
| User resource | Identity Record (+ Account when login-enabled) |
|
|
| Group resource | Group |
|
|
| member reference | Membership Relationship |
|
|
| userName | Identifier |
|
|
| externalId | Identifier (cross-system correlation) |
|
|
| active | Lifecycle State |
|
|
| manager (extension) | Representation Relationship (weakly typed) |
|
|
| organization/department/division | Affiliation hints; not Organization actors |
|
|
| roles (extension) | Role labels; authorization projection input |
|
|
| meta.created/lastModified | Evidence timestamps for record provenance |
|
|
| Service Provider namespace | Scope |
|
|
|
|
## Open Questions
|
|
|
|
- Should SCIM `externalId` be modeled as a dedicated **Identifier Binding**
|
|
or a generic Identifier with source metadata?
|
|
- How should indirect group membership (`type: indirect`) map to canon
|
|
membership vs. inherited authorization projection?
|
|
- Does the Enterprise User `manager` reference warrant a canonical
|
|
**Reporting Relationship** distinct from Representation?
|
|
- Should a SCIM-only deployment without login map User exclusively to
|
|
Identity Record, skipping Account?
|
|
|
|
## References
|
|
|
|
- RFC 7643: SCIM 2.0 Core Schema — https://datatracker.ietf.org/doc/html/rfc7643
|
|
- RFC 7644: SCIM 2.0 Protocol — https://datatracker.ietf.org/doc/html/rfc7644
|
|
- IETF SCIM working group overview — https://datatracker.ietf.org/wg/scim/about/ |