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.
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
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
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
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++