Exigences techniques pour l'application

Exigences techniques générales

Cette page décrit les exigences techniques générales de l'application. En font partie des directives importantes pour la sécurité, la Proxy Awareness, c'est-à-dire que l'application doit impérativement remplir les exigences suivantes pour pouvoir être intégrée avec le service standard eIAM.

Transmission cryptée des données

L'ensemble de la transmission des données du navigateur web à l'application DOIT être cryptée au moyen de TLS dans la couche de transport. Pour que les fonctions WAF d'eIAM et la fonctionnalité Reverse Proxy soient possibles, le cryptage entre le navigateur et l'application doit être rompu sur le loadbalancer avant le WAF et sur le PEP web eIAM et une nouvelle connexion, également cryptée, doit être établie. De même, toute la communication nécessaire à l'authentification de l'utilisateur doit être chiffrée sur la couche de transport.

Proxy-Awareness

Pour permettre l'intégration d'applications dans le service eIAM, des exigences sont posées à ce que l'on appelle la proxy-awareness de l'application. Les applications qui sont construites de manière à être conscientes du proxy peuvent être utilisées sans effort supplémentaire derrière un proxy inverse et ainsi être intégrées dans le service eIAM.

Pour savoir si une application web est proxy-aware, il suffit de tester l'application via le reverse proxy ou de rechercher dans le contenu HTML des liens entièrement qualifiés ou absolus. Les applications de servlet J2EE sont généralement proxy-aware ou peuvent être rendues proxy-aware sans grand effort en adaptant l'URL de déploiement. Si le contenu HTML ne change pas lors de l'adaptation de l'URL de déploiement, l'application est entièrement proxy-aware.

Ci-dessous, les critères de proxy awareness sont expliqués plus en détail. Ces exigences doivent impérativement être remplies par les applications utilisées avec eIAM.

Remarque
N'est pas une exigence d'eIAM pour les applications en dehors des réseaux de l'administration fédérale.

URLs dans les applications "Proxy-Aware"
Typiquement, l'utilisateur utilise une application en adressant des requêtes à des URL. Une URL peut être soit une adresse entièrement qualifiée, soit une adresse absolue, soit une adresse relative. Contrairement à une URL entièrement qualifiée, une URL relative ne contient pas de préfixe de schéma ni d'adresse de serveur, mais uniquement le chemin et le nom du document cible. Le chemin lui-même peut être absolu (en partant du répertoire racine du serveur web) ou relatif au répertoire du document source. Si le chemin commence par "/", il s'agit d'un chemin absolu à partir du répertoire racine correspondant.

Le tableau suivant présente les différents types de liens avec des exemples.

Type de lien	Exemple
Chemins relatifs	./Documents/index.html ../images/logo.gif ../../resources/title_bar.png
Chemins absolus	/myapp/Documents/index.html /myapp/images/logo.gif
URL entièrement qualifié	https://mycompany.com/myapp/Documents/index.html https://mycompany.com/myapp/images/logo.gif

L'illustration ci-dessous présente les différents types de liens tels qu'ils doivent être utilisés dans l'application.

: Utilisation des différents types de liens

Les règles suivantes s'appliquent aux cas présentés dans l'illustration ci-dessus.

cas	lien	type	règle
1	./Documents/index.html	Chemin relatif à l'intérieur de l'application	1ère règle
2	../images/logo.gif	Chemin relatif vers les ressources internes]	3ème règle
3	/otherapp/start.do	Chemin absolu vers une autre application derrière du même PEP (FQDN identique)]	4ème règle
4	https://www.otherserver. com/foo/bar/	URL entièrement qualifiée vers une ressource web externe (en dehors du FQDN de l'application actuelle)	5ème règle

Les directives suivantes s'appliquent au développement d'applications

Utilisation d'URLs relatives
1ère règle: Les applications doivent utiliser des URL relatives au sein de l'application pour l'intégration dans eIAM.

L'utilisation d'URL relatives est une condition nécessaire, mais pas suffisante, pour la sensibilisation au proxy. Dans un environnement proxy, toutes les applications intégrées sur le proxy inverse sont mappées sur un emplacement de niveau supérieur (emplacement racine) dédié (p. ex. "https://somehost.ch/myappl/"). On peut en déduire en outre les critères de sensibilisation au proxy décrits dans les paragraphes suivants.

URLs auto-contenues (self-contained URL).
2ème règle: les applications web et leurs ressources doivent être accessibles et fonctionnelles sous une URL auto-contenue.
Étant donné que le proxy effectue le mappage des servlets et donc la construction de la chaîne de filtrage à l'aide de l'URL, les applications web doivent être accessibles et fonctionnelles sous leur propre URL autonome (self-contained URL) (p. ex. "https://somehost.ch/myappl/"). Elles ne doivent pas être utilisées sous le répertoire racine (p. ex. "https://somehost.ch/"). Cela vaut pour toutes les ressources mises à disposition par l'application - donc aussi les feuilles de style, les images, les scripts, etc.

URLs au sein des applications
3ème règle: tous les liens vers des ressources internes à l'application doivent être des indications de chemin relatives.
De la même manière, les liens au sein de l'application qui adressent des ressources propres doivent être relatifs (p. ex. "./pics/picture.gif") et ne peuvent pas être indiqués de manière absolue (p. ex. "http://somehost.ch/myappl/pics/picture.gif").

Coupler les applications via des chemins absolus.
4ème règle: les applications sont couplées au moyen d'indications de chemin absolues sans adresse de serveur.
Si une autre application est adressée au sein d'une application, on parle d'applications couplées. Au sein de l'eIAM, ce couplage doit se faire exclusivement via le proxy. L'application doit savoir comment son application partenaire est accessible via le proxy. Les liens vers les applications partenaires doivent donc être réalisés sous forme de chemins absolus sans indication de l'adresse du serveur (p. ex. "/otherapp/start.do").

Adressage d'URL externes
5ème règle: les URL externes à l'application sont toujours adressées avec des indications absolues de serveur et de chemin.
Les URL qui s'adressent à une ressource externe (p. ex. renvoi à une page web d'une autre organisation ou page web générale sur Internet) sont bien entendu indiquées de manière absolue avec des indications de serveur et de chemin. Il convient de s'assurer que de telles URL sont globalement accessibles.

La balise HTML "basehref"
6ème règle: la balise HTML "basehref" ne doit être placée dans aucune page HTML.
Souvent, la balise HTML "basehref" est utilisée pour réduire la quantité de texte répétitif dans un document HTML. La balise "basehref" indique au navigateur que tous les liens relatifs dans ce document commencent par l'adresse indiquée. Cela aide certes lors de la création d'un document HTML, car la mise en page et le comportement peuvent être facilement testés localement et le document ne doit pas être placé sur un serveur. Toutefois, elle est difficilement applicable dans un environnement proxy, car le proxy reproduit l'application sur un emplacement de premier niveau dédié. Ainsi, la balise "basehref" ne doit être placée dans aucune page HTML.

Indication du type de contenu.
7ème règle: le type de contenu doit toujours être indiqué.
Le type de contenu doit toujours être indiqué, sinon le reverse proxy utilise une valeur par défaut. Cela peut entraîner des effets indésirables dans le navigateur (le code HTML est affiché comme du texte).

Les règles suivantes ne sont pas une exigence d'eIAM pour les applications en dehors des réseaux de l'administration fédérale.

URI au sein des applications
8ème règle: les différents espaces de noms URI d'une application avec 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 souhaite 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é.

Exigences pour les URLs de l'application

Cookies pour le suivi de session
9ème règle: l'utilisation de cookies pour le suivi de session de l'application est obligatoire.
Le suivi de session de l'application doit être effectué par cookie de session. La réécriture d'URL comme méthode de suivi de session n'est pas supportée par eIAM.

Exigences générales pour la gestion des sessions

Session-Tracking
10ème règle: les timings de l'application doivent être plus élevés que ceux du PEP. Le PEP est le maître sur les sessions.
Il est important que les applications adaptent leur durée de session et leurs délais d'attente au PEP.

Exigences générales pour la gestion des sessions

SAML/messages sur URL fixes
11ème règle: les applications au sein des réseaux de l'administration fédérale doivent accepter les messages SAML/ sur des URL fixes.
Pour les applications au sein des réseaux de l'administration fédérale, l'adresse de destination de la réponse de l'eIAM-Web PEP à l'AuthnRequest de l'application est fixe et préconfigurée dans les métadonnées de l'application. L'application doit donc recevoir la SAML Response, la LogoutRequest et la LogoutResponse sur une URL fixe.

Exigences techniques détaillées de l'interface SAML 2.0

Fin de la session SSO
12ème règle: Lors de la fin d'une session SSO (SLO Single Logout/Timeout), les applications peuvent être informées par le PEP via l'URI de Logout configurée.
Il est possible de configurer un URI de logout par application dans le PEP eIAM-Web. Si cet URI est défini, chaque application utilisée au sein de cette session SSO est informée lorsque la session SSO est terminée. Ainsi, les applications peuvent être informées par le PEP de la fin d'une session SSO afin de fermer proprement la session de l'utilisateur.

Terminaison de la session RP-PEP

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

Les paramètres de requête suivants sont réservés au service eIAM et NE DOIVENT PAS être utilisés par les applications.

?logout
?login

Remarque
N'est pas une exigence d'eIAM pour les applications en dehors des réseaux de l'administration fédérale.

Verbes http supportés par eIAM

Les verbes http suivants sont supportés par défaut par le service eIAM:

GET
POST

Selon l'application, il peut être nécessaire de débloquer d'autres verbes http. Cela doit être convenu avec l'expert en intégration IAM. Il n'est pas possible de se connecter avec une POST Request initiale. La POST Request est redirigée par eIAM-Web vers la même URL avec le paramètre de requête "login". Ensuite, l'agent utilisateur envoie la POST Request initiale en tant que GET Request avec le paramètre de requête "login".

Remarque
N'est pas une exigence d'eIAM pour les applications en dehors des réseaux de l'administration fédérale.

eIAM Cookie Handling

Par défaut, les cookies émis par l'application sont mis en cache sur le PEP web eIAM et ne sont pas transmis au navigateur web. Les cookies définis par l'application ne circulent donc qu'entre le PEP eIAM et l'application.

Si les cookies définis par l'application ne doivent pas être mis en cache sur le PEP, mais doivent être transmis jusqu'au navigateur web de l'utilisateur, cela doit être indiqué dans le dossier eIAM, en précisant le nom exact du cookie lors de la commande du service eIAM.

Si des cookies sont transmis du PEP au navigateur web de l'utilisateur du PEP, ils sont automatiquement réécrits (chemin et hôte), de sorte qu'ils s'appliquent au PEP et non à l'application.

Remarque
N'est pas une exigence d'eIAM pour les applications en dehors des réseaux de l'administration fédérale.

eIAM Request Timeout

Le PEP eIAM-Web peut traiter un nombre limité de requêtes http simultanées. C'est pourquoi, dans l'intérêt de toutes les applications accessibles via le PEP eIAM-Web, le temps pendant lequel un tel processus est occupé à attendre la réponse de l'application est limité. On s'assure ainsi que ce processus est à nouveau libéré pour le traitement d'une autre demande et qu'une seule application défectueuse n'influence pas négativement la disponibilité d'autres applications.

L'expérience montre que les utilisateurs n'attendent guère plus de 1 à 2 minutes pour savoir si une réponse est encore fournie à leur requête, jusqu'à ce qu'ils abandonnent (ferment le navigateur ou naviguent vers une autre ressource) ou qu'ils envoient à nouveau la requête (refresh).

La valeur de ce délai d'attente est fixée à 2 minutes dans eIAM-Web. Après cet intervalle, une page d'erreur html est livrée au client avec le code http 502 (Upstream Server not available).

La valeur du Request Timeout peut être configurée différemment par mapping dans des cas exceptionnels justifiés. Une demande doit être faite pour modifier cette valeur.

Remarque
N'est pas une exigence d'eIAM pour les applications en dehors des réseaux de l'administration fédérale.

Suivi du client entre eIAM-Web PEP - navigateur web

Un cookie de session non persistant est émis par le PEP au nom de '<eiam-amt>', par exemple 'eiam-ofit'. Le suivi du client sur le PEP est basé sur ce cookie. Le cookie est renouvelé après l'établissement d'un contexte de sécurité (session) sur le PEP.

Le cookie de session émis par le PEP eIAM-Web possède les attributs suivants:

HttpOnly - (le navigateur web ne doit pas permettre la lecture du cookie par un script. Ceci n'est pas supporté par tous les navigateurs, surtout les plus anciens).
Secure - (le navigateur web ne peut renvoyer le cookie que par une connexion sécurisée sur la couche de transport)
Host - (non défini) réglé par défaut sur le FQDN de l'éditeur du cookie
Path - / (Root)

Suivi client entre applications - eIAM-Web PEP

Si l'application établit un contexte de sécurité avec la session de l'utilisateur sur le PEP, l'application DOIT utiliser un suivi client basé sur un cookie. Les cookies de l'application ne circulent qu'entre l'application et le PEP et ne sont pas transmis au navigateur web de l'utilisateur. D'autres mécanismes de suivi de session comme SSL-ID et URL Rewriting ne sont pas supportés par le service eIAM.

Remarque
N'est pas une exigence d'eIAM pour les applications en dehors des réseaux de l'administration fédérale.

Application Bouton de déconnexion avec page de déconnexion et possibilité de Re-Login

L'application à intégrer doit offrir aux utilisateurs la possibilité de mettre fin à leur session en cours. Pour cela, il faut implémenter dans l'application un bouton ou un lien qui initie une déconnexion. Pour les applications implémentées à l'aide de STS-PEP (standard), le STS-PEP redirige l'utilisateur vers la page de déconnexion de l'application. Cette page de déconnexion, qui doit être mise à disposition par l'application, confirme à l'utilisateur que sa session a été correctement fermer.

: Confirmation de la déconnexion avec re-login

Pour qu'un utilisateur puisse se reconnecter à l'application métier directement après une déconnexion, il existe un bouton optionnel "Re-Login" sur la page de déconnexion. Ce bouton facilite la navigation si l'on souhaite se reconnecter directement, par exemple si l'utilisateur a oublié une action dans l'application métier ou si quelque chose est testé dans l'application métier. Le bouton est disponible sur tous les environnements REF, ABN et PROD.