Rendez une API sûre pour deux organisations. Vous ajoutez la connexion, les rôles et les frontières entre organisations à l'API de billets de Larkfield. Chaque requête répond ainsi, sur le serveur, à trois questions : qui appelle, ce que cette personne peut faire et dans quelle organisation. Vous le prouvez avec des tests qui essaient de briser ces règles.
Lisez toutes les leçons sans compte, ou connectez-vous pour vous inscrire et suivre vos progrès.
Inscrivez-vous pour enregistrer les leçons que vous terminez. C'est gratuit.
À la fin de ce cours, vous pourrez :
Le centre d’assistance de Larkfield sert maintenant une deuxième boutique, Bramble Books, avec la même API de billets et la même base de données. Une seule clé d’API partagée suffisait quand seuls les outils de Larkfield appelaient l’API. Elle ne suffit plus. Une clé dit que l’appelant est fiable, mais pas quelle personne appelle, ce que cette personne peut faire, ni les billets de quelle boutique elle peut voir.
Dans ce cours, vous ajoutez les réponses qui manquent, un changement à la fois. Vous modélisez les utilisateurs, les organisations, les adhésions et les rôles. Vous connectez les personnes au moyen d’un fournisseur d’identité local qui émet des jetons signés, et vous faites vérifier par l’API chaque jeton qu’elle reçoit. Vous donnez au navigateur une session sûre, et vous décidez de ce qui arrive à l’expiration, à la déconnexion et au changement de compte.
Ensuite, vous contrôlez l’accès sur le serveur pour chaque route, requête SQL, lien de fichier, recherche et réponse en cache. Un identifiant de billet deviné dans l’autre boutique ne trouve alors rien. Les tâches en arrière-plan et le personnel de soutien suivent les mêmes règles. Pour finir, vous testez chaque utilisateur sur chaque route dans les deux boutiques, et vous décrivez la conception pour l’équipe qui l’exploite.
Tout s’exécute sur votre ordinateur : l’API, PostgreSQL, le stockage objet et le fournisseur d’identité. Chaque jeton, chaque erreur et chaque résultat de test des leçons vient d’une vraie exécution. Les personnes, les boutiques et les billets sont tous fictifs.
Vous avez suivi les cours Créer et déployer votre première API et Bases de données et stockage pour les applications d'IA, ou vous avez les mêmes compétences. Vous n'avez besoin ni d'un compte ni d'argent. Le fournisseur d'identité du cours est un petit fournisseur fictif qui s'exécute sur votre ordinateur. Un vrai fournisseur est facultatif, et il est décrit étape par étape.
Cours à suivre avant : Créer et déployer votre première API, Bases de données et stockage pour les applications d'IA.
Les personnes qui savent créer une petite API et stocker ses données dans PostgreSQL, comme dans les cours Créer et déployer votre première API et Bases de données et stockage pour les applications d'IA, et qui ont maintenant besoin d'utilisateurs, de rôles et de plus d'une organisation cliente dans la même application. Les développeurs et ingénieurs en IA qui doivent connecter des personnes et garder séparées les données de chaque organisation.
Des spécialistes de l'IA expérimentés ont conçu ce cours. L'IA nous a aidés à rédiger le contenu; des personnes ont choisi l'approche pédagogique et les exemples, et ont révisé chaque leçon. Les résultats que vous voyez sont les vrais résultats de l'exécution du code. Comment nous créons les cours
Posez trois questions à chaque requête. Vous séparez qui appelle, ce que cette personne peut faire et dans quelle organisation, vous modélisez les utilisateurs, les adhésions et les rôles, et vous voyez comment un identifiant deviné ou un bouton caché échoue.
Comprenez la connexion et les jetons. Vous vous connectez au moyen d'un fournisseur d'identité local, vous lisez un jeton signé et vous faites refuser par l'API un jeton expiré, destiné à une autre API ou du mauvais type.
Gardez la session du navigateur sûre. Vous comparez un témoin (cookie) de session avec des jetons gardés dans le navigateur, vous gérez l'expiration, le renouvellement, la déconnexion et le changement de compte, et vous vérifiez que le fournisseur et l'API s'entendent sur chaque paramètre, aussi avec un vrai fournisseur.
Contrôlez l'accès sur le serveur, partout. Vous vérifiez l'adhésion, le rôle et la portée sur chaque route, vous faites de l'organisation une partie obligatoire de chaque requête SQL, et vous la transmettez aux fichiers, à la recherche, aux citations et aux clés de cache.
Gardez les autorisations justes avec le temps. Vous vérifiez de nouveau, au moment où une tâche en arrière-plan s'exécute, qui l'a demandée. Vous donnez au personnel de soutien un accès limité dans le temps et journalisé, et vous mesurez combien de temps l'accès dure après le retrait d'un membre.
Prouvez-le et remettez le travail. Vous testez chaque utilisateur, chaque route et chaque organisation dans une seule matrice de tests négatifs, vous enregistrez une piste d'audit sans jetons, et vous documentez la conception pour une autre équipe.
Deux études de cas de bout en bout. Auditez les frontières entre organisations d'une application libre sur votre ordinateur, et ajoutez la connexion et les rôles à l'API de l'étude de cas du cours sur les API. Terminez-en au moins une pour obtenir le certificat. Chacune peut entrer dans votre portfolio.
Terminez au moins une étude de cas pour obtenir le certificat. Les autres sont facultatives. Ce que couvre chacune
Utilisez tous les modules dans un projet pratique. Vous recueillez des preuves, puis vous les comparez aux objectifs du cours.
Des projets réalistes du début à la fin, sur de vraies données, avec chaque résultat expliqué. Chacun devient une pièce de votre portfolio. Terminez-en au moins une pour obtenir le certificat; les autres sont facultatives.
Auditer le contrôle d'accès d'une application multilocataire libre2 h
Exécuter sur votre ordinateur une application multilocataire libre sous licence permissive, répertorier ses utilisateurs, ses organisations et ses rôles, puis tester son isolation avec la matrice d'accès du cours.
Ajouter la connexion et les rôles à une API existante4 h
Ajouter le fournisseur d'identité fictif, la validation des jetons et les rôles à l'API de données de l'étude de cas du cours sur les API, la tester avec une matrice d'accès, puis faire correspondre la conception à un vrai fournisseur d'identité.
Chargement des avis…
Vous avez suivi ce cours? Connectez-vous pour donner votre avis. Vous pouvez donner un avis après avoir terminé 25 % des leçons.
