This all depends on the exposure of your Icingaweb both internally and externally.
If your deployment is internal, I do not see much reason for a 2FA as you want your users to see the errors and the status of your monitoring.
If you are exposing the Web to the outside world, first, Don’t ! unless you have too.
Second: a better way will be to put it behind a VPN that requires 2FA , it will be easier to implement and provision then waiting for the request to be integrated in to the Web development.
I agree with @anon66228339 , SSO capability would be much more beneficial, but as IcingaWeb already supports LDAP/AD integration it answers most of the market needs, so I do not expect any added SSO functionality added in the near future (just my two cents).
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.
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.
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.
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.
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
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.
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.
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.
