Blog

Comment nous avons ajouté l'authentification unique à PagerDuty

par Alper Kokmen 15 mai 2014 | 4 minutes de lecture

Depuis le lancement de l'authentification unique, nous avons reçu de nombreux retours positifs de la part de nos clients, qui nous ont fait part de leur désillusion à l'idée de devoir mémoriser un mot de passe de moins. Bien que l'authentification unique n'ait pas d'impact sur les fonctionnalités de gestion des performances opérationnelles de base de PagerDuty, la planification et la mise en œuvre de la nouvelle fonctionnalité ont nécessité une réflexion approfondie.

Élaborer un plan

Après avoir décidé de proposer une prise en charge de l'authentification unique pour PagerDuty, nous savions que nous avions besoin d'un outil capable de s'intégrer parfaitement à notre application Rails. Nous avons étudié les solutions possibles, mais avons déterminé que la boîte à outils Ruby SAML de OneLogin était la meilleure solution pour nous. D'autres entreprises de notre secteur lui font confiance et elle possède 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 consommer 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 un mélange de tests manuels et automatisés. L'un des scénarios que nous avons testés était celui où une réponse SAML d'un fournisseur d'identité est capturée, puis falsifiée (par exemple, une adresse e-mail modifiée). Que se passerait-il ? La boîte à outils dispose déjà de 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 donner le label d'approbation PagerDuty . Par exemple, nous avons modifié les points de terminaison SAML pour toujours utiliser SSL et nous nous sommes assurés que les périodes de validité des certificats soient respectées.

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 sortie majeure, nous donnons à certains de nos clients la possibilité de tester notre nouvelle fonctionnalité. Cela nous permet non seulement de détecter des bugs et d'approfondir les cas d'utilisation de nos clients, mais (et sans doute plus important encore) nous permet également d'apprendre à surveiller efficacement notre nouvelle fonctionnalité.

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 Sumo Logic pour nos points de terminaison SAML et OAuth lors de notre aperçu client nous a permis d'apprendre ce que nous devons surveiller.

Lors de notre configuration initiale, nous avons constaté que nos alertes n'étaient pas suffisamment détaillées (ou exploitables). Nous avons constaté que nous recevions souvent une alerte indiquant « Réponse SAML non valide », ce qui obligeait nos équipes d'astreinte à passer plus de temps à rechercher ce qui n'allait pas avant de pouvoir résoudre le problème. Par conséquent, nous avons commencé à rechercher des événements et à définir des seuils spécifiques pour créer des alertes contenant des informations significatives (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 que notre équipe puisse travailler plus efficacement, 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 commencer à déterminer ce qui se passe et si une action est nécessaire.

Notre aperçu client nous a permis d'en apprendre beaucoup sur le comportement d'authentification afin de nous assurer que nous savions ce que signifiait chaque événement pour affiner notre système d'alerte. Si quelque chose d'inattendu se produit, nous pouvons nous assurer que nous pouvons agir rapidement pour nos clients et leur offrir la fiabilité sur laquelle ils comptent.

Comptabilisation de la dérive de l'horloge

Plus précisément, lors de notre aperçu, nous avons été confrontés à la dérive 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. Le serveur d'un fournisseur d'identité peut être en avance sur l'heure de notre serveur, ce qui entraîne l'échec de l'authentification car les heures des serveurs ne correspondent pas.

Heureusement, la boîte à outils Ruby SAML de OneLogin dispose d'une fonctionnalité intégrée qui permet d'authentifier l'identité, en tenant compte de la dérive d'horloge. Après cette découverte, nous avons pu définir une certaine valeur après quelques passages dans notre environnement de test pour tenir compte des différences de temps entre les serveurs.

Configuration de l'authentification unique pour votre compte PagerDuty

Nous avons établi un partenariat avec Okta, OneLogin et Ping Identity pour faciliter l'activation de l'authentification unique pour votre compte PagerDuty . Mais vous pouvez également implémenter l'authentification unique 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, en l'utilisant 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 ? Faites-le nous savoir dans les commentaires.