Authentification et autorisation dans Azure Container Apps

Article
03/24/2023

Azure Container Apps fournit des fonctionnalités d’authentification et d’autorisation intégrées (parfois appelées « authentification simple »), pour sécuriser votre application conteneur avec entrée externe sans code ou très peu.

Pour plus d’informations sur l’authentification et l’autorisation, reportez-vous aux guides suivants pour votre choix de fournisseur.

Pourquoi utiliser l’authentification intégrée ?

Il n’est pas obligatoire d’utiliser cette fonctionnalité pour l’authentification et l’autorisation. Vous pouvez utiliser les fonctionnalités de sécurité groupées dans l’infrastructure web de votre choix, ou vous pouvez écrire vos propres utilitaires. Cependant, l’implémentation d’une solution sécurisée pour l’authentification (connexion des utilisateurs) et l’autorisation (accord de l’accès aux données sécurisées) peut nécessiter des efforts considérables. Vous devez veiller à suivre les meilleures pratiques et les normes du secteur, et à tenir à jour votre implémentation.

La fonctionnalité d’authentification intégrée pour Container Apps vous fait gagner du temps et de l’énergie en fournissant une authentification prête à l’emploi avec des fournisseurs d’identité fédérée. Ces fonctionnalités vous permettent de consacrer plus de temps au développement de votre application et moins de temps à la création de systèmes de sécurité.

Les avantages incluent :

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.
Vous pouvez intégrer plusieurs fournisseurs, notamment Microsoft Entra ID, Facebook, Google et Twitter.

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é Microsoft	`/.auth/login/aad`	Plateforme d’identité Microsoft
Facebook	`/.auth/login/facebook`	Facebook
GitHub	`/.auth/login/github`	GitHub
Google	`/.auth/login/google`	Google
Twitter	`/.auth/login/twitter`	Twitter
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.

Considérations relatives à l’utilisation de l’authentification intégrée

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é.

Par défaut, chaque application conteneur émet son propre cookie ou jeton unique pour l’authentification. Vous pouvez également fournir vos propres clés de signature et de chiffrement.

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. Quand elle est activée, votre application gère chaque requête HTTP entrante une fois qu’elle passe par la couche de sécurité.

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, comme expliqué dans cet article.

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.

Les appels entre une application de navigateur approuvée dans Container Apps et une autre API REST dans Container Apps peuvent être authentifiés à l’aide du flux dirigé vers le serveur. Pour plus d’informations, consultez Personnaliser la connexion et la déconnexion.

Le tableau montre les étapes du flux d’authentification.

Étape	Sans le Kit SDK du fournisseur	Avec le Kit SDK du fournisseur
1. Connexion de l’utilisateur	Redirige le client vers `/.auth/login/<PROVIDER>`.	Le code client connecte directement l’utilisateur avec le Kit SDK du fournisseur et reçoit un jeton d’authentification. Pour plus d’informations, consultez la documentation du fournisseur.
2. Post-authentification	Le fournisseur redirige le client vers `/.auth/login/<PROVIDER>/callback`.	Le code client publie un jeton du fournisseur vers `/.auth/login/<PROVIDER>` pour validation.
3. Établissement de la session authentifiée	Container Apps ajoute un cookie authentifié à la réponse.	Container Apps retourne son propre jeton d’authentification au code client.
4. Traitement du contenu authentifié	Le client inclut le cookie d’authentification dans les demandes suivantes (gérées automatiquement par le navigateur).	Le code client présente le jeton d'authentification dans l'en-tête `X-ZUMO-AUTH`.

Dans le cas des navigateurs clients, Container Apps peut diriger automatiquement tous les utilisateurs non authentifiés vers /.auth/login/<PROVIDER>. Vous pouvez également présenter aux utilisateurs un ou plusieurs liens /.auth/login/<PROVIDER> pour leur permettre de se connecter à votre application à l’aide du fournisseur de leur choix.

Comportement d’autorisation

Dans le Portail Azure, vous pouvez modifier les paramètres d’authentification de votre application conteneur pour la configurer avec différents comportements lorsqu’une demande entrante n’est pas authentifiée. Les titres suivants décrivent les options possibles.

Autoriser les accès non authentifiés : cette option diffère l’autorisation du trafic non authentifié dans le code de votre application. Dans le cas des demandes authentifiées, Container Apps transmet également les informations d’authentification dans les en-têtes HTTP. Votre application peut utiliser des informations dans les en-têtes pour prendre des décisions d’autorisation pour une demande.

Cette option assure un traitement plus souple des requêtes anonymes. Par exemple, il permet de présenter plusieurs fournisseurs de connexion aux utilisateurs. Vous devez cependant écrire du code.
Exiger l’authentification : cette option rejette tout trafic non authentifié vers votre application. Ce rejet peut être une action de redirection vers l’un des fournisseurs d’identité configurés. Dans ce cas, un client de navigateur est redirigé vers /.auth/login/<PROVIDER> pour le fournisseur de votre choix. Si la demande anonyme provient d’une application mobile native, la réponse retournée est HTTP 401 Unauthorized. Vous pouvez également faire en sorte que le rejet soit un message HTTP 401 Unauthorized ou HTTP 403 Forbidden pour toutes les requêtes.

Cette option évite d’avoir à écrire du code d’authentification dans l’application. Une autorisation plus fine, par exemple propre au rôle, peut être gérée en examinant les revendications de l’utilisateur (consultez la section Accéder aux revendications utilisateur).

Attention

Cette manière de restreindre l’accès s’applique à tous les appels à votre application qui peuvent ne pas être souhaitables pour les applications souhaitant une page d’accès publique disponible, comme dans de nombreuses applications à page unique.

Remarque

Par défaut, tout utilisateur de votre locataire Microsoft Entra peut demander un jeton pour votre application à partir de Microsoft Entra ID. Vous pouvez configurer l’application dans Microsoft Entra ID si vous souhaitez restreindre l’accès à votre application à un ensemble défini d’utilisateurs.

L’authentification Container Apps fournit des points de terminaison intégrés pour la connexion et la déconnexion. Lorsque la fonctionnalité est activée, ces points de terminaison sont disponibles sous le préfixe de routage /.auth sur votre application conteneur.

La configuration du portail n’offre pas de solution clé en main pour présenter à vos utilisateurs plusieurs fournisseurs de connexion (telles que Facebook et Twitter). Toutefois, il est relativement simple d’ajouter cette fonctionnalité à votre application. Voici la procédure à suivre :

Tout d’abord, sur la page Authentification / Autorisation du portail Azure, configurez chaque fournisseur d’identité que vous souhaitez activer.

Sous Mesure à prendre quand une demande n’est pas authentifiée, sélectionnez Autoriser les requêtes anonymes (aucune action) .

Dans la page de connexion, la barre de navigation ou tout autre emplacement de votre application, ajoutez un lien de connexion pour chacun des fournisseurs que vous avez activés (/.auth/login/<provider>). Par exemple :

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/twitter">Log in with Twitter</a>

Lorsque l’utilisateur sélectionne sur l’un des liens, l’interface utilisateur des fournisseurs respectifs s’affiche à l’utilisateur.

Pour rediriger l’utilisateur post-connexion vers une URL personnalisée, utilisez le paramètre de chaîne de requête post_login_redirect_uri (à ne pas confondre avec l’URI de redirection de votre configuration de fournisseur d’identité). Par exemple, pour diriger l’utilisateur vers /Home/Index après sa connexion, utilisez le code HTML suivant :

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Dans une connexion dirigée vers le client, l’application connecte l’utilisateur au fournisseur d’identité à l’aide d’un kit de développement logiciel (SDK) spécifique au fournisseur. Le code d’application envoie ensuite le jeton d’authentification obtenu à Container Apps pour validation (voir Flux d’authentification) à l’aide d’une requête HTTP POST.

Pour valider le jeton du fournisseur, l'application conteneur doit d'abord être configurée avec le fournisseur souhaité. Au moment de l'exécution, après avoir récupéré le jeton d'authentification auprès de votre fournisseur, envoyez-le à /.auth/login/<provider> pour validation. Par exemple :

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Le format du jeton varie légèrement selon le fournisseur. Pour plus de détails, consultez le tableau suivant :

Valeur du fournisseur	Requis dans le corps de la demande	Commentaires
`aad`	`{"access_token":"<ACCESS_TOKEN>"}`	Les propriétés `id_token`, `refresh_token` et `expires_in` sont facultatives.
`microsoftaccount`	`{"access_token":"<ACCESS_TOKEN>"}` ou `{"authentication_token": "<TOKEN>"`	`authentication_token` est préférable à `access_token`. La propriété `expires_in` est facultative. Lors de la demande de jeton à partir des services Live, demandez toujours l'étendue `wl.basic`.
`google`	`{"id_token":"<ID_TOKEN>"}`	La propriété `authorization_code` est facultative. Le fait de fournir une valeur `authorization_code` ajoute un jeton d’accès et un jeton d’actualisation au magasin de jetons. Lorsqu’elle est spécifiée, `authorization_code` peut également et éventuellement être accompagnée d’une propriété `redirect_uri`.
`facebook`	`{"access_token":"<USER_ACCESS_TOKEN>"}`	Utilisez un jeton d'accès utilisateur valide à partir de Facebook.
`twitter`	`{"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}`

Si le jeton du fournisseur est validé, l'API renvoie un authenticationToken dans le corps de la réponse. Il s'agit de votre jeton de session.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Une fois en possession de ce jeton de session, vous pouvez accéder aux ressources d'application protégées en ajoutant l'en-tête X-ZUMO-AUTH à vos requêtes HTTP. Par exemple :

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Déconnexion d’une session

Les utilisateurs peuvent se déconnecter en envoyant une requête GET au point de terminaison /.auth/logout de l’application. La demande GET effectue les actions suivantes :

Efface les cookies d’authentification de la session active.
Supprime du magasin de jetons les jetons de l’utilisateur actuel.
Permet d’effectuer une déconnexion côté serveur sur le fournisseur d’identité pour Microsoft Entra ID et Google.

Voici un lien de déconnexion simple sur une page web :

<a href="/.auth/logout">Sign out</a>

Par défaut, une déconnexion réussie redirige le client vers l’URL /.auth/logout/done. Vous pouvez modifier la page de redirection après déconnexion en ajoutant le paramètre de requête post_logout_redirect_uri. Par exemple :

GET /.auth/logout?post_logout_redirect_uri=/index.html

Veillez à coder la valeur de post_logout_redirect_uri.

L’URL doit être hébergée dans le même domaine lorsque vous utilisez des URL complètes.

Accéder aux revendications de l’utilisateur dans le code de l’application

Pour toutes les infrastructures linguistiques, Container Apps rend les revendications dans le jeton entrant disponible pour votre code d’application. Les revendications sont injectées dans les en-têtes de requête, qui sont présents à partir d’un utilisateur final authentifié ou d’une application cliente. Les demandes externes ne sont pas autorisées à définir ces en-têtes. Ces derniers ne s’affichent donc que s’ils sont définis par Container Apps. Voici quelques exemples d’en-têtes :

X-MS-CLIENT-PRINCIPAL-NAME
X-MS-CLIENT-PRINCIPAL-ID

Tout code, quels que soient le langage ou l’infrastructure utilisés, peut trouver les informations qu’il recherche dans ces en-têtes.

Remarque

Différentes infrastructures de langage peuvent présenter ces en-têtes au code d’application dans différents formats, tels que des minuscules ou des majuscules.

Étapes suivantes

Pour plus d’informations sur la sécurisation de votre application conteneur, consultez les articles suivants.

Partager via

Authentification et autorisation dans Azure Container Apps

Pourquoi utiliser l’authentification intégrée ?

Fournisseurs d’identité

Considérations relatives à l’utilisation de l’authentification intégrée

Architecture des fonctionnalités

Flux d’authentification

Comportement d’autorisation

Déconnexion d’une session

Accéder aux revendications de l’utilisateur dans le code de l’application

Étapes suivantes

Commentaires

Commentaires

Ressources supplémentaires

Partager via

Authentification et autorisation dans Azure Container Apps

Pourquoi utiliser l’authentification intégrée ?

Fournisseurs d’identité

Considérations relatives à l’utilisation de l’authentification intégrée

Architecture des fonctionnalités

Flux d’authentification

Comportement d’autorisation

Personnaliser la connexion et la déconnexion

Utiliser plusieurs fournisseurs de connexion

Connexion dirigée vers le client

Déconnexion d’une session

Accéder aux revendications de l’utilisateur dans le code de l’application

Étapes suivantes

Commentaires

Commentaires

Ressources supplémentaires