.. _Authentication: Authentification ================ .. _LocalAuthentication: Authentification des utilisateurs via comptes locaux ---------------------------------------------------- Par défaut, lorsqu'un utilisateur s'inscrit sur Astry (que ce soit suite à une invitation à rejoindre une Organisation ou à une nouvelle inscription hors invitation), un compte dit *local* est créé. Cela signifie simplement que les informations nécessaires à la connexion sont gérées par nos systèmes (néanmoins les mots de passe ne sont jamais stockés sur nos systèmes, voir :ref:`cette section`). Authentification des utilisateurs via SSO Entreprise ---------------------------------------------------- Les :ref:`Propriétaires ` d'une Organisation ont aussi la possibilité d'interfacer Astry au SSO (*Single Sign-On*) de leur entreprise (s'ils disposent d'un SSO accessible publiquement et si celui-ci supporte les protocoles standards SAML v2 ou OIDC (*OpenID Connect*)). Dans ce cas, lorsque les utilisateurs tentent de se connecter à leur compte sous Astry, ils sont redirigés vers le SSO de l'entreprise (les informations nécessaires à la connexion ne sont alors, *by design*, jamais stockées sur les systèmes Astry). Ce système permet, de façon non exhaustive : * de proposer aux utilisateurs des comptes (ou *credentials*) uniques pour un ensemble de services * de pouvoir configurer finement les règles d'administration de mots de passe (longueur, caractères, rotations, ...) * de configurer du MFA (*Multi-Factors Authentication*) directement sur le SSO de l'entreprise Protection des appels de services via clés d'API ------------------------------------------------ Les intégrations que nous proposons pour le déclenchement d'incidents reposent sur un mécanisme de **clés d'APIs**. Concrètement une clé d'API doit être créée via l'outil Astry (seuls les :ref:`Propriétaires ` d'une Organisation peuvent effectuer cette action), puis être utilisée ensuite par les intégrations pour communiquer avec Astry. Ces clés d'APIs se présentent sous la forme d'une chaîne de caractères pseudo-aléatoires, et sont propres à chaque type d'intégration. Vous pouvez disposer jusqu'à 5 clés d'APIs différentes par type d'intégration afin de vous permettre d'isoler les périmètres fonctionnels ou techniques si vous le souhaitez. .. note:: En cas de compromission d'une clé d'API, vous avez la possibilité d'effectuer des rotations de clés **sans interruption de service** (en utilisant vos jeux de 5 clés pour en générer une nouvelle, puis en décomissionnant la clé compromise ensuite).