This document discusses single sign-on (SSO) and why it is better than traditional LDAP authentication. It describes various SSO protocols like SAML, OAuth, and Kerberos. While LDAP is sometimes used for SSO, it has security risks since each application handles credentials separately. The document recommends using a true SSO solution instead, which avoids firewall openings, provides a consistent login experience across applications, and delegates security responsibilities. It then describes how the author set up Icingaweb2 to use Active Directory Federation Services for SSO and group mapping through an open-source project. A demo of the SSO process is provided.

1. Your observability expert

2. Why you should use true SSO
Luke Gripenberg
2

3. Who am I?
● Senior consultant
○ Developer
■ Web applications, monitoring
● Working in the monitoring space since 2008
● System administrator
● Built my first SSO application in 2007
● Avid password manager user
○ Reluctantly so

4. What is SSO?
● Single-Sign On
● A seamless sign in experience
○ No need to retype credentials
○ Just use the application
● Less passwords needed
● Today will cover web-based
applications

5. What SSO types are there?
● Kerberos
○ Often requires browser configuration
● SAML
○ Security Assertion Markup Language
● OAuth
○ Version 1
○ Version 2
● Others

6. Others
● CAS
● Apache Authtkt
● OpenID
● OpenID Connect
● IndieAuth
● WS-Fed
● CAS
● Client certificates
● SCIM
● ZXID
● LTPA
● DACS
● IceWall SSO
● Company-specific SSO
○ Microsoft, Twitter, etc.
● Authpubtkt
● Shibboleth

7. LDAP
● Lightweight Directory Access Protocol
● Sometimes conflated with SSO
● Most applications support this
● Require firewall rules
● Passthru authentication

8. LDAP
● Security risks
○ Passthru authentication
■ All applications must be trusted to handle these correctly
■ Certificates do not protect this
○ Login processes for different applications look
different
● Passwords must be typed in every time
a logon has expired

9. Passthru authentication
Icingaweb2
Password
Vault
Ticketing
System
HR system
Messaging
system
E-mail
system
Username
Password
Active
Directory

10. But SSL certificates?
● Often reused
○ Wildcard certificate: *.example.com
● Often untrusted

11. Use SSO instead
● Applications do not handle credentials at all
● No firewall openings needed
○ On premise / off premise difference doesn’t matter any more
● If sign in is needed, same dialog every time
● No plugins needed
● Delegate security concerns
○ Reduce attack surface
● Customers can sign in with their own accounts
● Compliance responsibility lies with SSO provider

12. Our contribution
● A guide to setting up Icingaweb2 SSO with Active
Directory Federation Services
● Group mapping
○ No generic users needed
○ Open-source code
● Local sign in without multiple ports
● Available today

13. Based on
● mod_auth_mellon (UNINETT)
○ https://github.com/Uninett/mod_auth_mellon
● MySQL group backend
○ Built-in

14. Demo

15. Monitoring
- Endpoints
- Sign-in process
- Services on ADFS server
- SAML endpoints on Service Provider end
- Internal tests in ADFS
- Powershell: Test-ADFSServerHealth
- Run on NSClient++

16. Monitoring
- ADFS
- Event Viewer
- Application and Services Log -> AD FS -> Admin

17. Check it out
- github.com/opsdis/icinga-adfs
- Pull requests welcome

18. Q&A
18

19. Sources
https://ehloes.wordpress.com/2016/07/07/monitoring-adfs/
https://www.uoguelph.ca/ccs/security/internet/single-sign-sso/
benefits
https://www.csoonline.com/article/2115776/what-is-single-sig
n-on-how-sso-improves-security-and-the-user-experience.html
https://ldapcon.org/2017/wp-content/uploads/2017/08/16_Cl%
C3%A9ment-Oudot_PRE_LDAPCon2017_SSO-1.pdf