Obligation d’achat

L’obligation d’achat prévoit que les applications doivent, conformément aux conditions-cadres définies dans la directive W008, obtenir les identités électroniques, plus précisément la prestation d’authentification qui en découle, obligatoirement auprès du service standard IAM Confédération, à savoir auprès du service eIAM de la ChF TNI et, dans les cas d’utilisation prévus à cet effet, auprès du SSO-Portal du DFJP.

Pour les applications dont la prestation d’authentification doit être obtenue via eIAM, eIAM constitue le point d’accès prévu aux fournisseurs d’identité autorisés. Cela vaut indépendamment du fait que la connexion à eIAM soit réalisée directement par l’application cible ou, de manière admissible, indirectement par l’intermédiaire d’un portail, d’un système IAM intermédiaire ou d’un autre composant de médiation.

Lorsque l’e-ID étatique suisse est utilisée dans le but d’authentifier une personne auprès d’une application cible soumise à l’obligation d’achat, cette utilisation passe par la composante du service standard AGOV. L’e-ID ne doit pas être utilisée directement, en contournant AGOV, comme moyen de connexion ou d’authentification propre à l’application. Pour l’administration fédérale centrale, AGOV est en principe obtenu via eIAM; AGOV «direct only» n’est admissible que dans le cadre d’une dérogation accordée à cet effet.

Par conséquent, les autres voies d’obtention de la prestation d’authentification prescrite, par exemple le raccordement direct de fournisseurs d’identité (IdP) à des applications, des intergiciels, des SaaS ou d’autres systèmes cibles ainsi que les procédures de connexion propres aux applications, nécessitent une dérogation de la ChF TNI, pour autant que l’obligation d’achat s’applique et que la directive W008 n’en dispose pas autrement.

Dans le cadre du service standard IAM Confédération, il est également possible d’obtenir une gestion des autorisations (Access Management). Il convient de la distinguer de l’autorisation fine interne à l’application, notamment de la gestion des autorisations portant sur les fonctions et les données au sein d’une application. Conformément à la directive W008, cette autorisation fine ne fait pas partie du service standard IAM Confédération et peut être gérée dans l’application cible, un intergiciel, un SaaS ou un autre système prévu à cet effet.

Cette réglementation poursuit les objectifs d’une economicité optimisée, d’un niveau de sécurité défini et de la promotion de la numérisation des processus administratifs grâce à l’interopérabilité des identités électroniques selon le principe once-only.

Les explications ci-après concernent les prestations IAM qui, conformément à la directive W008, font partie du périmètre de prestations du service standard IAM Confédération et sont soumises à l’obligation d’achat. Les délimitations expressément prévues par la directive W008 ainsi que les dérogations valablement accordées demeurent réservées.

L’obligation d’achat se fonde sur l’ordonnance sur la numérisation (ONum) et sur la directive W008. Pour les prestations IAM de l’administration fédérale centrale soumises à l’obligation d’achat, le service standard constitue la voie d’approvisionnement prescrite. Les dérogations limitées à une unité administrative ou à une application sont décidées par la ChF TNI conformément à la W008 et au processus P035 et sont limitées dans le temps.

Pour les applications web et les applications mobiles natives soumises à l’obligation d’achat, la prestation d’authentification doit en principe être obtenue via eIAM. Cela vaut également pour les SaaS et les autres formes d’exploitation dans le cloud, indépendamment du fait qu’une solution soit exploitée ou utilisée en interne, en externe, dans Microsoft Azure, auprès d’un autre hyperscaler ou sur un appareil mobile géré par l’administration fédérale.

Microsoft Entra ID ne constitue pas une voie d’approvisionnement alternative à eIAM pour l’authentification des utilisateurs d’une application métier, d’une application web, d’une solution SaaS ou d’une application mobile native soumise à l’obligation d’utiliser eIAM. La fédération directe d’une telle application cible avec Entra ID ou l’utilisation d’Entra ID comme service de connexion ou d’authentification n’est donc pas autorisée en l’absence d’une délimitation applicable ou d’une dérogation.

Il convient de distinguer de ce cas les services et applications Microsoft 365 mis à disposition dans le cadre du service standard Bureautique et autorisés conformément aux prescriptions applicables, notamment AR009 et E031. Leur approvisionnement IAM est régi par les prescriptions spécifiques du service standard Bureautique. Cette configuration spécifique à M365 ne constitue pas une autorisation générale d’utiliser Entra ID comme service d’authentification pour d’autres applications.

En particulier, une application métier ou une application mobile native ne devient pas une application Microsoft 365 et n’est pas exemptée de l’obligation d’utiliser eIAM du seul fait qu’elle est installée sur un appareil géré, distribuée, configurée, protégée ou administrée au moyen de Microsoft Intune, enregistrée dans un tenant Entra ID, qu’elle utilise des bibliothèques Microsoft ou qu’elle est exploitée dans Microsoft Azure. Si l’application est soumise à l’obligation d’utiliser eIAM, l’authentification de ses utilisateurs doit être effectuée via eIAM.

En l’absence d’une délimitation applicable au sens de la W008 ou d’une dérogation nécessaire accordée préalablement, sont notamment interdits:

• les procédures propres à l’application servant à établir pour la première fois ou à nouveau l’identité d’un utilisateur, par exemple au moyen de comptes nom d’utilisateur/mot de passe gérés dans l’application ou d’autres justificatifs propres à l’application, lorsqu’elles sont utilisées à la place de l’authentification prescrite via eIAM;
• le raccordement direct d’un fournisseur d’identité interne ou externe à une application cible soumise à l’obligation d’achat, à une application mobile native, à un intergiciel, à une couche de portail, à une solution SaaS ou à un autre système cible en contournant eIAM;
• la fédération directe d’une application métier, d’une application web, d’une solution SaaS ou d’une application mobile native soumise à l’obligation d’achat avec Microsoft Entra ID, ou l’utilisation d’Entra ID comme service de connexion ou d’authentification de cette application en dehors de la configuration M365 prévue dans le service standard Bureautique;
• l’utilisation de Microsoft Entra ID comme service de connexion ou d’authentification d’une application mobile native au seul motif que cette application est installée, distribuée, configurée, protégée ou administrée au moyen de Microsoft Intune;
• l’utilisation de Microsoft Entra ID comme service de connexion ou d’authentification d’une application métier au seul motif qu’elle est exploitée dans Microsoft Azure, enregistrée dans un tenant Entra ID ou qu’elle utilise d’autres services de l’écosystème cloud de Microsoft;
• l’authentification directe des utilisateurs d’une application web ou d’une application mobile native soumise à l’obligation d’achat auprès d’Active Directory, LDAP, Kerberos ou de services d’annuaire ou d’authentification comparables en contournant eIAM; conformément aux prescriptions eIAM, l’utilisation directe de Kerberos par des applications web et des applications mobiles natives nécessite une dérogation;
• le raccordement direct d’IdP sectoriels ou d’autres fournisseurs d’identité prévus pour être utilisés via eIAM à des systèmes cibles soumis à l’obligation d’achat ou à des systèmes IAM intermédiaires au lieu de passer par eIAM;
• les procédures de connexion propres à un portail ou les raccordements directs de fournisseurs d’identité sur une couche de portail soumise à l’obligation d’achat; l’abstraction admissible du raccordement eIAM par une couche de portail ne supprime pas l’obligation d’achat;
• l’utilisation d’AGOV «direct only», c’est-à-dire le raccordement direct d’AGOV à une application cible ou à un système IAM intermédiaire sans interposition d’eIAM, lorsqu’aucune dérogation préalable n’a été accordée à cet effet pour l’administration fédérale centrale; cela vaut également pour les applications mobiles natives;
• l’utilisation directe de l’e-ID étatique suisse comme moyen de connexion ou d’authentification propre à une application cible ou à une application mobile native soumise à l’obligation d’achat, en contournant AGOV ou la voie d’approvisionnement IAM prescrite pour l’application concernée;
• l’interposition en amont ou en aval d’un système IAM, d’un courtier d’identités, d’un système de fédération ou de Single Sign-on lorsque cela remplace ou contourne eIAM en tant que source prescrite de la prestation d’authentification;
• la création d’îlots de connexion distincts pour des applications métier, des applications mobiles natives, des solutions SaaS, des projets, des unités organisationnelles ou des groupes d’utilisateurs lorsque leur prestation d’authentification est soumise à l’obligation d’achat auprès du service standard IAM Confédération.

La gestion des autorisations propre à l’application (Access Management) n’est pas concernée lorsqu’il s’agit de l’autorisation et notamment de l’autorisation fine au sein de l’application. Les objets utilisateurs, rôles, autorisations, attributs métier et autres informations nécessaires à l’autorisation peuvent, conformément aux prescriptions applicables, être gérés dans l’application cible, un intergiciel, un SaaS ou un autre système prévu à cet effet. Cela ne doit toutefois pas avoir pour effet de remplacer la prestation d’authentification prescrite par une solution IAM propre ou différente.

Pour les applications mobiles natives, il convient en outre de distinguer l’authentification auprès d’eIAM de l’accès local à un état de connexion déjà établi via eIAM et enregistré de manière persistante. La persistance de la connexion est autorisée conformément aux prescriptions eIAM. Le nouvel accès à cet état de connexion persistant peut être autorisé localement au moyen de la protection de l’appareil, notamment par biométrie ou code PIN de l’appareil. Une telle réauthentification locale ne constitue ni un fournisseur d’identité alternatif ni un contournement de l’obligation d’utiliser eIAM. Lorsqu’une nouvelle authentification auprès du système IAM est nécessaire, celle-ci est à nouveau effectuée via eIAM.

Les raccordements indirects à eIAM par l’intermédiaire de portails, de systèmes IAM intermédiaires ou de composants de médiation comparables sont également autorisés, pour autant qu’ils transmettent à l’application cible la prestation d’authentification obtenue d’eIAM et ne remplacent ni ne contournent eIAM comme instance d’authentification prescrite. Il en va de même des ponts d’authentification qui raccordent à eIAM une application cible qui ne serait autrement pas compatible.

Il convient en outre de distinguer l’utilisation non autorisée d’Entra ID comme service alternatif d’authentification des utilisateurs de l’utilisation technique de l’écosystème cloud de Microsoft autorisée par les prescriptions applicables. AR015 régit notamment les comptes Entra ID, les enregistrements d’applications, les Service Principals, les tenants et d’autres composants nécessaires à l’exploitation de solutions cloud. Leur utilisation technique ne constitue pas, à elle seule, une authentification alternative des utilisateurs. Elle n’autorise toutefois pas l’utilisation d’Entra ID à la place d’eIAM comme fournisseur d’identité ou service d’authentification d’une application cible soumise à l’obligation d’utiliser eIAM. Les prescriptions d’AR015 concernant la médiation d’identités et la fédération via le service standard IAM demeurent applicables.

La fonction est donc déterminante, et non le produit, la plateforme ou le lieu d’exploitation: lorsque l’authentification des utilisateurs est soumise à l’obligation d’achat auprès du service standard IAM Confédération, elle doit être effectuée par le service du service standard prévu à cet effet. Une autre voie d’authentification n’est autorisée que si la prestation IAM concernée n’est pas soumise à l’obligation d’achat selon la W008 ou si la dérogation nécessaire a été accordée préalablement.

Les dérogations sont régies par la directive W008 et le processus P035. Les dérogations limitées à une unité administrative ou à une application sont décidées par la ChF TNI et sont limitées dans le temps.

Des dérogations pour l’approvisionnement IAM des applications web et des applications mobiles natives en dehors du service standard correspondant de l’administration fédérale sont accordées pour des exploitations pilotes avec une durée de validité courte.

Pour l’approvisionnement IAM d’applications web et d’applications mobiles natives en exploitation productive, les prescriptions eIAM publiées prévoient qu’aucune dérogation n’est en principe accordée, même si le nombre d’utilisateurs est faible ou le besoin de protection réduit, sauf en cas d’impossibilité technique absolue ou de situation urgente. Le seul fait qu’un produit dispose déjà de son propre système de connexion ou que son fabricant ne prenne en charge qu’une autre solution IAM ne constitue pas, à lui seul, un motif de dérogation.

AGOV «direct only» est prévu pour l’administration fédérale centrale comme un cas de dérogation très rare soumis à autorisation. En l’absence d’une autorisation préalable correspondante, AGOV est obtenu via eIAM «full».

Les acquisitions de logiciels, de SaaS et d’autres solutions cloud, etc., doivent être entièrement orientées vers la possibilité de raccordement à eIAM conformément à . Pour les solutions soumises à l’obligation d’achat, la possibilité de raccordement au service standard prescrit constitue un critère obligatoire.

Si des solutions TIC sont acquises, y compris des solutions cloud telles que SaaS, qui ne peuvent pas être raccordées à eIAM dans le cadre du standard eIAM, le propriétaire de l’application est tenu de faire développer et exploiter un pont d’authentification sous la forme d’un adaptateur. Cf. .

Une dérogation accordée ne vaut que pour le champ d’application qui y est désigné et pour la durée fixée. Elle ne constitue pas une autorisation générale d’utiliser le même mode d’approvisionnement IAM pour d’autres applications, unités organisationnelles ou projets ultérieurs.

L’approvisionnement IAM uniforme du paysage applicatif de l’administration fédérale constitue la base d’une numérisation réussie des processus. Dans ce contexte, l’accumulation de petites applications avec un approvisionnement IAM propriétaire doit impérativement être évitée ou consolidée.