Distribute frozen commercial research provenance
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
parent
8a07292dd7
commit
8a89a6869e
40 changed files with 7201 additions and 4 deletions
|
|
@ -0,0 +1,138 @@
|
|||
# Keycloak Organizations
|
||||
|
||||
## Source Type
|
||||
|
||||
Product documentation and implementation reference for Keycloak 26+ organization
|
||||
features and core realm/user/group/role model.
|
||||
|
||||
## Domain
|
||||
|
||||
Multi-tenant IAM, B2B/B2B2C organization management, and OIDC/SAML federation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Keycloak organizations, realms, groups, roles, clients, and B2B/B2B2C
|
||||
organization management terminology.
|
||||
|
||||
Keycloak is a widely deployed open-source IAM product. Its newer Organizations
|
||||
feature adds first-class B2B org semantics on top of the classic realm model,
|
||||
making it a live vocabulary source for tenant/org/customer overlap.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Realm**: top-level administrative and security namespace; owns users,
|
||||
clients, identity providers, roles, groups, and authentication flows.
|
||||
- **User**: realm-local account with credentials, attributes, group/role
|
||||
mappings, and federation links.
|
||||
- **Organization** (26+): B2B entity with members, domains, identity providers,
|
||||
and invited users; supports multi-org membership per user.
|
||||
- **Organization member**: user linked to an organization with membership
|
||||
metadata (roles within the org context).
|
||||
- **Group**: realm-level hierarchical collection for user grouping and role
|
||||
mapping.
|
||||
- **Role**: realm role or client role; assigned directly, via group, or via
|
||||
composite roles.
|
||||
- **Client**: OIDC/SAML application registered in a realm; may represent a
|
||||
tenant application or service.
|
||||
- **Identity Provider (IdP)**: federated authentication source brokering
|
||||
external identities into realm users.
|
||||
- **User federation**: LDAP/AD/Kerberos bridge supplying or syncing users.
|
||||
- **Attribute**: key-value metadata on users, clients, or organizations.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Realm | Hard identity/admin boundary; separate user namespace per realm. |
|
||||
| User | Realm-local login account with credentials and profile attributes. |
|
||||
| Organization | B2B org actor within a realm; has domains, members, and IdP config. |
|
||||
| Member | User belonging to an organization. |
|
||||
| Group | Realm hierarchy node; users inherit roles through group membership. |
|
||||
| Role | Named permission bundle at realm or client scope. |
|
||||
| Client | Application or service consuming tokens from the realm. |
|
||||
| Identity Provider | External auth source; may assert identities into realm users. |
|
||||
| Domain (org) | Email domain associated with an organization for discovery/broker routing. |
|
||||
| Federated identity | Link between realm user and external IdP identity. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Realm is the primary isolation boundary** for users, credentials, and
|
||||
admin policy.
|
||||
- **User means account** in product vocabulary; one realm user per login
|
||||
identity within that realm.
|
||||
- **Organization is a B2B overlay** within a realm, not a replacement for
|
||||
realm or tenant infrastructure boundaries.
|
||||
- **Groups carry authorization semantics** through role mapping, not just
|
||||
social grouping.
|
||||
- **Roles are permission bundles**, assignable directly or transitively via
|
||||
groups and composites.
|
||||
- **Federation links** connect external IdP identities to local users via
|
||||
brokered login.
|
||||
- **Multi-org membership** is supported: one user can belong to multiple
|
||||
organizations in the same realm.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Keycloak **Realm** maps to **Realm** (Scope specialization) with hard
|
||||
namespace boundaries.
|
||||
- Keycloak **User** maps to **Account** in a realm Scope; not **Natural
|
||||
Person**.
|
||||
- Keycloak **Organization** maps to **Organization** collective actor with
|
||||
**Membership Relationship** to member Accounts.
|
||||
- **Group** maps to **Group** with Membership edges; role inheritance is
|
||||
authorization projection.
|
||||
- **Role** maps to **Role** (authorization projection), not membership.
|
||||
- **Client** maps to application **Scope** or registered resource in
|
||||
authorization domain.
|
||||
- **Federated identity** link maps to **Synonymity Assertion** or
|
||||
**Identifier Binding** between external IdP identifier and local Account.
|
||||
- **Domain** on organization is an **Identifier** used for discovery routing.
|
||||
- Supports scenarios S03 (enterprise orgs), S04 (vendor/customer B2B), S05
|
||||
(delegated admins via roles/groups).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Realm vs. Tenant**: Keycloak realm is both issuer namespace and admin
|
||||
partition; products often call this "tenant."
|
||||
- **User vs. Member**: org member is still a realm User; membership is a
|
||||
relationship overlay.
|
||||
- **Organization vs. Group**: both exist; org has B2B semantics (domains, IdP),
|
||||
group is generic hierarchy.
|
||||
- **Role vs. Membership**: group membership implies role inheritance;
|
||||
conflates relationship types.
|
||||
- **Client vs. Tenant**: clients are applications, not customer isolation
|
||||
boundaries.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Keycloak concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Realm | Realm (Scope) |
|
||||
| User | Account |
|
||||
| Organization | Organization |
|
||||
| Organization membership | Membership Relationship |
|
||||
| Group | Group |
|
||||
| Group membership | Membership Relationship |
|
||||
| Role (realm/client) | Role (authorization projection) |
|
||||
| Client | Application Scope / registered client |
|
||||
| Identity Provider | Trust Relationship + external issuer Scope |
|
||||
| Federated identity link | Synonymity Assertion / Identifier Binding |
|
||||
| User attribute | Profile attribute or Claim |
|
||||
| Organization domain | Identifier (email domain) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should Keycloak Realm remain a **Realm** specialization or absorb **Tenant**
|
||||
semantics when used as SaaS isolation?
|
||||
- How should multi-org user membership be modeled when the same Account holds
|
||||
Membership edges to multiple Organizations?
|
||||
- Does Keycloak Organization domain verification warrant a **Claim** or
|
||||
**Evidence Source** in canon?
|
||||
- Should composite roles be modeled as Role aggregation or as derived
|
||||
authorization projection only?
|
||||
|
||||
## References
|
||||
|
||||
- Keycloak Organizations documentation — https://www.keycloak.org/docs/latest/server_admin/#_organizations
|
||||
- Keycloak Server Administration Guide — https://www.keycloak.org/docs/latest/server_admin/
|
||||
- Keycloak Realm concepts — https://www.keycloak.org/docs/latest/server_admin/#_create-realm
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
# ZITADEL Organizations and Projects
|
||||
|
||||
## Source Type
|
||||
|
||||
Product documentation and implementation reference for ZITADEL's multi-instance
|
||||
organization, project, and grant model.
|
||||
|
||||
## Domain
|
||||
|
||||
Cloud-native IAM, multi-tenancy, B2B SaaS identity, and fine-grained
|
||||
authorization grants.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
ZITADEL organizations, projects, roles, grants, and multi-tenancy concepts.
|
||||
|
||||
ZITADEL is designed for multi-tenant SaaS from the ground up. Its org →
|
||||
project → grant hierarchy provides a live product vocabulary for separating
|
||||
customer organizations, application projects, and role grants.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Instance**: ZITADEL deployment; top-level operational boundary.
|
||||
- **Organization**: primary tenant/customer entity; owns users, projects,
|
||||
policies, and branding.
|
||||
- **Project**: application or service scope within an organization; owns roles,
|
||||
applications, and grants.
|
||||
- **Application**: OIDC/SAML/API client registered under a project.
|
||||
- **User**: human identity within an organization with authentication methods
|
||||
and profile.
|
||||
- **Machine user / service user**: non-human identity for API access.
|
||||
- **Grant**: assignment of project roles to a user or organization (including
|
||||
cross-org grants for B2B).
|
||||
- **Role**: project-scoped permission label granted via grants.
|
||||
- **Organization domain**: verified domain for org discovery and policy.
|
||||
- **User grant vs. org grant**: direct user-to-project role vs. org-wide
|
||||
project access.
|
||||
- **Actions / Flows**: customizable authentication and provisioning pipelines.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Organization | Customer or business entity; primary multi-tenant partition. |
|
||||
| Project | Application or product scope within an org. |
|
||||
| Grant | Role assignment linking user or org to a project. |
|
||||
| Role | Named capability within a project. |
|
||||
| User | Human identity record within an organization. |
|
||||
| Machine user | Service identity for programmatic access. |
|
||||
| Application | Registered client (OIDC/SAML/API) under a project. |
|
||||
| Instance | ZITADEL deployment boundary. |
|
||||
| Org grant | Organization-level access to a project's roles. |
|
||||
| Domain verification | Proof that an org controls an email domain. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Organization is the primary customer/tenant boundary** for users and
|
||||
admin delegation.
|
||||
- **Project separates applications** within an org; roles are project-scoped.
|
||||
- **Grants are the authorization assignment mechanism**, not group membership.
|
||||
- **Users belong to exactly one organization** (per current product model);
|
||||
cross-org access is via grants to shared projects.
|
||||
- **Machine users are first-class** identities distinct from human users.
|
||||
- **B2B** is modeled by granting one organization's project roles to another
|
||||
organization's users or to the org itself.
|
||||
- **Branding and login policy** are org-scoped configuration.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- ZITADEL **Organization** maps to **Organization** actor and/or **Tenant**
|
||||
Scope depending on deployment (often both: org as actor, org as tenant
|
||||
boundary).
|
||||
- **Project** maps to **Application Scope** or child **Scope** under tenant.
|
||||
- **User** maps to **Account** (human); **Machine user** maps to **Service
|
||||
Account**.
|
||||
- **Grant** maps to **Role** assignment via **Delegation** or Membership-like
|
||||
relationship with authorization implication.
|
||||
- **Role** maps to **Role** (authorization projection).
|
||||
- **Application** maps to registered client within Application Scope.
|
||||
- **Domain verification** maps to **Claim** or **Evidence Source** for org
|
||||
domain ownership.
|
||||
- Product vocabulary strongly supports S04 (vendor/customer) and S05
|
||||
(delegated admin via grants).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Organization vs. Tenant**: ZITADEL uses "organization" for what SaaS
|
||||
products often call "tenant."
|
||||
- **Grant vs. Membership**: grants assign roles; no generic group concept at
|
||||
project level.
|
||||
- **User vs. Account**: product says "user" but means org-local identity
|
||||
record with credentials.
|
||||
- **Project vs. Application**: project is container; application is client;
|
||||
both compete with "tenant" in other products.
|
||||
- **Role vs. Grant**: role is definition; grant is assignment; IAM products
|
||||
often collapse these.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| ZITADEL concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Instance | Scope (deployment boundary) |
|
||||
| Organization | Organization + Tenant Scope |
|
||||
| Project | Application Scope |
|
||||
| User | Account |
|
||||
| Machine user | Service Account |
|
||||
| Application | Registered client / Application Scope |
|
||||
| Role | Role (authorization projection) |
|
||||
| Grant | Role assignment relationship (Delegation-like) |
|
||||
| Org grant | Membership or Delegation at org level |
|
||||
| Domain verification | Claim + Evidence Source |
|
||||
| User profile | Profile |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- When ZITADEL Organization serves as both commercial actor and isolation
|
||||
boundary, should canon use one node with dual typing or separate Organization
|
||||
+ Tenant linked by Ownership?
|
||||
- How should cross-org project grants map: **Delegation**, **Trust**, or a
|
||||
vendor-specific **Grant Relationship**?
|
||||
- Does single-org-per-user constraint affect canon modeling of multi-org
|
||||
persons (S02)?
|
||||
- Should Machine user always map to Service Account, or sometimes to
|
||||
Artificial Agent?
|
||||
|
||||
## References
|
||||
|
||||
- ZITADEL documentation — https://zitadel.com/docs
|
||||
- ZITADEL Organizations — https://zitadel.com/docs/guides/manage/console/organizations
|
||||
- ZITADEL Projects and roles — https://zitadel.com/docs/guides/manage/console/projects
|
||||
Loading…
Add table
Add a link
Reference in a new issue