Conception de systèmes d'authentification et d'autorisation fonctionnels

Dans cet article, nous allons parler d'un système permettant d'effectuer une authentification et une autorisation en toute sécurité. Pour commencer, comprenons quelle est la différence entre l’authentification et l’autorisation.

• L'authentification est le processus permettant de prouver que vous êtes, qui vous dites être, lorsque vous accédez à une application.
• L'autorisation est le processus de définition et d'application des politiques d'accès, c'est-à-dire ce que vous pouvez faire une fois authentifié.

Dans cet article, nous verrons :

• Pourquoi l'authentification et l'autorisation sont importantes
• Comment fonctionne l'authentification
• Comment fonctionne l'autorisation
• Conception du système d'authentification
• Conclusion

Pourquoi l'authentification et l'autorisation sont-elles importantes ?

Disons que nous sommes en réunion et que vous menez la conversation. Pour demander des mises à jour/un statut pour quelque chose à la bonne personne, vous devez identifier (c'est-à-dire authentifier ) la personne. Même pour partager certaines données sensibles avec une personne, vous devez authentifier correctement la personne. Et c’est là qu’intervient l’authentification.

Supposons maintenant qu'au cours de la même réunion, quelques décisions doivent être prises. Donc pour cela, les personnes qui ont le droit de prendre ces décisions devraient être celles qui prennent l’appel, nous ne pouvons pas permettre à tout le monde de tout faire. De toute évidence, certaines personnes ne sont pas suffisamment prises en charge pour prendre certaines décisions, et certaines essaieront certainement d’en tirer le meilleur parti. Cela apporte donc une autorisation , qui donne à certaines personnes les droits d'autorisation pour certaines activités.

Comment fonctionne l'authentification ?

Pour authentifier une personne, nous pouvons attribuer une phrase unique à chaque personne, et étant donné que la personne dit correctement la phrase ainsi que son nom. On peut dire que ok, on a identifié la personne. Il s’agit de l’approche habituelle des noms d’utilisateur et des mots de passe. Lorsque les informations d'identification appropriées sont fournies, un système considère l'identité comme valide et accorde l'accès. C'est ce qu'on appelle 1FA ou authentification à facteur unique (SFA).

SFA est considéré comme assez peu sécurisé. Pourquoi? Parce que les utilisateurs sont notoirement mauvais pour protéger leurs informations de connexion. L'authentification multifacteur (MFA) est une alternative plus sécurisée qui oblige les utilisateurs à prouver leur identité de plusieurs manières. Voici quelques-unes de ces méthodes :

• Numéros PIN à usage unique / OTP
• Applications d'authentification gérées par un tiers sécurisé (ex. Google/Microsoft Authenticator)
• Biométrie

Une fois authentifiée, la personne continuerait à effectuer librement des actions sur l'application. Et l'application est censée faire reconnaître la personne tout au long de son parcours sans l'oublier. Idéalement, ce serait trop demander à l’utilisateur de fournir le mot de passe à chaque fois qu’il passe à une page différente ou qu’il effectue une activité. Nous avons donc besoin d'un moyen de garder l'utilisateur authentifié une fois qu'il a saisi ses informations d'identification et qu'il a été authentifié une fois. C'est ce qu'on appelle la gestion de session .

2 façons de garder l'utilisateur authentifié :

• Authentification basée sur la session : lorsqu'un utilisateur se connecte à un site Web sur un navigateur, le serveur crée une session pour cet utilisateur et lui attribue un identifiant de session. Cet identifiant de session est stocké par le serveur à titre de référence et est renvoyé à l'utilisateur pour être stocké dans un cookie du navigateur. Désormais, chaque fois que l'utilisateur fera une demande, le navigateur enverra l'identifiant de session avec la demande. Ce qui aidera à authentifier la demande. Et ainsi préserver l’authentification lorsque l’utilisateur est sur le site.
• Authentification basée sur un jeton : Pour cela, le serveur crée un jeton crypté qui est envoyé à l'utilisateur et enregistré uniquement par le navigateur, sous forme de cookies HttpOnly. Toutes les informations requises telles que les informations utilisateur, les autorisations et l'expiration du jeton sont cryptées dans le jeton. Le jeton est envoyé pour les appels au serveur. Le serveur déchiffre simplement le jeton avec la clé secrète et vérifie l'utilisateur. Ce jeton est actualisé à intervalles réguliers.

Les principales différences entre ces deux approches seraient que l'authentification basée sur un jeton est Stateless , car le jeton n'a pas besoin d'être stocké côté serveur. Mais pour l'authentification basée sur la session, le jeton doit également être stocké côté serveur, ce qui le rend Stateful . Ce qui entraîne des complications lorsque le système évolue ou que le nombre d’utilisateurs augmente.

Pour l'authentification basée sur les jetons, nous utilisons principalement des JWT (JSON Web Tokens).

Comment fonctionne l'autorisation ?

Une fois l'utilisateur authentifié, nous devrons toujours nous assurer qu'il est uniquement autorisé à accéder aux ressources pour lesquelles il est autorisé à accéder. L'accès non autorisé à des données sensibles peut être un désastre. Selon le principe du moindre privilège, les entreprises mettent généralement en place des politiques d'accès telles que, par défaut, vous ayez accès à ce qui vous est absolument nécessaire. Et puis, au fur et à mesure, vous disposez d’un accès supplémentaire. Les méthodes courantes de segmentation de l'accès sont :

• Contrôle d'accès basé sur les rôles (RBAC) : les utilisateurs sont affectés à un certain groupe/rôle doté d'autorisations définies. Exemples : administrateur, membre, propriétaire.
• Contrôle d'accès basé sur des politiques (PBAC) : détermine dynamiquement les privilèges d'accès lors de l'autorisation en fonction des politiques et des règles. Les politiques sont basées sur les rôles des utilisateurs, les fonctions professionnelles et les exigences organisationnelles.
• Contrôle d'accès basé sur les attributs (ABAC) : les utilisateurs sont autorisés à accéder en fonction d'attributs tels que le titre, la certification, la formation et/ou des facteurs environnementaux tels que l'emplacement.
• Listes de contrôle d'accès (ACL) : chaque utilisateur ou entité dispose d'autorisations individuelles qui peuvent être activées ou désactivées, de la même manière que pour installer une nouvelle application sur votre téléphone et décider quelles autorisations accorder (services de localisation, contacts, etc.)

L'ACL est fréquemment utilisée à un niveau granulaire plutôt qu'ABAC ou RBAC - par exemple, pour accorder à des utilisateurs individuels l'accès à un certain fichier. L'ABAC et le RBAC sont généralement institués en tant que politiques à l'échelle de l'entreprise.

Conception du système d'authentification

Exigences

Commençons par définir les exigences fonctionnelles du système :

• Inscription : permettez aux utilisateurs de s'inscrire en fournissant les informations nécessaires.
• Connexion : authentifiez les utilisateurs en fonction de leurs informations d'identification.
• Gestion des sessions : gérez efficacement les sessions utilisateur pour garantir la sécurité.
• Récupération de mot de passe : fournissez un processus sécurisé permettant aux utilisateurs de récupérer leurs mots de passe.
• Contrôle d'accès : définissez les rôles et les autorisations pour différents types d'utilisateurs.
• Piste d'audit : conservez des journaux détaillés des événements d'authentification pour l'audit.
• Performance : Garantissez une faible latence et des temps de réponse rapides.

Quelques exigences non fonctionnelles que nous n'allons pas prendre en compte dans le cadre de cet article sont :

• Authentification multifacteur (MFA) : implémentez un système MFA robuste.
• Sécurité : donnez la priorité à la sécurité des données grâce au cryptage, au stockage sécurisé et à la communication sécurisée.
• Évolutivité : concevez le système pour gérer un nombre croissant d'utilisateurs et de transactions.
• Fiabilité : minimisez les temps d'arrêt du système et garantissez une haute disponibilité.
• Convivialité : Développez une interface utilisateur intuitive pour une expérience transparente.

Estimation de la capacité

Estimation du trafic

Commençons par l'estimation du trafic . En supposant un trafic moyen de 100 000 par mois, nous estimons un trafic d'utilisateurs de 100 000 par mois. Ce qui se traduit par 0,04 requête par seconde. Nous aurions besoin de répondre à chaque requête dans un délai de 500 ms dans 90 % des cas, c'est-à-dire que nous avons besoin d'une latence p90 de 500 ms.

 assumed_traffic_per_month = 100000 #requests assumed_traffic_per_day = assumed_traffic_per_month / 30 ~= 3350 (assuming on higher end; 3333.33 to be precise) estimated_time_per_request = 500 #ms; P90 of 500ms traffic_per_second = (assumed_traffic_per_month) / (30*24*60*60) = 0.04

Objectif de niveau de service (SLO) : 500 ms (latence maximale acceptable, sans importance pour la charge sur le système). La capacité moyenne qu'une instance peut prendre, d'après nos calculs, est d'environ 35 ms pour répondre à une requête, en supposant qu'aucun traitement lourd n'ait lieu pour l'instance. demande particulière.

Générons deux autres métriques dérivées en utilisant les métriques ci-dessus.

• Capacité : Backlog acceptable par instance : Nombre maximum de requêtes (charge) pouvant être acceptées par une instance, sans compromettre le SLO.
• Demande : Backlog par instance : nombre total de requêtes (charge) qui affluent vers une unité/instance en fonction du trafic actuel.

Ainsi,

 SLO = 500ms approx_response_time_for_one_request = 35 #ms capacity = SLO/approx_response_time_for_one_request = 500 / 35 ~= 20 load_on_one_instance = 0.04 instances_available = 1 demand = traffic_per_second / instances_available = 0.04

Avec la demande et la capacité disponible, calculons le nombre total d'instances requises.

 total_units_required = demand / capacity = 0.04 / 20 = 0.002 ~= 1

Ainsi, nous serions facilement capables de gérer 100 000 requêtes par mois, avec 0,04 requêtes par seconde, avec 1 instance. Où chaque unité peut gérer 20 requêtes par seconde sans compromettre le SLO.

Estimation du stockage

Idéalement, nous aurions besoin de stocker les détails de chaque utilisateur pour l'authentification et l'autorisation d'accès. En supposant que 5 ko/utilisateur

 monthly_new_users = 500 monthly_additional_storage = 500 * 5kb = 2500kb ~= 2GB

Ainsi, chaque mois, en supposant que nous intégrons 500 nouveaux utilisateurs, nous aurons besoin de 2 Go de stockage supplémentaire. Au cas où nous souhaiterions conserver les journaux d’authentification. Chaque demande d'authentification devrait prendre 2 Ko à stocker.

 auth_request_size = 2kb #assumption monthly_storage = monthly_visitors * auth_request_size = 100,000 * 2KB ~= 200MB

Ainsi, chaque mois, nous aurions besoin de 200 Mo supplémentaires, en supposant un trafic mensuel de 100 000.

Conception de base de données

Maintenant que nous avons fait l’estimation de la capacité. Créons les schémas de la base de données requis pour prendre en charge les exigences fonctionnelles.

Passons rapidement en revue les tableaux. Nous utilisons 6 tables.

1. Utilisateurs - Pour stocker toutes les informations utilisateur
2. Informations d'identification - Pour stocker les informations d'identification d'accès/actualisation une fois que l'utilisateur a été autorisé.
3. Mots de passe - Pour stocker les mots de passe utilisateur cryptés.
4. PasswordRequests - Pour stocker les demandes de changement de mot de passe adressées à un utilisateur particulier.
5. Sessions - Pour stocker quand l'utilisateur a eu une session active et quand a eu lieu sa dernière activité.
6. ActivityApproval - Pour stocker les demandes d'approbation pour une activité effectuée par un utilisateur particulier, qui serait vérifiée par l'administrateur.

Conception de haut niveau pour le système d'authentification

Points de terminaison du système

Satisfaction des exigences

Maintenant que tout est en place, voyons comment nous pouvons répondre à toutes les exigences.

Inscription

• Exigence - Lorsqu'un nouvel utilisateur visite notre application. Nous devons stocker les détails de l'utilisateur afin de pouvoir autoriser/identifier l'utilisateur lors de sa prochaine visite.
• Accompli - Lorsqu'un nouvel utilisateur visite l'application et saisit les détails de l'utilisateur ainsi que son e-mail et son mot de passe. Cela sera capturé dans la base de données. Les détails de l'utilisateur seront stockés dans la table Utilisateur. Et le mot de passe sera stocké dans le tableau des informations d'identification sous une forme cryptée.

Se connecter

• Exigence - Lorsqu'un utilisateur existant visite notre application. Nous devons identifier l'utilisateur afin de pouvoir autoriser/identifier ses actions et lui montrer les données qui lui appartiennent.
• Accompli - Lorsqu'un utilisateur existant visite l'application et saisit ses coordonnées, son e-mail et son mot de passe. Nous hachons le mot de passe et comparons le hachage au hachage stocké pour l'utilisateur dans la table des informations d'identification. Si cela correspond, nous avons pu identifier l'utilisateur avec succès. Sinon, ils doivent saisir le mot de passe correct qu'ils ont saisi lors de leur inscription. Ce processus est appelé Authentification .

Gestion des sessions

• Condition requise - Lorsqu'un utilisateur s'est authentifié, en saisissant son utilisateur et son mot de passe. Nous devons nous assurer qu'ils restent connectés lorsqu'ils effectuent leurs actions futures/essaient de voir des données sensibles, sans qu'ils aient à ressaisir leur mot de passe encore et encore.
• Réalisé : lorsque l'utilisateur s'authentifie avec succès. Le serveur d'authentification partagera 2 jetons avec le client. Un access_token et un rafraîchir_token . Le access_token peut contenir des données cryptées et son délai d'expiration est court pour des raisons de sécurité. Une fois que le client dispose du access_token, il renvoie le access_token avec chaque demande, ce qui aide à authentifier la demande. Lorsque le access_token expire, le client doit demander un nouveau access_token en utilisant le rafraîchissement fourni. Cela aide à maintenir une session.

Récupération de mot de passe

• Exigence - Lorsqu'un utilisateur oublie son mot de passe, il doit pouvoir réinitialiser son mot de passe en toute sécurité.
• Accompli - Lorsque l'utilisateur oublie son mot de passe, il peut soumettre son adresse e-mail sur la page mot de passe oublié, et nous générerons un code à usage unique et enverrons le lien vers son e-mail. Lorsque l'utilisateur clique sur ce lien avec le code et l'adresse email. Nous serons en mesure d'identifier en toute sécurité que la demande de récupération de mot de passe est authentique. Et demandez à l’utilisateur de définir son nouveau mot de passe. Et ainsi pouvoir récupérer le mot de passe.

Contrôle d'accès

• Exigence - Lorsqu'un utilisateur effectue une certaine action, nous devons nous assurer qu'il est authentifié pour effectuer cette action et ensuite seulement autoriser l'action à se produire.
• Accompli - Nous maintiendrons une liste d'actions, disons 1 à 12, pour plus de simplicité. Pour chaque utilisateur, nous conserverons les actions authentifiées pour cet utilisateur. Disons maintenant que l'utilisateur essaie d'effectuer une action #id 4. Nous vérifierons si l'utilisateur a les autorisations pour effectuer l'action 4. Si oui, nous continuerons et terminerons la demande. Sinon, nous montrons que la demande n’aboutit pas en raison du manque d’autorisations.

Piste d'audit

• Exigence - En cas d'incident de sécurité, nous devrions être en mesure de disposer de suffisamment de journaux pour les parcourir et d'avoir une raison plausible sur ce qui aurait pu se produire / ou des pistes sur ce qui aurait pu en être la cause possible.
• Rempli - Pour de tels scénarios, nous pouvons conserver des journaux pour chaque action d'authentification effectuée sur le serveur. (un). Pour chaque demande de connexion, nous conserverons un journal indiquant le moment où l'authentification a eu lieu, d'où, l'adresse IP et d'autres détails pertinents. (b). Pour chaque demande de récupération de mot de passe, nous conserverons un journal indiquant le moment où elle a été lancée, d'où, ips, si la demande était complète et d'autres détails pertinents. (c). De plus, nous conserverons des journaux chaque fois qu'un utilisateur est autorisé/non autorisé pour une action et par qui. Dans l’ensemble, ces journaux devraient être en mesure d’indiquer ce qui aurait pu se passer si vous essayiez de comprendre un scénario.

Performance

• Exigence : les exigences en matière de performances, telles que discutées dans la section sur l'estimation de la capacité, sont de 0,04 requêtes/seconde et de 100 000 requêtes par mois.
• Rempli - Nous avons déjà répondu à l'exigence avec suffisamment de serveurs dans la section d'estimation de la capacité.

Conclusion

Dans cet article, nous avons commencé par comprendre quelle est la différence entre l'authentification et l'autorisation. Ensuite, nous avons créé un système d'authentification et d'autorisation. C'est sûr, sécurisé, offre des performances tout en répondant aux normes de l'industrie et en répondant à toutes les exigences souhaitées. À l'avenir, je pourrais mettre à jour certaines parties de l'article pour le rendre pertinent ainsi que pour couvrir plus d'informations et d'idées sur la construction d'un tel système.