Main Page Navigation Content Contact Sitemap Search

Connexion d’applications à eIAM

Fiche technique relative aux acquisitions
V1.7 2024-10-09 ▪ Egalement obligatoire pour les développements internes et autres formes d'introduction de nouveaux logiciels

La présente fiche technique doit faire partie intégrante des exigences à remplir lors des acquisitions des solutions informatiques qui sont concernées par la connexion à eIAM; elle peut être référencée par l’URL .

Elle ne s’applique pas à l’utilisation d’AGOV par les cantons et leurs communes. Les applications de la Confédération ne sont pas directement connectées à AGOV, mais à eIAM conformément à la présente fiche technique; AGOV est automatiquement mis à disposition dans l’écosystème eIAM.


Pour la plupart des applications, y compris les applications mobiles natives , une obligation d'obtention d'eIAM s'applique selon . Évaluez l'obligation d'obtention pour votre cas dans la Liste de contrôle Ⅴ’’’

tout déplier ▼

Ⅰ INTRODUCTION

La présente fiche technique traite de la connexion d’applications à eIAM.

INTRODUCTION
×

Contexte

Les applications web et les applications mobiles natives de l’administration fédérale, quels que soient leur lieu d’exploitation, leur mode d’exploitation et leur besoin de protection, ci-après appelées «applications», doivent obtenir les services d’authentification auprès du service standard correspondant de l’administration fédérale (voir ). Le portail SSO du DFJP doit être utilisé pour les applications du contexte de la justice et des personnes affiliées, et le service eIAM dans les autres cas (possibilité de connexion directe ou indirecte à eIAM; autres possibilités de connexion indirecte: via l’ePortal ou le système IAM du DEFR).

Obtention obligatoire et importance pour les acquisitions

Compte tenu de l’obtention obligatoire des services d’authentification et, donc, de l’exclusion d’autres approvisionnements IAM (propriétaires), par exemple intégrés aux applications ou à leurs environnements d’exploitation (SaaS et autres modes d’exploitation en nuage), la possibilité de connexion (simple autant que possible) au service standard est un CRITÈRE OBLIGATOIRE pour les acquisitions. Lors de marchés publics, la présente fiche technique est destinée à constituer une annexe servant de source à la définition des CRITÈRES OBLIGATOIRES, ainsi que des CRITÈRES OPTIONNELS (aspects de la possibilité de connexion simple).

Accent principal de l’obtention obligatoire et délimitation

L’obtention obligatoire concerne les identités numériques et leurs identifiants (Credential) et les services d’authentification qui en découlent. Par la suite, les applications ou leurs environnements d’exploitation (par ex. SaaS et autres modes d’exploitation en nuage) peuvent assurer leur propre gestion des utilisateurs avec des données d’autorisation (droits tels que rôles et attributs) du moment que les services d’authentification sont exclusivement obtenus auprès d’eIAM.

Ⅱ CRITÈRES

Il convient de distinguer entre la possibilité de connexion de principe et la simplicité de sa configuration.

Ⅱ’ CRITÈRES OBLIGATOIRES
×

CRITÈRE OBLIGATOIRE 1: Possibilité de connexion de principe

La possibilité de connexion de principe est assurée lorsque les applications peuvent fédérer avec eIAM par le biais de l’un des protocoles suivants:
  1. OIDC avec Authorization Code Flow & PKCE (Proof Key of Code Exchange)
  2. SAML2.0 avec browser POST binding
  3. SAML2.0 avec browser Redirect binding
  4. WS-Federation

CRITÈRE OBLIGATOIRE 2: Priorité donnée au fournisseur de service y compris données et transport

Comme le montre la vidéo sur à partir de la minute 7, eIAM applique le principe de la priorité donnée au fournisseur de service («Service Provider First»), ce qui signifie qu’une fois que l’utilisateur final a accédé à l’application cible, celle-ci reconnaît l’utilisateur comme n’étant pas encore authentifié et fait alors en sorte que le navigateur assure le réacheminement de forme et de fond vers eIAM conformément au protocole OIDC, SAML2.0 ou WS-Federation.

Ce critère comprend les points suivants concernant les données et le transport:

  • L’application DOIT* être en mesure de lancer une déconnexion unique au moyen du protocole de la fédération.
  • L’application DOIT être en mesure de signer la demande d’authentification (point facultatif; uniquement s’il n’y a pas d’Assertion Consumer Service URL fixe).
  • L’application DOIT* accepter les Bearer Token.
  • Les messages de la fédération sont reçus et transmis par eIAM uniquement sur des connexions sécurisées par le protocole TLS (Transport Layer Security).
*Si le critère ne peut pas être satisfait, la connexion à eIAM reste malgré tout possible.

Ⅱ’’ CRITÈRES OPTIONNELS (Aspects de la possibilité de connexion simple)
×

Comme le point de contact avec eIAM ne doit pas obligatoirement se trouver directement sur l’application, mais peut également être une façade de l’exploitant, on parlera ci-après de point de contact entre eIAM et la cible plutôt qu’entre eIAM et l’application.

CRITÈRE OPTIONNEL 1: Utilisation du jeton d’OIDC, de SAML2.0 ou de WS-Federation conformément à la norme eIAM

eIAM inscrit dans les jetons certaines données dans certains champs. La connexion à eIAM est simplifiée lorsque la cible peut s’en accommoder (voir la documentation à l’adresse ).

Si le CRITÈRE OPTIONNEL 1 n’est pas satisfait et que la cible a besoin d’autres champs, eIAM offre un certain degré de flexibilité (transcription / cartographie) susceptible d’entraîner des coûts. Les demandes de modifications des jetons eIAM (OIDC, SAML2.0, WS-Federation) spécifiques à l’application cible doivent se faire via le processus P035 ().

CRITÈRE OPTIONNEL 2: OIDC, SAML2.0 ou WS-Federation en tant que seul point de contact (pas d’interfaces)

La connexion est simplifiée lorsque l’un des protocoles susmentionnés est le seul point de contact entre eIAM et la cible, en d’autres termes lorsqu’il n’est pas nécessaire qu’existe une interface entre eIAM et la cible afin a) que les données d’utilisateur venant d’eIAM soient lues; b) que ces données soient écrites selon eIAM; ou c) qu’eIAM soit tenu d’envoyer à la cible (approvisionner) les jetons qui en résultent sur un autre canal que celui découlant du protocole OIDC, SAML2.0 ou WS-Federation.
Pour la cible, cela signifie que les jetons d’OIDC, de SAML ou de WS-Federation qui en résultent sont la seule source externe contenant des informations de l’utilisateur et que s’il faut que la cible conserve les données d’utilisateur, cela doit se faire à flux tendus à partir des jetons.

On se reportera au chapitre suivant si le CRITÈRE OPTIONNEL 2 n’est pas satisfait et que la cible a besoin d’interfaces au sens de a), b) et/ou c).


Ⅱ’’’ NON-RESPECT DES CRITÈRES (Résolution de l'incompatibilité eIAM résultante)
×

Si des solutions TIC sont acquises, y compris des solutions cloud telles que SaaS, qui ne peuvent pas être connectées à eIAM selon les normes 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. Voir .

Ⅲ INTERFACES

Les interfaces d’eIAM ne seront pas adaptées à la cible, c’est la cible qui devra être adaptée aux interfaces.

INTERFACES
×

S’il est nécessaire de recourir aux interfaces mentionnées ci-après, il convient de solliciter dès que possible un entretien avec le secteur TNI de la ChF et l’OFIT.

Si des interfaces telles que décrites plus haut et ci-après sont nécessaires, la connexion à eIAM reste possible, mais à condition de suivre les règles d’eIAM en matière d’interfaces. Les interfaces d’eIAM ne seront pas adaptées à la cible, c’est la cible qui devra être adaptée aux interfaces.

Si cela entraîne une incompatibilité entre la cible et eIAM et que la cible ne peut pas être adaptée (ce qui est parfois le cas pour les prestataires SaaS), la connexion à eIAM est compromise. De telles applications ne devraient pas être acquises. Si une pareille acquisition s’avère malgré tout nécessaire, le client doit faire développer et exploiter à ses frais à l’OFIT ou ailleurs un adaptateur au sens d’une application métier servant d’intermédiaire (voir ). Une telle incompatibilité n’entraîne pas automatiquement une autorisation d’exception pour l’exploitation sans eIAM.

On relèvera que les indications d’un fabricant telles que «compatible avec SAML2.0», «compatible avec OIDC» ou «compatible avec WS-Federation» ne suffisent pas à elles seules. En voici un exemple: la SaaS X. est compatible avec SAML2.0, mais nécessite un approvisionnement des utilisateurs sur leur API propriétaire; il est exclu qu’eIAM en tant que service standard fournisse cet approvisionnement propriétaire (règle de réutilisation). Par la suite, un adaptateur au sens d’une application métier servant d’intermédiaire a été développé pour la SaaS X. (voir ).

Interface eIAM-RDM

La gestion déléguée à distance (remote delegated management, RDM) d’eIAM permet d’inviter des utilisateurs dans eIAM à l’aide d’une API REST (representational state transfer). Le principe de la gestion déléguée veut que ce n’est pas le responsable des autorisations d’un office qui attribue les autorisations de ce type, mais quelqu’un d’autre (voir prestation 6 et vidéo eIAM à la minute 11). En cas d’utilisation de la gestion déléguée à distance, ce n’est pas un être humain, mais une machine qui déclenche l’invitation à eIAM. Dans les deux cas, eIAM envoie à la personne invitée un courriel contenant un texte d’invitation et un code d’onboarding. La personne invitée utilise le code d’onboarding une seule fois en employant une identité numérique adéquate de son choix. Cette identité numérique est alors reliée par eIAM à l’application cible.
Considération d’utilisation: pour savoir si la gestion déléguée d’eIAM doit être utilisée en général et, le cas échéant, en particulier celle à distance, il convient de s’appuyer sur la modélisation des processus d’onboarding, c’est-à-dire sur la manière dont les utilisateurs parviennent pour la première fois dans l’application cible (voir la section PROCÉDURE D’ONBOARDING ci-après).

Interface eIAM-AMW

eIAM-AMW fournit une API SOAP (Simple Object Access Protocol) qui permet la lecture et la modification des données d’utilisateur et des structures organisationnelles dans eIAM. En d’autres termes, eIAM-AMW est l’interface avec le mandant d’accès eIAM.
Considération d’utilisation: l’utilisation de cette interface est l’antithèse du CRITÈRE OPTIONNEL 2 mentionné plus haut, et il est recommandé de réfléchir à la manière dont le CRITÈRE OPTIONNEL 2 pourrait être satisfait dans le respect de la règle de simplicité.

Interface eIAM-LDS

eIAM-LDS permet la lecture des données d’utilisateur par le biais du protocole LDAP (Lightweight Directory Access Protocol). L’interface LDAP n’est disponible que pour les applications qui sont exploitées dans les réseaux de l’administration fédérale. À cet effet, eIAM met à disposition les indications relatives aux utilisateurs d’une application dans un répertoire dédié.
Considération d’utilisation: l’utilisation de cette interface est l’antithèse du CRITÈRE OPTIONNEL 2 mentionné plus haut, et il est recommandé de réfléchir à la manière dont le CRITÈRE OPTIONNEL 2 pourrait être satisfait dans le respect de la règle de simplicité.

Ⅳ AUTRES ASPECTS À PRENDRE EN CONSIDÉRATION

AUTRES ASPECTS À PRENDRE EN CONSIDÉRATION
×

GESTION DES ACCÈS

Sans gestion des accès (Authentication Only): L’application cible ne doit obtenir d’eIAM que l’identité de la personne qui se connecte (à des fins de reconnaissance); autrement dit, eIAM ne traite pas de données d’autorisation (rôles, droits, etc.), ni n’effectue de procédures d’onboarding, car la gestion des accès se fait entièrement dans l’application cible elle-même. L’utilisation d’un mandant d’accès eIAM n’est donc pas nécessaire, mais il est indiqué que l’application soit directement connectée au Bundestrustbroker (BTB), c’est-à-dire à l’intermédiaire de confiance de la Confédération (procédure de connexion légère).

Avec gestion des accès: Si eIAM doit traiter entièrement ou partiellement des données d’autorisation (droits, rôles, etc.) en vue de leur transmission à l’application cible lors du processus de connexion, et/ou effectuer des procédures d’onboarding pour l’application cible (recevoir les demandes d’accès des utilisateurs ou, inversement, envoyer des invitations à ces derniers par courriel ou courrier, y c. pour la gestion déléguée), l’utilisation d’un mandant d’accès eIAM est obligatoire. Pour ce qui est notamment des rôles et des droits à faire figurer dans le mandant d’accès eIAM, il faut, premièrement, que leur nombre soit raisonnable (pas de l’ordre de la centaine), deuxièmement, que les modifications (ajouter ou supprimer un droit, un rôle, etc., ou en changer la dénomination) soient peu fréquentes (nécessité de donner systématiquement mandat à l’OFIT pour ce faire) et, troisièmement, qu’aucune lecture dynamique de rôles, de droits, etc. par des sources externes ne soit nécessaire.

PROCÉDURE D’ONBOARDING

Il est recommandé de mentionner dans le dossier d’appel d’offres les procédures d’onboarding possibles et, parmi celles-ci, la procédure préférée. La notion d’onboarding décrit le processus qui aboutit à ce qu’un utilisateur peut utiliser une application cible avec son identité numérique. Les procédures d’onboarding sont décrites sous → Prestation 5. Les soumissionnaires doivent traiter ces procédures d’onboarding et décrire la manière dont celles-ci peuvent fonctionner avec leur solution. Les adjudicateurs ainsi que les soumissionnaires peuvent consulter l’OFIT et le secteur TNI de la ChF à ce sujet.

BESOIN ACCRU DE PROTECTION

eIAM applique la réglementation des zones à la zone de réseau «SZ+» et à celle du réseau de l’administration fédérale, et n’autorise l’accès à ces zones que sur authentification préalable avec une QoA de 50 au moins.

APPROVISIONNEMENT EIAM DE SOLUTIONS EN NUAGE

L’approvisionnement d’applications dans AWS et Azure et d’autres nuages est pratiqué avec succès. En particulier Azure définit de nombreuses conditions préalables. C’est pourquoi il est recommandé d’impliquer l’OFIT et le secteur TNI de la ChF dès que possible lorsqu’il est question d’acquérir des solutions en nuage. SaaS et d’autres configurations en nuage sont soumis à une obtention obligatoire .

Ⅴ LISTES DE CONTRÔLE

Ⅴ’ LISTE DE CONTRÔLE CRITÈRES ET ASPECTS
×

Télécharger listes de contrôle V' (WORD DOCX)

 Ⅴ’ LISTE DE CONTRÔLE CRITÈRES ET ASPECTS

CRITÈRE OBLIGATOIRE 1: possibilité de connexion de principe
☐ satisfait, à savoir via le protocole ____________

CRITÈRE OBLIGATOIRE 2: priorité donnée au fournisseur de service, y compris données et transport
☐ satisfait, y compris données et transport

CRITÈRE OPTIONNEL 1: utilisation des jetons d’OIDC, de SAML2.0 ou de WS-Federation selon la norme eIAM
☐ oui, satisfait
☐ non, la cible a besoin d’autres champs / données
      (nécessité d’une description précise par le soumissionnaire, recommandation de faire examiner les offres par le secteur TNI de la ChF et par l’OFIT)

CRITÈRE OPTIONNEL 2: OIDC, SAML2.0 ou WS-Federation en tant que seul point de contact (pas d’interfaces)
☐ oui, satisfait
☐ non, la cible a besoin d’interfaces à eIAM
      (nécessité d’une description précise par le soumissionnaire, recommandation de faire examiner les offres par le secteur TNI de la ChF et par l’OFIT)

GESTION DES ACCÈS
☐ Pas de gestion des accès dans eIAM (Authentication Only),
      car les droits, les rôles, etc. sont traités non pas dans eIAM, mais dans l’application cible
☐ Gestion des accès dans eIAM, car eIAM:
☐ gère ☐ tout ou ☐ partie des droits et rôles (nombre: ______ )
      et/ou ☐ effectue des procédures d’onboarding / ☐ assure la gestion déléguée
☐ Les soumissionnaires ont décrit cette procédure

PROCÉDURE D’ONBOARDING
☐ obsolète, car Authentication Only
☐ La préférence et le scénario de l’adjudicateur sont définis
☐ Les soumissionnaires ont décrit cette procédure

MODE D’EXPLOITATION
À l’OFIT (Atlantica, VM...), à l’extérieur, SaaS, solution en nuage, etc.

☐ __________________________________________


Ⅴ’’ LISTE DE CONTRÔLE PROCÉDURE DE CONNEXION ET QUALITÉ DE L’AUTHENTIFICATION
×

Télécharger listes de contrôle V'' (WORD DOCX)

 Ⅴ’’ LISTE DE CONTRÔLE PROCÉDURE DE CONNEXION ET QUALITÉ DE L’AUTHENTIFICATION


Dans les sections b) et c) ci-après, seule une proposition peut recevoir la réponse «oui».

Dans ces mêmes sections, les exigences sont énoncées de la moins élevée à la plus élevée. Les exigences élevées peuvent résulter d’exigences opérationnelles; il ne faut pas faire de nivellement inutile vers le haut, mais «seulement» respecter les directives informatiques de la Confédération, notamment la Si001.

a) Procédure de connexion:

☐oui / ☐non
Les titulaires d’un compte FED-LOGIN (collaborateurs de l’administration fédérale et personnes affiliées disposant d’un tel compte comme certains collaborateurs des cantons) doivent pouvoir se connecter par ce biais.

☐oui / ☐non
Les personnes dépourvues de compte FED-LOGIN doivent (aussi) pouvoir se connecter (partenaires, particuliers, etc. via AGOV, le CH-LOGIN et les fournisseurs d’identité tiers affiliés).

b) Qualité de l’authentification: vérification d’identité:

☐oui / ☐non
La personne fournit elle-même les données la concernant lors de la procédure de connexion (à l’ouverture du compte); il n’y a pas de vérification supplémentaire.
Justification: _____________________________________________________

☐oui / ☐non
La personne fournit elle-même les données la concernant lors de la procédure de connexion (à l’ouverture du compte), mais celles-ci doivent correspondre à celles figurant dans un registre (par ex. base de données d’adresses postales de particuliers, base de données des ressources humaines, etc.).
Justification: _____________________________________________________

☐oui / ☐non
Les renseignements concernant la personne titulaire du compte doivent être fiables au regard du document (pièce d’identité officielle munie d’une photo) déposé et comparé avec le visage de la personne.
Justification: _____________________________________________________

c) Qualité de l’authentification: facteurs d’authentification:

☐oui / ☐non
Des facteurs d’authentification non renforcés tels que des mots de passe ou des SMS-m TAN peuvent être utilisés. Au sein de l’administration fédérale, Kerberos est aussi considéré comme un protocole d’authentification non renforcé.
Justification: _____________________________________________________

 
☐oui / ☐non
Seuls des facteurs d’authentification renforcés (par ex. applications basées sur FIDO, clés de sécurité FIDO, cartes à puce, etc.) peuvent être utilisés.
Justification: _____________________________________________________


Le secteur TNI de la ChF et l’OFIT dispensent gratuitement des conseils concernant les modes d’exploitation.


Ⅴ’’’ LISTE DE CONTRÔLE POUR L’APPROVISIONNEMENT IAM, DIRECTIVES ET OBLIGATION D’ACHAT
unorthodoxesprungmarke
×

Télécharger listes de contrôle V''' (WORD DOCX)

Ⅴ’’’ LISTE DE CONTRÔLE POUR L’APPROVISIONNEMENT IAM À L’ADMINISTRATION FÉDÉRALE, DIRECTIVES, OBLIGATION D’ACHAT

Synopsis
×

Au sein de l’administration fédérale, on entend par approvisionnement IAM toutes les opérations pour lesquelles une identité numérique est requise pour authentifier l’entité agissant et qui requièrent parfois aussi des données supplémentaires d’autorisation (Access).

La présente liste de contrôle a pour objectif d’identifier les besoins sur la base de deux questions :

  1. Quel système IAM doit / peut être employé ?
  2. Quel niveau de qualité la prestation d’authentification doit-elle atteindre ?

Ces deux questions se fondent sur différentes sources d’information qu’il n’est pas facile de résumer :

En ce qui concerne la première question, l’élément le plus important est l’obligation d’achat du service standard, qui propose deux prestations, puis le fait que les cas dédiés ne sont pas soumis à l’obligation d’achat ;

Pour répondre à la deuxième question, il convient de se baser principalement sur les résultats de l’analyse du besoin de protection, mais de nombreux autres éléments sont à prendre en compte.

Dans la plupart des cas, la présente liste de contrôle permet de répondre à ces deux questions de manière directe.

Liste de contrôle

Cette liste de contrôle n’est pas spécifique à eIAM et peut être appliquée à tout type de situation au sein de l’administration fédérale. Veuillez répondre à chaque question par « oui » ou par « non ». Les questions se rapportent à une application cible concrète ou à un portail comportant plusieurs applications cibles.

Nom de l’application / du portail : _________________________________
(désigné ci-après par le terme « cible »). Les systèmes intermédiaires IAM (par ex. ePortals PAMS) regroupant plusieurs applications peuvent également être considérés comme des cibles.)


    A. SUJETS
  1. ☐oui ☐non : des personnes doivent-elles se connecter à la cible (connexion) ?


  2. ☐oui ☐non : des machines doivent-elles se connecter à la cible (connexion) ?
    3. Si vous avez coché « non » aux deux questions : l’approvisionnement IAM n’est pas nécessaire et la présente liste de contrôle n’est pas applicable.
    Si vous avez coché « oui » à la deuxième question, veuillez prendre contact avec le secteur Transformation numérique et gouvernance de l’informatique (TNI) de la Chancellerie fédérale (ChF).


    B. OBJET CIBLE (APPLICATION CIBLE / CIBLE)
  3. ☐oui / ☐non : la cible est-elle une application web (un programme qui s’utilise dans le navigateur) ?
    4. Si vous avez coché « oui », l’obligation d’achat prévue sous s’applique (l’obligation d’achat s’applique uniquement à l’administration fédérale centralisée. L’administration fédérale décentralisée peut effectuer des achats sous certaines conditions). Cette option est valable indépendamment de l’hébergeur et de la zone d’hébergement. Les logiciels en tant que services (SaaS) tels que les services en nuage Atlassian, par exemple, sont également soumis à l’obligation d’achat


  4. ☐oui / ☐non : la cible est-elle une application mobile (un programme qui s’utilise sur un smartphone ou une tablette) ?
    5. Si vous avez coché « oui » : l’obligation d’achat prévue sous s’applique (l’obligation d’achat s’applique uniquement au sein de l’administration fédérale centralisée. L’administration fédérale décentralisée peut effectuer des achats sous certaines conditions).


  5. ☐oui / ☐non : la cible est-elle une application client sur un terminal (par ex. un client lourd) ?
    En cas de technologie non souhaitée, veuillez prendre contact avec le secteur TNI de la ChF


  6. ☐oui / ☐non : la cible est-elle une application client sur un serveur, par ex. gérée à distance sur un émulateur de terminal tel que Citrix ?
    En cas de technologie non souhaitée, veuillez prendre contact avec le secteur TNI de la ChF


  7. ☐oui / ☐non : la cible est-elle une entité Internet des objets (IdO) connectée (par ex. un moteur pour les stores électriques, un dispositif d’ouverture de porte, une barrière de contrôle d’identité [comme à l’aéroport], un robot ou une machine automatique de travail, y. c. un robot logiciel sur les postes de travail « client BAB » ou autres clients) ?
    Pour toute question en lien avec l’utilisation d’IAM pour l’IdO, veuillez prendre contact avec le secteur TNI de la ChF. L’obligation d’achat est applicable et les pratiques sont en train d’être mises en place.


  8. ☐oui / ☐non : avez-vous répondu « non » à toutes les questions de la section B ?
    Si vous avez coché « oui », veuillez prendre contact avec le secteur TNI de la ChF.


    C. RESPONSABILITÉ POUR LA CIBLE (responsable spécialisé d’application RA)
  9. ☐oui / ☐non : le mandant de la cible fait-il partie de l’administration fédérale centralisée ou est-il soumis d’une autre manière à l’ordonnance sur la numérisation (ONum) ?
    10. Si vous avez coché « non », l’obligation d’achat fixée dans la section A est caduque. Pour les personnes extérieures à l’administration fédérale (externes), l’achat à titre volontaire est possible sous certaines conditions et même souvent recommandé.


    D. BESOIN DE PROTECTION
    Important : le besoin de protection n’a AUCUNE influence sur ce qui est indiqué dans les sections A à C concernant l’obligation d’achat.
  10. ☐oui / ☐non : le résultat de l’analyse du besoin de protection est-il « protection de base » ?
    Si vous avez coché « oui », la prestation d’authentification doit atteindre le niveau de protection « moyen », conformément aux directives Si001, et au moins le niveau de qualité d’authentification QoA30, conformément aux directives figurant sous www.eiam.admin.ch/qoa. Autrement dit, une authentification à deux facteurs est requise sans la nécessité de vérifier l’identité du sujet .


  11. ☐oui / ☐non : le résultat de l’analyse du besoin de protection est-il « besoin de protection accrue » ?
    12. Si vous avez coché « oui », la prestation d’authentification doit atteindre le niveau de protection « élevé », conformément aux directives Si001, et au moins le niveau de qualité d’authentification QoA50, conformément aux directives figurant sous www.eiam.admin.ch/qoa. Autrement dit, une authentification à deux facteurs est requise, accompagnée d’une vérification poussée de l’identité du sujet.


    E. HÉBERGEMENT DE LA CIBLE
    Important : le besoin de protection exclut les hébergements qui ne remplissent pas ses conditions.
  12. ☐oui / ☐non : la cible est-elle exploitée dans une zone de serveur nécessitant une protection accrue, par ex. une zone de serveur « plus » (SZ+) de l’administration fédérale ?
    13. Cette option n’est pas applicable dans une éventuelle situation inverse. Si vous avez coché « oui », la prestation d’authentification doit atteindre le niveau de protection « élevé », conformément aux directives Si001, et au moins le niveau de qualité d’authentification QoA50, conformément aux directives figurant sous www.eiam.admin.ch/qoa. Autrement dit, une authentification à deux facteurs est requise, accompagnée d’une vérification poussée de l’identité du sujet.


  13. ☐oui / ☐non : la cible est-elle exploitée dans une autre zone de serveur de l’administration fédérale ?
    14. Aucune influence sur les résultats de l’obligation d’achat des sections A. à C.


  14. ☐oui / ☐non : la cible est-elle exploitée par un prestataire externe à l’administration fédérale, qui s’occupe également de toutes les solutions en nuage (par ex. Abraxas, Azure, AWS, Google et autres) ?
    15. Aucune influence sur les résultats de l’obligation d’achat des sections A. à C.


    F. UTILISATEURS CIBLES
  15. ☐oui / ☐non : les collaborateurs de l’administration fédérale (internes et externes, ou les personnes affiliées enregistrées des administrations cantonales) doivent-ils pouvoir se connecter ?
    16. Si vous avez coché « oui », les utilisateurs cibles doivent utiliser la méthode de connexion FED-LOGIN (veuillez noter que FED-LOGIN peut également être utilisé sans carte à puce, cf. la section « Utilisation sans carte à puce » ). IMPORTANT : le type d’utilisateur cible n’a AUCUNE influence sur ce qui est indiqué dans les sections A à C concernant l’obligation d’achat. Cela vaut également pour les SaaS en location (par ex. solutions en nuage Atlassian, Power BI ou miro-boards).


  16. ☐oui / ☐non : des personnes autres que celles répondant aux critères énoncés au point 15 doivent-elles pouvoir se connecter ? Ces personnes peuvent être par exemple des citoyens ou des partenaires (tels que les cantons) qui ne sont pas enregistrés sur FED-LOGIN.
    Si vous avez coché « oui », ces utilisateurs cibles doivent utiliser la procédure de connexion AGOV d’eIAM (y compris les fournisseurs d’identité tiers associés, tels que eduID, les IdPs cantonaux et le CH-LOGIN, qui est actuellement en cours de suppression). IMPORTANT : le type d’utilisateur cible n’a AUCUNE influence sur ce qui est indiqué dans les sections A à C concernant l’obligation d’achat. Cela vaut également pour les SaaS en location (par ex. solutions en nuage Atlassian ou miro-boards).


  17. ☐oui / ☐non : les titulaires de l'e-ID étatique suisse doivent-ils pouvoir s'authentifier directement avec celle-ci?
    18. La réponse à cette question n'a AUCUNE influence sur l'obligation d'achat, les authentifications e-ID doivent être obtenues via le service standard IAM, à savoir via la composante AGOV du service standard intégral IAM. Une connexion directe de l'e-ID à l'application cible à des fins d'authentification (login) n'est pas autorisée.


  18. ☐oui / ☐non : les personnes disposant de fournisseurs d’identités spéciaux (IdPs de secteur, comme définis sous , par ex. les professionnels de santé qui bénéficient des services du fournisseur d’identité HIN) doivent-elles pouvoir se connecter ?
    19. Si vous avez coché « oui », vous pouvez déposer une demande auprès du secteur TNI de la ChF. IMPORTANT : l’obligation d’achat d’eIAM s’applique également dans cette situation. Les IdPs de secteur doivent être obtenus en passant par eIAM et ne peuvent pas être connectés à des systèmes (systèmes cibles ou systèmes IAM intermédiaires) autres qu’eIAM. Le type d’utilisateur cible n’a AUCUNE influence sur ce qui est indiqué dans les sections A à C concernant l’obligation d’achat. Cela vaut également pour les SaaS en location (par ex. solutions en nuage Atlassian ou miro-boards).


    G. GESTION DES ACCÈS
  19. ☐oui / ☐non : Les personnes doivent-elles être invitées par e-mail à utiliser l'application cible par eIAM (e-mail avec code d'embarquement)?
    20. La réponse à cette question n'a pas d'influence sur l'obligation de retrait. Si oui, la gestion déléguée de l'eIAM doit être utilisée et la réponse à la question suivante est obligatoirement « oui ». Toutefois, l'application cible peut gérer elle-même les e-mails d'invitation.

  20. ☐oui / ☐non : les personnes doivent-elles être dotées de rôles et de droits dans eIAM?
    21. La réponse à cette question n'a aucune influence sur l'obligation d'achat (l'obligation d'achat s'applique aux identités et à l'authentification, pas à la gestion des accès). Les rôles et les droits peuvent être gérés dans eIAM et ou dans l'application cible, donc également sous une forme mixte. Exigences extrêmes : rien concernant la gestion des accès dans eIAM, tout dans l'application cible (eIAM = Authentication Only) versus rien concernant la gestion des accès dans l'application cible, tout dans eIAM (eIAM = avec mandant d'accès), c'est-à-dire que l'application suit les instructions du jeton d'authentification eIAM.


    H. DIFFÉRENCIATION DE L’OBLIGATION D’ACHAT
  21. ☐oui / ☐non : les réponses apportées aux sections A à C indiquent-elles une obligation d’achat du service standard, et la cible est-elle située dans le domaine de la police ou de la justice ?
    22. Si vous avez coché « oui », le portail SSO du DFJP, qui fait partie du service de base de l’administration fédérale pour la gestion des identités et des accès () doit être utilisé à la place d’eIAM.
    Les deux services sont gérés par le secteur TNI de la ChF.


    I. INFORMATIONS CONCERNANT LES APPLICATIONS INTÉGRÉES À DES PORTAILS
  22. Pour les applications intégrées à des portails (par ex. Easygov, ePortal, eGov DETEC), l’obligation d’achat telle qu’elle est prévue sous s’applique. Veuillez noter que le portail peut faire abstraction du passage à eIAM, de sorte que l’application individuelle ne doit pas être connectée à eIAM, mais seulement la couche portail elle-même. Les procédures de connexion propres au portail et les connexions directes des fournisseurs d’identités sur ces plateformes ne sont pas autorisées.


    J. DÉTAILS CONCERNANT KERBEROS
  23. Les applications web et mobiles natives peuvent utiliser le protocole Kerberos uniquement si une dérogation a été accordée à cet effet. À défaut, elles doivent employer eIAM.

  24. Kerberos peut directement être mis en place pour les autres applications et la bureautique (selon les circonstances ; veuillez consulter le secteur TNI de la ChF).

  25. Le protocole Kerberos ne présente PAS un niveau de sécurité « élevé » conforme aux directives Si001, sauf si la ressource concernée fait partie intégrante d’une forêt d’utilisateurs de l’administration fédérale (autorisation du secteur TNI de la ChF, DS / DAB requise) et que l’authentification sur le client utilisé a été effectuée avec une carte à puce (ce qui n’est pas possible avec l’application Mobile VDI, par exemple).


    K. DÉTAILS CONCERNANT AGOV
  26. L’administration fédérale centrale n’utilise AGOV « direct only »* que dans de très rares cas exceptionnels soumis à autorisation, mais recourt sinon à AGOV via le « full »* eIAM. Des dérogations sont possibles ; la demande peut être faite sous .

  27. L’administration fédérale décentralisée peut acheter AGOV via eIAM (des conditions spéciales s’appliquent) ou AGOV « direct only »*.

  28. Les autres autorités suisses (cantons, communes, établissements combinés publics et privés) achètent AGOV « direct only »* et non AGOV via eIAM « full »*, sous réserve de la compatibilité avec la loi fédérale sur l’utilisation des moyens électroniques pour l’exécution des tâches des autorités.
*
Schéma eIAM « full » : fournisseur d’identité AGOV ➤ système IAM eIAM ➤ application cible (ou système IAM intermédiaire)
Schéma AGOV « direct only » : fournisseur d’identité AGOV ➤ application cible (ou système IAM intermédiaire)