Implémentation de l’authentification et de l’autorisation dans Azure Container Apps
Azure Container Apps fournit des fonctionnalités d’authentification et d’autorisation intégrées, pour sécuriser votre application conteneur avec entrée externe sans code ou très peu. La fonctionnalité d’authentification intégrée pour Container Apps peut vous faire gagner du temps et de l’énergie en fournissant une authentification prête à l’emploi avec des fournisseurs d’identité fédérée, ce qui vous permet de vous concentrer sur le reste de votre application.
- Azure Container Apps fournit l’accès à différents fournisseurs d’authentification intégrés.
- Les fonctionnalités d’authentification intégrées ne nécessitent pas de langage, de SDK, d’expertise en sécurité ou même de code que vous devez écrire.
Cette fonctionnalité doit être utilisée uniquement avec HTTPS. Vérifiez que allowInsecure est désactivé dans la configuration d’entrée de votre application conteneur. Vous pouvez configurer votre application conteneur pour l’authentification avec ou sans restriction de l’accès au contenu et aux API de votre site.
- Pour restreindre l’accès aux applications uniquement aux utilisateurs authentifiés, définissez son paramètre Restreindre l’accès sur Exiger l’authentification.
- Pour authentifier mais ne pas restreindre l’accès, définissez son paramètre Restreindre l’accès sur Autoriser l’accès non authentifié.
Fournisseurs d’identité
Container Apps utilise l’identité fédérée, dans laquelle un fournisseur d’identité tiers gère automatiquement l’identité des utilisateurs et le flux d’authentification. Les fournisseurs d’identité suivants sont disponibles par défaut :
| Fournisseur | Point de terminaison de connexion | Guides pratiques |
|---|---|---|
| Plateforme d’identités Microsoft | /.auth/login/aad |
Plateforme d’identités Microsoft |
/.auth/login/facebook |
||
| GitHub | /.auth/login/github |
GitHub |
/.auth/login/google |
||
| X | /.auth/login/twitter |
X |
| Tout fournisseur OpenID Connect | /.auth/login/<providerName> |
OpenID Connect |
Lorsque vous utilisez un de ces fournisseurs, le point de terminaison de connexion est accessible à des fins d’authentification de l’utilisateur et de validation des jetons d’authentification provenant du fournisseur. Vous pouvez proposer à vos utilisateurs toutes les options de fournisseur que vous souhaitez parmi celles-ci.
Architecture des fonctionnalités
Le composant intergiciel (middleware) d’authentification et d’autorisation est une fonctionnalité de la plateforme qui s’exécute comme un conteneur side-car sur chaque replica dans votre application. Lorsqu’elle est activée, chaque requête HTTP entrante traverse la couche de sécurité avant d’être gérée par votre application.
L’intergiciel (middleware) de la plateforme gère plusieurs éléments pour votre application :
- Authentifie les utilisateurs et les clients avec les fournisseurs d’identité spécifiés
- gestion de la session authentifiée ;
- Injecte des informations d’identité dans les en-têtes de demande HTTP
Le module d’authentification et d’autorisation s’exécute dans un conteneur distinct, isolé du code de votre application. Comme le conteneur de sécurité ne s’exécute pas en cours d’exécution, aucune intégration directe avec des frameworks de langage spécifiques n’est possible. Toutefois, les informations pertinentes dont votre application a besoin sont fournies dans les en-têtes de demande.
Flux d’authentification
Le flux d’authentification est identique pour tous les fournisseurs, mais il diffère selon que vous souhaitez ou non vous connecter avec le Kit de développement logiciel (SDK) du fournisseur :
Sans kit SDK fournisseur (flux orienté serveur ou flux de serveur) : l’application délègue la connexion fédérée à Container Apps. La délégation est généralement le cas avec les applications de navigateur, qui présentent la page de connexion du fournisseur à l’utilisateur.
Avec kit SDK fournisseur (flux orienté client ou flux client) : l’application connecte les utilisateurs au fournisseur manuellement et soumet ensuite le jeton d’authentification à App Service pour validation. Cette approche est classique pour les applications sans navigateur qui ne présentent pas la page de connexion du fournisseur à l’utilisateur. Par exemple, une application mobile native qui connecte les utilisateurs à l’aide du kit SDK du fournisseur.