From 918c984021a8d8484bb96a47ffb51d7ed416c7e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20P=C3=A9ters?= <fpeters@entrouvert.com>
Date: Mon, 19 Oct 2015 10:08:31 +0200
Subject: [PATCH] doc: reorg and add a new security section (#8691)

---
 help/fr/api-services.page | 152 +++++++++++++++++++-------------------
 1 file changed, 76 insertions(+), 76 deletions(-)

diff --git a/help/fr/api-services.page b/help/fr/api-services.page
index 2101ddb..ad2bd27 100644
--- a/help/fr/api-services.page
+++ b/help/fr/api-services.page
@@ -35,78 +35,6 @@ d'utiliser celle qui est décrite dans ce document.</p>
 </section> <!-- #intro -->
 
 
-<section id="requete">
-<title>Requête</title>
-
-<p>Le portail effectue des requêtes HTTP GET vers les différents services. Les
-échanges atendus sont conformes au style d'architecture REST.</p>
-
-
-<section id="req-ident">
-<title>Requête identifiante</title>
-
-<p>L'URI utilisée pour ces requêtes peut contenir des informations identifiant
-l'usager concerné.</p>
-
-<section id="saml">
-<title>Identifiant SAML</title>
-
-<p>Lorsque le service intègre le protocole de fédération d'identité SAML, la
-requête identifiante utilisera un identifiant SAML, le NameID :</p>
-
-<code>
-https://www.example.com/eservices/pending?NameID=<var>nameid</var>
-</code>
-</section> <!-- #saml -->
-
-<section id="adel">
-<title>Adresse électronique</title>
-
-<p>Lorsque le service n'intègre pas le protocole de fédération d'identité SAML,
-la requête identifiante utilisera l'adresse électronique de l'utilisateur :</p>
-
-<code>
-https://www.example.com/eservices/pending?email=<var>email</var>
-</code>
-
-<note>
-  <title>Adresses électroniques identiques</title>
-  <p>L'utilisation de cette méthode pour identifier l'utilisateur ne fonctionne
-  que si ce dernier a employé la même adresse électronique pour la création du
-  compte citoyen et la création du compte sur le service.</p>
-</note>
-</section> <!-- #adel -->
-</section> <!-- #req-ident -->
-
-<section id="autres">
-<title>Autres requêtes</title>
-
-<p>Il est possible pour le service d'exposer davantage de données via des
-URL.</p>
-
-<section id="donnees">
-<title>Données génériques (qui ne concernent pas un utilisateur particulier)</title>
-
-<p>L'applications peut exposer des données génériques (horaires, informations,
-actualités). Elle doit le faire via une URL du type :</p>
-
-<code>https://www.example.com/eservices/horaires/</code>
-</section> <!-- #donnees -->
-
-<section id="filtres">
-<title>Filtres</title>
-
-<p>Il peut être utile pour le portail citoyen de filtrer les données récupérées
-en utilisant des critères divers (catégories, localisations...) via les URL.
-Les filtres doivent être compris dans les URL sous la forme (pour exposer les
-horaires de Montpellier par exemple) :</p>
-
-<code>https://www.example.com/eservices/montpellier/horaires/</code>
-
-</section> <!-- #filtres -->
-</section> <!-- #autres -->
-</section> <!-- #requete -->
-
 <section id="structure">
 <title>Structure de l'information fournie par les services</title>
 
@@ -225,11 +153,43 @@ des colonnes.
 
 </section> <!-- #structure -->
 
-<section>
-  <title>Signature de l'URL</title>
+
+<section id="requete">
+<title>Requête</title>
+
+<p>Le portail effectue des requêtes HTTP GET vers les différents services. Les
+échanges atendus sont conformes au style d'architecture REST.</p>
+
+<section id="req-security">
+<title>Protection des accès au service</title>
+
+<p>L'accès au service peut être protégé de différentes manières, le portail
+citoyen peut utiliser les mécanismes suivants pour s'authentifier auprès du
+service.</p>
+
+<section id="req-security-http-auth">
+<title>Authentification HTTP</title>
+
+<p>Le portail citoyen peut utiliser l'authentification HTTP basique (définie
+dans la RFC 2617).</p>
+</section>
+
+<section id="req-security-client-cert">
+<title>Authentification par certificat X.509</title>
+
+<p>Le portail citoyen peut s'authentifier à l'aide d'un certificat client.</p>
+</section>
+
+<!--
+<section id="req-security-oauth2">
+</section>
+-->
+
+<section id="req-security-shared-secret">
+<title>Authentification par secret partagé</title>
 
 <p>
-L'URL doit être signée via une clé partagée à configurer des deux cotés de la
+L'URL peut être signée via une clé partagée à configurer des deux cotés de la
 liaison, la signature est du type HMAC; l'algorithme de hash à employer est
 passé en paramètre.
 </p>
@@ -305,6 +265,46 @@ maintenir une bonne synchronisation des horloges, en utilisant par exemple le
 protocole NTP.
 </p></note>
 
-</section>
+</section> <!-- req-security-shared-secret -->
+</section> <!-- req-security -->
+
+
+<section id="req-ident">
+<title>Identification de l'usager</title>
+
+<p>L'URI utilisée pour ces requêtes peut contenir des informations identifiant
+l'usager concerné.</p>
+
+<section id="saml">
+<title>Identifiant SAML</title>
+
+<p>Lorsque le service intègre le protocole de fédération d'identité SAML, la
+requête identifiante utilisera un identifiant SAML, le NameID :</p>
+
+<code>
+https://www.example.com/eservices/pending?NameID=<var>nameid</var>
+</code>
+</section> <!-- #saml -->
+
+<section id="adel">
+<title>Adresse électronique</title>
+
+<p>Lorsque le service n'intègre pas le protocole de fédération d'identité SAML,
+la requête identifiante utilisera l'adresse électronique de l'utilisateur :</p>
+
+<code>
+https://www.example.com/eservices/pending?email=<var>email</var>
+</code>
+
+<note>
+  <title>Adresses électroniques identiques</title>
+  <p>L'utilisation de cette méthode pour identifier l'utilisateur ne fonctionne
+  que si ce dernier a employé la même adresse électronique pour la création du
+  compte citoyen et la création du compte sur le service.</p>
+</note>
+</section> <!-- #adel -->
+</section> <!-- #req-ident -->
+
+</section> <!-- #requete -->
 
 </page>