2FA for Icinga Web 2

I’ve actually started developing SAML/ADFS support for my employer at the moment - I am not sure if we plan on open sourcing this, but adding SAML support for us inherently adds 2FA when it meets the criteria from the IDP.

I do think it is beneficial to have 2FA for users that are using the built-in/database authentication, but does it not make sense to leave 2FA authentication backend, rather than trying to bolt-on 2FA to Icinga itself?

It should be up to the backend to provide the criteria to successfully authenticate - e.g we are using Duo for 2FA and ADFS as our identity provider.

Duo would take care of hardware token, push notifications, biometrics, etc.

This would be true for other MFA solutions (Okta, OneLogin, etc).

As a user, I wouldn’t want to configure an entirely new 2FA solution in Icinga - it makes much more sense to hand this off to an already existing service - if I already require 2FA on my applications, it’s increasingly likely I already have a 2FA/SSO/SAML solution in place.

EDIT: I also want to mention that asking users not to expose Icinga Web to the world is unrealistic. If there are vulnerabilities in Icinga Web, the same would apply internally and that should be addressed appropriately. If I was a prospective customer of Icinga and got told I shouldn’t expose the web interface, that would instantly raise suspicions with our CISO/CTO and we would likely ditch the product.

1 Like

IMAO you can expose Icinga Web, but (just to be sure) with a reverse proxy doing (external) authn for you.

Maybe my answer was a bit short. But no matter what it will be at the end, dont you think icinga have enough ‘road works’ that should be finished/fixed first before there are ‘another’ thing put into it?

From my view i would love if icinga & icingaweb2 get a feature freeze and fix, build the things that are allready on the roadmap first before new features are added.

1 Like

Hey Carsten,
as I mentioned in my posts before, we are currently restructuring and working on getting our development process streamlined and more open.
This is part of it.

I want to thank you for your concern, but I think we are able to handle this.

We are not abandoning existing problems for the sake of adding new features, but we are allocating our resources in a way that we think is a good balance between adding features that are requested and asked for a lot and fixing / improving existing issues.

I would like to ask you to trust us to make good decisions.

Thank you,


Hi @0xliam
The reason not to expose it to the world is not related to the security of Icinga, but more related to exposing the data of your internal systems to the outside world.
I am a CISO and I can tell you that the information that a monitoring system gathers and exposes is a treasure trove for any attacker or bots in the world, the version of your http servers, status of your SSL/TLS , version of OpenSSH, OS patching etc’.
All those are things that ( if you do) can be used to expose an attack vector to your organization ( and there are many more I did not mention) and due to that you do not want to expose your monitoring to the world.



That’s understandable - I suppose that’s a risk we are willing to accept as our customers connect from all around the country and we need the Director API exposed - too many firewall rules to manage with our systems at the moment.

I suppose 2FA would mitigate this risk for the most part anyway - hence why we’re looking at implementing SAML ourselves.

Whilst I do think 2FA is important for people using the built-in user database, we’re only using this because we were not comfortable exposing our corporate LDAP servers. It made more sense to just implement native SAML rather than trying to hack together bits of technology (proxies, etc).

I would strongly argue that SAML is more useful than 2FA as most organisations are going to have some kind of SAML compatible identity provider - e.g. Office 365, Google Apps, Okta, ADFS, etc. already in place.

I may be wrong on this point though. I’m not too familiar with the customer base.

If SAML was supported, we would not be using the built-in authentication, and I am curious to know whether that is true for any other users.

@theFeu I am sure there are already existing discussions around SAML/2FA internally, but I would be curious to see how customers of Icinga partners would prefer 2FA over SAML or vice versa.

1 Like

Hi @0xliam!

We started a twitter poll about it yesterday, if you want to have a look: https://twitter.com/icinga/status/1247099912250175488?s=20
This is of course the general public voting here, but there were around 60 people who voted, last time I checked.

This here is an initial discussion, as far as I know, so I don’t have any intel about the customers wishes to share with you.
I could tell you, what we feel like they’d want, but that would be purely speculative :slight_smile:

Have a nice day,

1 Like

I’m a proponent of delegating these security issues to other parties. This way one can avoid ‘rolling one’s own security’ as much as possible. I like the external authentication mechanism in Icingaweb2 (so you can use oauth2, saml, etc and add 2fa using a 3rd party authentication solution), though I really wish a way to pass group information would exist, like header authentication.

@0xliam, I’ve implemented a mechanism for SAML authentication which has been tested with Okta and ADFS, in case you are interested: https://github.com/opsdis/icinga-adfs - I’d definitely appreciate some feedback if you try it out.


I would also like to express our view of things:
In our company this feature isn’t relevant. Because only our IT department is using Icinga. We have no external customers. So there is no need for this. But I can understand if a company with customers would give them access to icinga.

But like other people wrote here, we also use other methods for authentication to our system. So isn’t it better to support interfaces/APIs/protocols from other tools, that have already proven themselves in the own company Like @anon66228339 wrote SSO or like @0xliam wrote SAML etc. So in my eyes it should be better to extend the list of supported authentication methods like AD and LDAP instead of creating your own new authentication method. Maybe some companies already use a 2FA authenction tool. Maybe they have to bought it from an company and they want to to us this also for Icinga.

We for example use ID Cards, certificates etc. We have an application portal where our web applications are integrated. For this we can use SAML and reversproxy over HTTP headers.

So we think it’s better to support some standards for authentication so everybody can use their own prefered 3rd party tools/logins if needed. 2FA shouldn’t be a must.


SSO beat 2FA:

Please could all of you SSO users summarize the top 1-3 relevant SSO standards? So we can let you vote again on Twitter.

I don’t use twitter :wink:

I know…already quite an old thread, but I really want to emphasize: SSO != 2FA and 2FA != SSO…it would be to compare apples and pies.
Especially as it seems that most of the people here think of Kerberos then.

Within internal, 90’s networks I would sign that way but in 2019/20…?
Especially new modern IDMS / Federation / IDP systems would prefer other modern techniques, especially being more for usable for the web by design (e.g. SAML / OAuth). That would help to use all kind of IdPs (no matter if you have some Okta, or AzureAD or …) and bring 2FA (or let’s better call it MFA) with it.

Would you say SAML and OAuth are the top two industry standards? If yes, is there also a third relevant one?

OpenID is probably the third most common standard.

@theFeu Shall we poll for the most desired SSO mechanism of these three?

Isn’t it better to first take a look at how these differ? How these work? How much is required to support them? (e.g. OAuth(2) is mostly configuration) Maybe it’s not much to support all three?

While the poll about MFA vs SSO has certainly been interesting, creating another one seems unnecessary to me.

If e.g. 90% want SAML, would you implement all three?

I would agree with OAuth(2), SAML and OpenID for SSO.
Old-school would prefer Kerberos :wink:

SCIM would be something regarding provisioning.

In general it’s preferred to have good SSO with MFA. I can do this alreaby for example by using mod_auth_openidc in apache.

The biggest problem in general with adding MFA is always the API and/or third party apps using that. DevOps engineers sometimes have an app on their phone to quickky view / get alerts on criticals.

Looking at other tools, the possiblity of API tokens often allows for the rollout of SSO and/or MFA.

I just found oauth_proxy which seems to be usable as external backend in icingaweb2

Unfortunately the documentation to integrate with AzureAD is not that up to date…does anybody has any experience with this?