You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remote authentication using the X-Remote-User header creates a user on demand but does not support assigning groups.
Describe the solution you'd like
Configuring a second header, e.g. X-Remote-Groups, with the list of groups a user should have, would ease mapping group memberships from remote auth, such as OIDC or SAML.
For example:
X-Remote-User: john
X-Remote-Groups: administrator, service-a-manager
Describe alternatives you've considered
The documentation recommends setting up LDAP group sync, but that would require LDAP infrastructure to be present and to contain the users and groups. In many modern environments, that might not be given anymore, e.g. users are managed on IdPs, such as Entrea ID, Octa, GitHub, Google, or Authentik. Some might offer LDAP endpoints, which would need extra configuration, but others do not.
Maintaining a standalone LDAP only for Icingaweb2 group mappings is tedious, or impossible, if users are not known upfront.
Additional context
The header could be specified in a configuration, and, if no header is configured, nothing would happen.
If the header must contain all groups for user, it would support addition and removal, or only stored in the session/not at all.
The text was updated successfully, but these errors were encountered:
Remote authentication using the
X-Remote-User
header creates a user on demand but does not support assigning groups.Describe the solution you'd like
Configuring a second header, e.g.
X-Remote-Groups
, with the list of groups a user should have, would ease mapping group memberships from remote auth, such as OIDC or SAML.For example:
Describe alternatives you've considered
The documentation recommends setting up LDAP group sync, but that would require LDAP infrastructure to be present and to contain the users and groups. In many modern environments, that might not be given anymore, e.g. users are managed on IdPs, such as Entrea ID, Octa, GitHub, Google, or Authentik. Some might offer LDAP endpoints, which would need extra configuration, but others do not.
Maintaining a standalone LDAP only for Icingaweb2 group mappings is tedious, or impossible, if users are not known upfront.
Additional context
The header could be specified in a configuration, and, if no header is configured, nothing would happen.
If the header must contain all groups for user, it would support addition and removal, or only stored in the session/not at all.
The text was updated successfully, but these errors were encountered: