Authentification et autorisation dans Azure Container Apps

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.

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• X
• Personnaliser OpenID Connect

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

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 :

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.

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.

Personnaliser la connexion et la déconnexion

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.

Utiliser plusieurs fournisseurs de connexion

La configuration du portail n’offre pas de solution clés en main pour présenter plusieurs fournisseurs de connexion à vos utilisateurs (tels que Facebook et X). 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/x">Log in with X</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>

Connexion dirigée vers le client

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 :

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.

Étapes suivantes

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

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• X
• Personnaliser OpenID Connect