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=falseoidc_default_admin=falseoidc_default_groups=["viewers"][[oidc_role_mapping]]role="Admin"enabled=trueadmin=truegroups=["admins"][[oidc_role_mapping]]role="Operator"enabled=trueadmin=falsegroups=["operators"][[oidc_role_mapping]]role="Viewer"enabled=trueadmin=falsegroups=["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:
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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
adminoruser_groupmembership. Komodo already has a strong authorization model based onadminanduser_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/falseadmin = true/falseuser_groupmembershipThis 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
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:
Expected behavior
user_groups.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.@johnmaguire commented on GitHub (Apr 2, 2026):
I believe this is a dupe of #667, but with more specific details.