Exigences aux URLs de l'application

La conformité aux exigences eIAM pour les URLs est obligatoire pour les applications qui sont exploitées au sein des réseaux de l'administration fédérale!

Explication des parties de l'URL

Les URLs par exemple https://www.gate.amt.admin.ch/appl1/private/ d'une application web se compose d'une partie protocole (https://) d'une partie Fully Qualified Domain Name (FQDN) (www. gate.amt.admin.ch) et d'une partie chemin (/appl1/private/) .

Ce qui suit décrit les spécifications concernant ces parties de l'URL.

Point d'entrée FQDN

La désignation du FQDN sur le PEP eIAM-Web est en principe prédéfinie:

eIAM PEP Externe (réseau administratif fédéral, réseau cantonal et Internet)

eIAM instance	FQDN
Production (PRO)	www.gate.<amt>.admin.ch
Réception (ABN)	www.gate-a.<amt>.admin.ch
Référence (REF)	www.gate-r.<amt>.admin.ch

Une procédure appelée "Split Brain DNS" veille à ce que le même FQDN sur Internet soit résolu sur une autre adresse IP (externe) que sur le réseau de l'administration fédérale, où le FQDN est résolu sur une adresse IP interne au réseau administratif fédéral. Du côté de l'eIAM, les requêtes provenant du réseau de l'administration fédérale passent par d'autres instances eIAM-Web PEP que les requêtes provenant de l'extérieur du réseau de l'administration fédérale. Pour l'application, cela est toutefois transparent.

Domaines d'application

Le PEP web eIAM est un serveur proxy inverse sécurisé dans une version front door. Il permet ainsi d'accéder à plusieurs applications spécialisées dans un domaine d'authentification unique via le même FQDN. Cela exige une séparation propre des applications via les chemins URI, car le eIAM-Web PEP se base sur le chemin pour choisir le backend auquel la requête http de l'utilisateur doit être envoyée.

Pour que l'eIAM-Web PEP puisse remplir correctement sa fonction de niveau d'autorisation générale, il convient de définir des domaines d'application. Les domaines d'application sont définis par l'URL dans l'application. Les domaines d'application, également appelés URI Name-spaces, peuvent être définis avec la structure du répertoire.

Différents domaines d'application sont nécessaires si, dans l'application, les ressources doivent être protégées différemment dans la structure de répertoire. Il se peut ainsi qu'une partie de l'application soit accessible sans authentification, tandis qu'une autre partie de l'application n'est accessible qu'aux utilisateurs authentifiés et autorisés, et qu'une autre partie de l'application n'est accessible qu'avec un haut niveau d'authentification.

La configuration d'une telle politique est également valable pour tous les sous-répertoires (par exemple, une configuration pour /appl1/private/* est également valable pour /appl1/private/docs/*).
Si l'on utilise le schéma suivant pour les domaines d'application, l'eIAM-Web PEP peut veiller dès le départ à ce que seuls les accès correctement authentifiés et autorisés parviennent à l'application.

Exemple d'URL pour les domaines publics, protégés et spécialement protégés:

/appl1/* = espace de nommage contextuel de l'application domaine public (non authentifié)
/appl1/public/* = domaine public (non authentifié)
/appl1/private/* = domaine authentifié (requiert l'identification de l'utilisateur) et autorisé (requiert le rôle de granularité grossière)
/appl1/private/strong/* = zone authentifiée (requiert une connexion utilisateur avec authentification forte) et autorisée avec rôle granulaire grossier

Il est important de bien délimiter les différents espaces de noms URI. Il est bien sûr possible de réserver l'accès à l'ensemble de l'espace de noms URI de l'application aux seuls utilisateurs autorisés grâce à un rôle granulaire. Il est également possible d'exiger une authentification forte pour l'ensemble de l'application.

Règle 8: les différents espaces de noms URI d'une application ayant des besoins de protection différents doivent être structurés de manière simple et ne doivent pas se chevaucher.

Des chevauchements ont lieu si l'on veut par exemple protéger différemment /appl1/private/* et /appl1/private/public/*. A l'intérieur du chemin protégé /appl1/private/* se trouve ici un chemin non protégé ./public/*. Ceci n'est pas autorisé.

Public

Ce domaine est public et l'URL peut être consultée par n'importe qui sans identification de l'utilisateur et sans vérification des autorisations.
Les ressources qui doivent être utilisées avant l'authentification de l'utilisateur doivent en principe se trouver dans une zone non protégée.

Authentique et autorisé avec le rôle APPL.ALLOW

Toutes les applications ont un rôle d'autorisation générale '<nom de l'application de eIAM-AM>.ALLOW'. Si un utilisateur doit être autorisé à accéder à une application, ce rôle doit au moins lui être attribué dans son profil. Ce n'est qu'avec ce rôle sommaire que l'utilisateur a accès aux zones protégées de l'application via le PEP Web eIAM. Comme celui-ci impose que l'utilisateur qui envoie la requête possède ce rôle, il faut en outre définir une force minimale d'authentification pour chaque application.

eIAM utilise les qualités d'authentification suivantes

Qualité de l'authentification (QoA)

Authentique et autorisé avec un rôle défini à granularité fine (option)

Le service eIAM offre un concept de rôle à 2 niveaux pour la gestion des accès. Il est par exemple possible de protéger en plus une URL et de ne l'autoriser que pour le rôle "Nom de l'application de eIAM-AM>.<ROLLE>". Les rôles à granularité fine doivent être définis dans le dossier eIAM avant l'intégration.

Fonctionnement des rôles eIAM

Authentique avec authentification forte (option)

Certaines parties ou l'ensemble de l'application peuvent être protégées en demandant une authentification plus forte. Ces URL protégées ne peuvent alors être consultées que si l'utilisateur s'est connecté avec une authentification considérée comme plus forte. Les chemins qui doivent être protégés et avec quel niveau d'authentification doivent être définis dans le dossier eIAM avant l'intégration.

Gestion de l'espace de nommage URI

Le PEP web eIAM effectue un dispatching des requêtes. Cela signifie que pour chaque requête envoyée au PEP par le navigateur web, le PEP doit évaluer à quelle application la requête doit être envoyée. Pour cela, des mappings sont définis sur le PEP. La gestion des espaces de noms URI est importante afin d'éviter tout chevauchement des espaces de noms.

Le PEP peut dispatcher les requêtes envoyées par le navigateur web à l'aide de la possibilité suivante.

Dispatching de requêtes par mappage URI de requêtes - Standard

Exemple:
https://www.gate.amt.admin.ch/appl1/* => https://appl1.ssz.admin.ch/appl1/*
https://www.gate.amt.admin.ch/appl2/* => https://appl2.ssz.admin.ch/appl2/*
https://www.gate.amt.admin.ch/appl3/* => https://appl2.ssz.admin.ch/appl3/*

Structure d'une URL : <entrypoint(pep)>/<application>/<access>/<resource>
Exemple : https://www.gate.bit.admin.ch/myappl/private/welcome.html

Où les différentes parties sont définies comme suit:

Key	Description
<entrypoint(PEP)>	Point d'entrée dépendant du mandant https://www.gate.amt.admin.ch
<application>	URI réservé à l'application, par ex. /myappl
<access>	type d'accès selon le domaine de l'application, voir chapitre 0, par ex. /private
<resource>	ressource à l'intérieur du domaine d'application welcome.html

Espaces de noms URI réservés par eIAM

/_pep/*
/auth/*
/errorpages/*
/login/*
/styles/*
/scripts/*
/images/*
/nevisidm/*
/passwordchange/*
/pwreset/*
/apstat
/favicon.ico

Cependant, il va de soi qu'une application peut par exemple utiliser le namespace /appl1/public/images/*.

Paramètres de requête réservés par eIAM

Les paramètres de requête suivants sont réservés par eIAM et ne doivent pas être utilisés par les applications qui utilisent le service eIAM.

?login
?logout