Depuis le lancement de l'authentification unique (SSO), nous avons reçu de nombreux retours positifs de nos clients, qui ont constaté qu'ils devaient mémoriser un mot de passe de moins. Bien que l'authentification unique n'ait pas d'impact sur les fonctionnalités clés de gestion des performances opérationnelles de PagerDuty, sa planification et son déploiement ont nécessité une réflexion approfondie.

Élaborer un plan

Après avoir décidé d'offrir la prise en charge de l'authentification unique pour PagerDuty, nous savions qu'il nous fallait une solution s'intégrant parfaitement à notre application Rails. Nous avons étudié les solutions possibles, mais avons conclu que la boîte à outils Ruby SAML de OneLogin était la solution la plus adaptée. D'autres entreprises de notre secteur lui font confiance et elle offre toutes les fonctionnalités dont nous pensions avoir besoin.

Pour garantir le bon fonctionnement de cette solution, nous avons créé un prototype fonctionnel avec une implémentation simple : un point de terminaison pour initier l'authentification de notre côté et un autre pour traiter la réponse des fournisseurs d'identité.

La preuve de concept a fonctionné, nous permettant de commencer à créer la fonctionnalité que nous voulions.

Boîte à outils Ruby SAML de OneLogin

Pour nous assurer que l'utilisation de la boîte à outils Ruby SAML de OneLogin n'introduisait pas de vulnérabilités dans nos systèmes, nous avons commencé par une combinaison de tests manuels et automatisés. Nous avons notamment testé le scénario suivant : si une réponse SAML d'un fournisseur d'identité était capturée puis falsifiée (par exemple, en cas de modification d'adresse e-mail), que se passerait-il ? La boîte à outils intègre déjà quelques points de contrôle pour ce scénario et interdit donc l'authentification.

Malgré les fonctionnalités robustes de la boîte à outils, nous avons apporté quelques modifications pour l'adapter à nos besoins et lui conférer l'approbation de PagerDuty . Par exemple, nous avons modifié les points de terminaison SAML pour qu'ils utilisent systématiquement SSL et nous nous sommes assurés du respect des périodes de validité des certificats.

Qu'en est-il du mobile et de SAML ?

Afin de prendre en charge SSO pour nos applications mobiles, nous avons utilisé SAML en combinaison avec OAuth où nos applications iOS et Android obtiennent un jeton d'authentification après une authentification SAML réussie.

Apprendre des aperçus des clients

Avant chaque version majeure, nous offrons à quelques-uns de nos clients la possibilité de tester notre nouvelle fonctionnalité. Cela nous permet non seulement d'identifier les bugs et d'approfondir nos cas d'utilisation, mais aussi (et surtout) d'apprendre à la surveiller efficacement.

Affiner la surveillance pour des alertes exploitables

Nous surveillons notre fonctionnalité d'authentification unique principalement à l'aide de Sumo Logic. La configuration de la surveillance de nos points de terminaison SAML et OAuth par Sumo Logic lors de notre aperçu client nous a permis de déterminer les éléments à surveiller.

Lors de notre configuration initiale, nous avons constaté que nos alertes n'étaient pas suffisamment détaillées (ni exploitables). Nous recevions souvent une alerte indiquant « Réponse SAML non valide », ce qui obligeait nos équipes d'astreinte à consacrer plus de temps à l'analyse de la cause du problème avant de pouvoir le résoudre. Nous avons donc commencé à rechercher des événements et à définir des seuils spécifiques pour générer des alertes contenant des informations pertinentes (par exemple, réponse SAML non valide, XML non validé, assertion non valide en raison de restrictions de date/heure), sans révéler de données sensibles sur la tentative d'authentification.

Pour optimiser l'efficacité de notre équipe, nous avons créé des tableaux de bord et des requêtes de recherche pour le nombre d'authentifications réussies et d'échecs. En fonction du nombre d'erreurs, nous pouvons déterminer la cause du problème et si une action est nécessaire.

Notre aperçu client nous a permis d'en apprendre davantage sur le comportement d'authentification et de comprendre la signification de chaque événement afin d'affiner nos alertes. En cas d'imprévu, nous pouvons réagir rapidement et garantir la fiabilité à laquelle nos clients sont confrontés.

Comptabilisation de la dérive de l'horloge

Lors de notre aperçu, nous avons été confrontés à un problème de décalage d'horloge. Nous avons appris que l'authentification entre PagerDuty et un fournisseur d'identité peut échouer en raison d'un décalage d'horloge entre les serveurs. Un serveur de fournisseur d'identité peut être en avance sur notre serveur, ce qui entraîne l'échec de l'authentification en raison d'une incohérence des heures des serveurs.

Heureusement, la boîte à outils Ruby SAML de OneLogin intègre une fonctionnalité permettant d'authentifier l'identité en tenant compte des décalages d'horloge. Suite à cette découverte, nous avons pu définir une valeur spécifique après plusieurs passages dans notre environnement de test afin de tenir compte des décalages horaires entre les serveurs.

Configuration de l'authentification unique (SSO) pour votre compte PagerDuty

Nous avons collaboré avec Okta, OneLogin et Ping Identity pour faciliter l'activation de l'authentification unique (SSO) pour votre compte PagerDuty . Vous pouvez également implémenter l'authentification unique (SSO) pour tout fournisseur d'identité compatible SAML 2.0, y compris les services de domaine Active Directory (via ADFS, qui s'intègre aux services de domaine Active Directory et les utilise comme fournisseur d'identité). Nous avons également mis en place un guider ensemble pour vous aider à configurer SSO avec Google Apps.

Cette fonctionnalité a-t-elle été bénéfique pour votre équipe ? Dites-le-nous dans les commentaires.