Seit der Einführung von Single Sign-On (SSO) haben wir viel positives Feedback von unseren Kunden erhalten, die sich nun ein Passwort weniger merken müssen. Obwohl SSO die Kernfunktionen von PagerDuty für das Performance-Management nicht beeinträchtigt, erforderte die Planung und Implementierung der neuen Funktion sorgfältige Überlegung.

Einen Plan entwickeln

Nachdem wir uns entschieden hatten, Single Sign-On für PagerDuty anzubieten, war uns klar, dass wir eine Lösung benötigten, die sich nahtlos in unsere Rails-Anwendung integrieren lässt. Wir recherchierten verschiedene Möglichkeiten und kamen schließlich zu dem Schluss, dass das Ruby SAML Toolkit von OneLogin die beste Lösung für uns ist. Es genießt das Vertrauen anderer Unternehmen in unserer Branche und bietet alle Funktionen, die wir uns vorgestellt haben.

Um sicherzustellen, dass dies funktioniert, haben wir einen funktionierenden Prototyp mit einer einfachen Implementierung entwickelt. Ein Endpunkt dient dazu, die Authentifizierung von unserer Seite aus zu initiieren, und ein weiterer empfängt die Antwort der Identitätsanbieter.

Der Machbarkeitsnachweis war erfolgreich, sodass wir mit der Entwicklung der gewünschten Funktion beginnen konnten.

OneLogins Ruby SAML Toolkit

Um sicherzustellen, dass die Verwendung des Ruby-SAML-Toolkits von OneLogin keine Sicherheitslücken in unseren Systemen verursacht, begannen wir mit einer Kombination aus manuellen und automatisierten Tests. Ein getestetes Szenario war, was passiert, wenn eine SAML-Antwort eines Identitätsanbieters abgefangen und anschließend manipuliert wird (z. B. durch Änderung der E-Mail-Adresse). Das Toolkit verfügt bereits über einige Prüfpunkte für dieses Szenario und verhindert daher die Authentifizierung.

Trotz der umfangreichen Funktionalität des Toolkits haben wir einige Anpassungen vorgenommen, um es an unsere Bedürfnisse anzupassen und die PagerDuty -Zertifizierung zu erhalten. Beispielsweise haben wir die SAML-Endpunkte so konfiguriert, dass sie immer SSL verwenden, und sichergestellt, dass die Gültigkeitsdauer der Zertifikate eingehalten wird.

Und wie sieht es mit Mobile und SAML aus?

Um SSO für unsere mobilen Anwendungen zu unterstützen, haben wir SAML in Kombination mit OAuth verwendet, wobei unsere iOS- und Android-Anwendungen nach erfolgreicher SAML-Authentifizierung ein Authentifizierungstoken erhalten.

Erkenntnisse aus Kundenvorschauen

Vor jeder größeren Veröffentlichung geben wir einigen unserer Kunden die Möglichkeit, die kommende Funktion im Rahmen eines Testlaufs vorab zu prüfen. Dies ermöglicht es uns nicht nur, Fehler zu finden und die Anwendungsfälle unserer Kunden genauer zu analysieren, sondern (und das ist wohl noch wichtiger) uns auch, die neue Funktion effektiv zu überwachen.

Verfeinerung der Überwachung für umsetzbare Warnmeldungen

Wir überwachen unsere Single-Sign-On-Funktion hauptsächlich mit Sumo Logic. Die Einrichtung des Sumo-Logic-Monitorings für unsere SAML- und OAuth-Endpunkte während der Kundenvorschau hat uns die Möglichkeit gegeben, zu erfahren, was wir überwachen sollten.

In unserer anfänglichen Konfiguration stellten wir fest, dass unsere Warnmeldungen nicht detailliert genug (oder nicht handlungsrelevant) waren. Wir erhielten häufig die Meldung „Ungültige SAML-Antwort“, was dazu führte, dass unsere Bereitschaftsmitarbeiter mehr Zeit mit der Fehlersuche verbrachten, bevor sie das Problem beheben konnten. Daher begannen wir, nach Ereignissen zu suchen und spezifische Schwellenwerte festzulegen, um Warnmeldungen mit aussagekräftigen Informationen zu generieren (z. B. ungültige SAML-Antwort, XML konnte nicht validiert werden, Assertion aufgrund von Datums-/Zeitbeschränkungen ungültig), ohne dabei sensible Daten über den Authentifizierungsversuch preiszugeben.

Um die Arbeit unseres Teams zu optimieren, haben wir Dashboards und Suchanfragen für die Anzahl erfolgreicher und fehlgeschlagener Authentifizierungen erstellt. Anhand der Fehleranzahl können wir die Ursachen ermitteln und gegebenenfalls Maßnahmen ergreifen.

Die Kundenvorschau hat uns wertvolle Einblicke in das Authentifizierungsverhalten ermöglicht. So konnten wir die Bedeutung jedes einzelnen Ereignisses genau verstehen und unsere Benachrichtigungen optimal anpassen. Sollte etwas Unerwartetes passieren, können wir schnell reagieren und unseren Kunden die gewohnte Zuverlässigkeit bieten.

Berücksichtigung der Zeitabweichung

Insbesondere während unserer Vorschau stießen wir auf das Problem der Zeitabweichung. Wir stellten fest, dass die Authentifizierung zwischen PagerDuty und einem Identitätsanbieter aufgrund von Zeitunterschieden zwischen den Servern fehlschlagen kann. Der Server des Identitätsanbieters kann zeitlich vor unserem Server liegen, wodurch die Authentifizierung fehlschlägt, weil die Serverzeiten nicht übereinstimmen.

Glücklicherweise verfügt das Ruby SAML Toolkit von OneLogin über eine integrierte Funktion zur Authentifizierung der Identität unter Berücksichtigung von Zeitabweichungen. Nach dieser Entdeckung konnten wir in unserer Testumgebung nach einigen Durchläufen einen bestimmten Wert festlegen, um die Zeitunterschiede zwischen den Servern auszugleichen.

SSO für Ihr PagerDuty Konto einrichten

Wir haben Partnerschaften mit Okta, OneLogin und Ping Identity geschlossen, um die Aktivierung von SSO für Ihr PagerDuty Konto so einfach wie möglich zu gestalten. Sie können SSO aber auch für jeden SAML 2.0-fähigen Identitätsanbieter implementieren, einschließlich Active Directory Domain Services (über ADFS, das mit Active Directory Domain Services integriert ist und dieses als Identitätsanbieter nutzt). gemeinsam führen um Ihnen bei der Einrichtung von SSO mit Google Apps zu helfen.

Hat diese Funktion Ihrem Team geholfen? Teilen Sie uns Ihre Meinung in den Kommentaren mit.