LDAP group-to-project access mapping #12

New issue

Closed

opened 2026-02-02 21:25:30 +01:00 by qwc · 0 comments

qwc commented

2026-02-02 21:25:30 +01:00

Owner

Currently LDAP group membership only determines a user's global role (admin/editor/viewer). Per-project access is managed manually by admins through the admin panel.

Proposed feature: Allow LDAP groups to be mapped to project access, so that membership in an LDAP group automatically grants a user a specific role on a specific project.

Possible approaches

Config-based mapping:

auth:
  ldap:
    project_groups:
      - group: "cn=api-docs-editors,ou=groups,dc=example,dc=com"
        project: "api-docs"
        role: "editor"
      - group: "cn=internal-viewers,ou=groups,dc=example,dc=com"
        project: "internal-docs"
        role: "viewer"

Periodic sync vs login-time sync:

Login-time: Update project_access rows each time the user authenticates via LDAP. Simple, but access only updates on login.
Periodic background sync: A goroutine that queries LDAP group memberships on an interval and syncs project_access. More complex but keeps access up to date even without user login.

Considerations

Should LDAP-managed project access be marked differently from manually granted access (e.g. a source column on project_access) so admins know which entries are auto-managed?
Should manual overrides take precedence over LDAP-synced access?
How to handle group removal — revoke access on next sync/login?

Currently LDAP group membership only determines a user's global role (admin/editor/viewer). Per-project access is managed manually by admins through the admin panel. **Proposed feature:** Allow LDAP groups to be mapped to project access, so that membership in an LDAP group automatically grants a user a specific role on a specific project. ### Possible approaches **Config-based mapping:** ```yaml auth: ldap: project_groups: - group: "cn=api-docs-editors,ou=groups,dc=example,dc=com" project: "api-docs" role: "editor" - group: "cn=internal-viewers,ou=groups,dc=example,dc=com" project: "internal-docs" role: "viewer" ``` **Periodic sync vs login-time sync:** - **Login-time:** Update `project_access` rows each time the user authenticates via LDAP. Simple, but access only updates on login. - **Periodic background sync:** A goroutine that queries LDAP group memberships on an interval and syncs `project_access`. More complex but keeps access up to date even without user login. ### Considerations - Should LDAP-managed project access be marked differently from manually granted access (e.g. a `source` column on `project_access`) so admins know which entries are auto-managed? - Should manual overrides take precedence over LDAP-synced access? - How to handle group removal — revoke access on next sync/login?

qwc referenced this issue

2026-02-03 11:28:27 +01:00

add a viewer_group to ldap configuration #26

qwc referenced this issue from a commit

2026-02-03 12:34:08 +01:00

Add LDAP/OAuth2 group-based authentication enhancements

qwc closed this issue

2026-02-03 12:36:31 +01:00

qwc referenced this issue

2026-05-18 20:35:54 +02:00

Synchronize Handler shared state (H-10) #107