Looking for advice on implementing SSO for IcingaWeb2 and Grafana (and possibly others)

Hello everyone, I’m doing some research to design a single sign on solution for IcingaWeb2 and Grafana, usable in environments without internet access, open to the possibility of some additions in the future (most probable candidates are Kibana and GitLab or Gitea). We are talking about “community” editions of all the softwares involved.

After some good old RTFM it seems to me that my only option for IcingaWeb2 is to leverage something that has an LDAP interface. I know that I could get the authenticated username from the web server but it is my understanding that it won’t give me user groups that I could use in configuring authorizations in icingaweb2, is that correct?

Also AFAIK IcingaWeb2 does not support OAuth2, OpenID Connect, SAML, JWTs or anything like that. Is there any plan on those? Seems strange to me to be the only one with that itch to scratch, being that they’re becoming ubiquitous and with a good adoption also in enterprise environments.

On the other side Grafana Community should work out of the box and still have role mapping with both LDAP and OAuth2 so it shouldn’t be a problem.

Has anyone done anything like this? What identity provider did you use (the candidates I would research are Keycloak and Gluu), or did you design your solution in another way?

thank you for any advice


Just answering to parts of your question.

As you said, (Open-)LDAP should be a possibility.

This seems to be correct (if not, please correct me).

You can add members of the LDAP backend to groups within icingaweb2.
You can also use filters to only allow a subset of group or groupOfNames members from LDAP to access icingaweb2.
If you do not have a lot of accounts which change frequently, the required effort should not be too high.


Correction: The groups might be sourced from the database backend as well. User authenticates with the webserver → Icinga Web accepts it and looks up groups from the database based on the passed username.

1 Like


Thanks for clarifying this.


thank you @homerjay and @nilmerg , I understand IcingaWeb2 could manage group memberships with its internal database and/or I can filter groups in LDAP queries, but this means that I would have to manage groups in two different places.

While this is a possible solution, I consider it being far from optimal because it partially defeats the original purpose of an SSO solution where both users and their group memberships are managed in a single place for multiple applications and application can “see” the various group memberships and act upon them.

IE: if I understood everything correctly, I can not assign privileges in Director based on group memberships in LDAP.

Side note: integration of the “users” as defined by authentication and IcingaWeb2 / Director with “users” as defined by Icinga “User” objects, and their groupings, is an entirely different beast and AFAIK that is not covered by anything unless we write some custom synchronizations between the two worlds. What I mean is that I cannot create a new user in the identity provider, add him to the relevant groups (also in the identity provider) and expect the user to start receiving the correct notifications from Icinga - I would have to somehow recreate it as an User object in Icinga (possibly via Director) and manage its membership to UserGroup objects in Icinga.