[GH-ISSUE #1251] [Feature request] - OIDC role mapping #16449

New Issue

GiteaMirror · 2026-05-29T00:59:11-05:00

GiteaMirror commented

2026-05-29 00:59:11 -05:00

Originally created by @kabsdk on GitHub (Mar 16, 2026).
Original GitHub issue: https://github.com/moghtech/komodo/issues/1251

Disclaimer: This feature request has been written with the help of AI

Feature request

Please add OIDC role/group mapping so Komodo can automatically authorize users on login based on OIDC claims, similar to Grafana’s OIDC role mapping.

Today, OIDC login works, but OIDC users still need to be manually enabled after first login, and there is no built-in way to map OIDC claims/groups to Komodo authorization such as admin or user_group membership. Komodo already has a strong authorization model based on admin and user_group, and the config format already uses repeated TOML blocks like [[user_group]], so this feels like a natural fit for the existing config style.

Motivation

This is especially useful for setups using Authentik, Keycloak etc., where roles or groups are already present in the OIDC token/userinfo response.

Without mapping, OIDC is mostly authentication-only, and authorization still has to be handled manually inside Komodo. For larger environments, that becomes hard to manage.

A Grafana-style approach would make Komodo much easier to integrate into existing identity systems while still keeping Komodo’s own permission model. Grafana already supports OIDC role extraction through role_attribute_path, which is a good reference point for the user experience.

Proposed behavior

Allow Komodo to evaluate OIDC claims and map them to:

enabled = true/false
admin = true/false
user_group membership

This should happen automatically during OIDC login, so users do not need to be manually enabled or manually added to groups afterward.

Suggested config format

I think the cleanest approach is to keep this Komodo-native and TOML-based.

Option A: role mapping inspired by Grafana

oidc_enabled = true
...

# Evaluate against OIDC claims payload.
# Returns a logical role string which is then mapped below.
oidc_role_attribute_path = "contains(groups[*], 'komodo-admin') && 'Admin' || contains(groups[*], 'komodo-operator') && 'Operator' || 'Viewer'"

# If true, deny login when no mapping matches.
oidc_role_attribute_strict = false

# Optional fallback values when no role mapping matches.
oidc_default_enabled = false
oidc_default_admin = false
oidc_default_groups = ["viewers"]

[[oidc_role_mapping]]
role = "Admin"
enabled = true
admin = true
groups = ["admins"]

[[oidc_role_mapping]]
role = "Operator"
enabled = true
admin = false
groups = ["operators"]

[[oidc_role_mapping]]
role = "Viewer"
enabled = true
admin = false
groups = ["viewers"]

This is close to Grafana conceptually, but instead of introducing a separate Komodo RBAC layer, it maps into Komodo’s existing authorization model.

Option B: direct group mapping

This may be even simpler and may fit Komodo better for many IdPs:

oidc_groups_attribute_path = "groups"
oidc_groups_strict = false

[[oidc_group_mapping]]
external = "komodo-admin"
enabled = true
admin = true
groups = ["admins"]

[[oidc_group_mapping]]
external = "komodo-operator"
enabled = true
admin = false
groups = ["operators"]

[[oidc_group_mapping]]
external = "komodo-viewer"
enabled = true
admin = false
groups = ["viewers"]

Expected behavior

On first OIDC login, matching users can be automatically enabled.
Matching users can automatically become admin if configured.
Matching users can automatically be added to one or more existing Komodo user_groups.
Multiple matching mappings should merge group membership.
If multiple mappings match, highest privilege should win.
Optional strict mode should deny login if no valid mapping is found.

Important detail

I think mappings should reference existing Komodo user group names, not define permissions inline.

That keeps permissions centralized in normal Komodo [[user_group]] config and avoids duplicating permission logic in the OIDC section.

Originally created by @kabsdk on GitHub (Mar 16, 2026). Original GitHub issue: https://github.com/moghtech/komodo/issues/1251 **Disclaimer: This feature request has been written with the help of AI** # Feature request Please add OIDC role/group mapping so Komodo can automatically authorize users on login based on OIDC claims, similar to Grafana’s OIDC role mapping. Today, OIDC login works, but OIDC users still need to be manually enabled after first login, and there is no built-in way to map OIDC claims/groups to Komodo authorization such as `admin` or `user_group` membership. Komodo already has a strong authorization model based on `admin` and `user_group`, and the config format already uses repeated TOML blocks like `[[user_group]]`, so this feels like a natural fit for the existing config style. # Motivation This is especially useful for setups using Authentik, Keycloak etc., where roles or groups are already present in the OIDC token/userinfo response. Without mapping, OIDC is mostly authentication-only, and authorization still has to be handled manually inside Komodo. For larger environments, that becomes hard to manage. A Grafana-style approach would make Komodo much easier to integrate into existing identity systems while still keeping Komodo’s own permission model. Grafana already supports OIDC role extraction through `role_attribute_path`, which is a good reference point for the user experience. # Proposed behavior Allow Komodo to evaluate OIDC claims and map them to: - `enabled = true/false` - `admin = true/false` - `user_group` membership This should happen automatically during OIDC login, so users do not need to be manually enabled or manually added to groups afterward. # Suggested config format I think the cleanest approach is to keep this Komodo-native and TOML-based. ## Option A: role mapping inspired by Grafana ```toml oidc_enabled = true ... # Evaluate against OIDC claims payload. # Returns a logical role string which is then mapped below. oidc_role_attribute_path = "contains(groups[*], 'komodo-admin') && 'Admin' || contains(groups[*], 'komodo-operator') && 'Operator' || 'Viewer'" # If true, deny login when no mapping matches. oidc_role_attribute_strict = false # Optional fallback values when no role mapping matches. oidc_default_enabled = false oidc_default_admin = false oidc_default_groups = ["viewers"] [[oidc_role_mapping]] role = "Admin" enabled = true admin = true groups = ["admins"] [[oidc_role_mapping]] role = "Operator" enabled = true admin = false groups = ["operators"] [[oidc_role_mapping]] role = "Viewer" enabled = true admin = false groups = ["viewers"] ```` This is close to Grafana conceptually, but instead of introducing a separate Komodo RBAC layer, it maps into Komodo’s existing authorization model. ## Option B: direct group mapping This may be even simpler and may fit Komodo better for many IdPs: ```toml oidc_groups_attribute_path = "groups" oidc_groups_strict = false [[oidc_group_mapping]] external = "komodo-admin" enabled = true admin = true groups = ["admins"] [[oidc_group_mapping]] external = "komodo-operator" enabled = true admin = false groups = ["operators"] [[oidc_group_mapping]] external = "komodo-viewer" enabled = true admin = false groups = ["viewers"] ``` # Expected behavior * On first OIDC login, matching users can be automatically enabled. * Matching users can automatically become admin if configured. * Matching users can automatically be added to one or more existing Komodo `user_group`s. * Multiple matching mappings should merge group membership. * If multiple mappings match, highest privilege should win. * Optional strict mode should deny login if no valid mapping is found. # Important detail I think mappings should reference **existing Komodo user group names**, not define permissions inline. That keeps permissions centralized in normal Komodo `[[user_group]]` config and avoids duplicating permission logic in the OIDC section.

GiteaMirror commented

2026-05-29 00:59:12 -05:00

@johnmaguire commented on GitHub (Apr 2, 2026):

I believe this is a dupe of #667, but with more specific details.

@johnmaguire commented on GitHub (Apr 2, 2026): I believe this is a dupe of #667, but with more specific details.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#16449