Seit wir Single Sign-On eingeführt haben, haben wir von unseren Kunden viel positives Feedback dazu erhalten, dass sie sich jetzt ein Passwort weniger merken müssen. Obwohl SSO die Kernfunktionen von PagerDuty zur Leistungsverwaltung von Vorgängen nicht beeinträchtigt, erforderte die Planung und Implementierung der neuen Funktion viel sorgfältige Überlegung.

Einen Plan entwickeln

Nachdem wir uns entschieden hatten, Single Sign-On-Support für PagerDuty anzubieten, wussten wir, dass wir etwas brauchten, das sich gut in unsere Rails-Anwendung integrieren lässt. Wir untersuchten mögliche Lösungen, kamen aber zu dem Schluss, dass das Ruby SAML Toolkit von OneLogin die beste Lösung für uns war. Andere Unternehmen in unserem Bereich vertrauen darauf und es verfügte über alle Funktionen, die wir brauchten.

Um sicherzustellen, dass dies funktioniert, haben wir einen funktionierenden Prototyp mit einer einfachen Implementierung zusammengesucht. Ein Endpunkt, um die Authentifizierung von unserer Seite aus zu initiieren, und ein anderer, um die Antwort von Identitätsanbietern zu empfangen.

Der Proof of Concept funktionierte und ermöglichte uns, mit der Entwicklung der gewünschten Funktion zu beginnen.

Das Ruby SAML Toolkit von OneLogin

Um sicherzustellen, dass die Verwendung des Ruby SAML-Toolkits von OneLogin keine Schwachstellen in unsere Systeme bringt, begannen wir mit einer Mischung aus manuellen und automatisierten Tests. Ein Szenario, das wir getestet haben, war, wenn eine SAML-Antwort eines Identitätsanbieters erfasst und anschließend manipuliert wird (z. B. durch Änderung der E-Mail-Adresse). Was würde passieren? Das Toolkit verfügt bereits über einige Check-in-Punkte für dieses Szenario und verhindert daher die Authentifizierung.

Trotz der robusten Funktionalität des Toolkits haben wir einige Änderungen vorgenommen, um das Toolkit an unsere Anforderungen anzupassen und ihm das PagerDuty Gütesiegel zu verleihen. Beispielsweise haben wir SAML-Endpunkte so geändert, dass sie immer SSL verwenden, und sichergestellt, dass die Gültigkeitsdauer der Zertifikate eingehalten wird.

Was ist mit Mobile und SAML?

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.

Lernen aus Kundenvorschauen

Vor jeder größeren Veröffentlichung geben wir einigen unserer Kunden die Möglichkeit, unsere kommende Funktion bei einer Testfahrt vorab zu testen. Auf diese Weise können wir nicht nur Fehler finden und tiefer in die Anwendungsfälle unserer Kunden eintauchen, sondern (was wohl noch wichtiger ist) lernen, unsere neue Funktion effektiv zu überwachen.

Verfeinerung der Überwachung für umsetzbare Warnungen

Wir überwachen unsere Single Sign-On-Funktion hauptsächlich mit Sumo Logic. Durch die Einrichtung der Überwachung von Sumo Logic für unsere SAML- und OAuth-Endpunkte während unserer Kundenvorschau konnten wir lernen, was wir überwachen sollten.

Bei unserer ersten Einrichtung stellten wir fest, dass unsere Warnmeldungen nicht detailliert genug (oder umsetzbar) waren. Wir stellten fest, dass wir häufig eine Warnmeldung mit dem Hinweis „Ungültige SAML-Antwort“ erhielten, was dazu führte, dass unsere Bereitschaftsmitarbeiter mehr Zeit damit verbrachten, zu untersuchen, was schiefgelaufen war, bevor sie das Problem beheben konnten. Daher begannen wir, nach Ereignissen zu suchen und bestimmte Schwellenwerte festzulegen, um Warnmeldungen mit aussagekräftigen Informationen zu erstellen (z. B. ungültige SAML-Antwort, XML konnte nicht validiert werden, Behauptung aufgrund von Datums-/Zeitbeschränkungen ungültig), ohne vertrauliche Daten über den Authentifizierungsversuch preiszugeben.

Damit unser Team effektiver arbeiten kann, haben wir Dashboards und Suchanfragen sowohl für die Anzahl erfolgreicher als auch fehlgeschlagener Authentifizierungen erstellt. Abhängig von der Anzahl der Fehler können wir feststellen, was los ist und ob Maßnahmen erforderlich sind.

Durch unsere Kundenvorschau konnten wir viel über das Authentifizierungsverhalten lernen und so sicherstellen, dass wir wissen, was jedes Ereignis bedeutet, um unsere Warnmeldungen fein abzustimmen. Wenn etwas Unerwartetes passiert, können wir sicherstellen, dass wir schnell für unsere Kunden handeln und die Zuverlässigkeit liefern können, auf die unsere Kunden angewiesen sind.

Berücksichtigung der Taktabweichung

Insbesondere während unserer Vorschau wurden wir mit Clock Drift konfrontiert. Wir haben erfahren, dass die Authentifizierung zwischen PagerDuty und einem Identitätsanbieter aufgrund von Taktabweichungen zwischen den Servern fehlschlagen kann. Der Server eines Identitätsanbieters kann der Zeit unseres Servers voraus sein, was dazu führt, dass die Authentifizierung fehlschlägt, weil die Serverzeiten nicht übereinstimmen.

Glücklicherweise verfügt das Ruby SAML Toolkit von OneLogin über eine integrierte Funktion, die bei der Identitätsauthentifikation hilft und dabei Zeitabweichungen berücksichtigt. Nach dieser Entdeckung konnten wir nach einigen Durchläufen in unserer Testumgebung einen bestimmten Wert festlegen, um die Zeitunterschiede zwischen den Servern zu berücksichtigen.

Einrichten von SSO für Ihr PagerDuty -Konto

Wir haben eine Partnerschaft mit Okta, OneLogin und Ping Identity geschlossen, um die Aktivierung von SSO für Ihr PagerDuty -Konto wirklich einfach zu machen. 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 sich in Active Directory Domain Services integriert und als Identitätsanbieter verwendet). Wir haben auch eine gemeinsam führen um Ihnen bei der Einrichtung von SSO mit Google Apps zu helfen.

Hat dieses Feature Ihrem Team geholfen? Lassen Sie es uns in den Kommentaren wissen.