IDP_URL/idp/oidc/authorize/?client_id=...&...&redirect_uri=...&state=...&...* le détail de l'appel se trouve dans les spécifications, on notera simplement ici les paramètres importants suivant: ** @client_id@ : identifie le portail métier auprès du fournisseur d'identité, la valeur de ce champ sera fournit par l'administrateur de la plateforme Publik ** @redirect_uri@ : URL sur laquelle l'usager sera re-dirigé après authentification, elle devra être déclarée auprès de l'administrateur de la plateforme Publik (plusieurs sont possibles, mais pas de wildcard) ** @state@ : paramètre opaque retourné au retour sur le portail métier si le SSO échoue ou réussi, il permet au portail de maintenir un état entre la requête de SSO et sa réponse (par exemple URL de retour précise sur le portail, sachant que l'URL de retour au SSO ne peut pas varier énormément) 3. le fournisseur d'identité de la plateforme Publik procède à l'authentification de l'usager, s'il n'est pas déjà authentifié, puis s'il n'a pas encore donné son autorisation lui présente un formulaire lui demandant de confirmer sa volonté de s'authentifier auprès du portail en fournissant un certain nombre d'attributs. 4. le fournisseur d'identité Publik redirige le navigateur de l'utilisateur sur l'URL de retour (ou de callback) déclaré par le portail métier par exemple,
https://portail-metier.collectivite.fr/oidc/callback/?code=xxx&state=yyy5. le portail métier à la réception de cette requête doit : 5.1. éventuellement *utiliser le paramètre @state@* pour retrouver un état conservé (URL de retour sur le portail, identifiant métier de la personne demandé préalablement, jeton transmis par mail ou SMS permettant l'appairage, etc...) en session 5.2. *appeler le web-service @token@* (@IDP_URL/ipd/oidc/token/@) du fournisseur d'identité en s'authentifiant avec son @client_id@ et son @client_secret@ (fourni lui aussi par l'administrateur de la plateforme Publik) permettant d'échanger @code@ contre un @access_token@ ; l'access token est un jeton qui permettra d'appeler le web-service fournissant les informations sur l'utilisateur. Le web-service @token@ fournit aussi le *@sub@* ou identifiant unique de l'utilisateur, c'est cet identifiant qui sert de clé à la liaison entre Publik et le portail-métier. Enfin, le web-service @token@ fournit deux valeurs *@iss@* (identifiant de l'émetteur) et *@sid@* (identifiant de la session) qui doivent être enregistrés dans la session créée sur le portail métier, en vue d'assurer la mécanique de déconnexion (voir plus bas). 5.3. *appeler le web-service @user-info@* (@IDP_URL/idp/oidc/user_info/@) pour obtenir les attributs de l'utilisateur qui lui sont autorisés. 5.4. déterminer si le @sub@ est connu ** si le @sub@ est connu, il connecte l'usager à son compte ou un de ses comptes (voir plus haut) ** si le @sub@ est inconnu, il doit lancer un processus d'appairage ou de création de compte, nécessitant des interaction ou pas avec l'utilisateur (cette partie est entièrement à la charge de l'éditeur métier) h3. Description technique non-exhaustive de la déconnexion unique La déconnexion pourra avoir lieu : * sur la plateforme Publik, et dans ce cas le portail métier en sera notifié si un SSO a eu lieu vers lui durant la session courante en suivant la spécification "frontchannel logout" * sur le portail métier, et dans ce cas il DOIT le notifier à la plateforme Publik en suivant la spécification "RP initiated logout" h4. SLO initié par Publik (Frontchannel Logout) Voir http://openid.net/specs/openid-connect-frontchannel-1_0.html#RPLogout La plateforme Publik procédera à une re-direction sur l'URL @frontchannel_logout_uri@ via une @iframe@ invisible, le portail métier devra procéder à la déconnexion de la session en cours sur toute requête à cette URL et faire en sorte qu'elle ne puisse jamais être mise en cache par le navigateur. Deux paramètres sont envoyés dans la query-string de l'URL @frontchannel_logout_uri@ : @iss@ et @sid@. Ce sont ceux qui ont été reçus lors de l'appel au web-service token au début de la création de la session (voir plus haut). Ces deux paramètres permettent de retrouver la session en jeu sur le portail métier, et de la détruire afin d'assurer la déconnexion. Note : il convient de régler les entêtes de sécurité de l'URL pour que celle-ci soit utilisable dans une @iframe@. Notamment il ne faut pas renvoyer d'entête de restriction @X-Frame-Options@, ni de limitation via @Content-Security-Policy@. h4. SLO inité par le portail métier (RP initiated Logout) Voir https://openid.net/specs/openid-connect-rpinitiated-1_0.html Le portail-métier devra rediriger le navigateur de l'utilisateur sur l'URL @IDP_URL/idp/oidc/logout/@, il pourra passer une URL de retour via le paramètre @post_logout_redirect_uri@. Cette URL devra être préalablement déclarée auprès de l'administrateur Publik. h2. Remontée d'information Publik propose un point d'entrée unique pour la gestion de la relation usager, à ce titre il est important que Publik puisse centraliser toutes les informations importantes des portails métiers tiers. Pour cela nous proposons la possibilité d'appeler des web-services portés par les portails métiers en vue d'afficher des informations dans les pages du portail citoyen de Publik. h3. Pré-requis * tous les web-services devront être servis via HTTPS:// et une authentification HTTP Basic * tous les web-services devront échanger en utilisant le format JSON en entrée (POST) et en sortie * en sortie toutes les réponses des web-services devront suivre le formalisme suivant : ** dans le cas passant :
{
"err": 0,
"data": {}
}
{
"err": "code-erreur-xxx",
"err_desc": "",
}
GET /api/demandes/?sub=xxx
{
"err": 0,
"data": [
{
"datetime": "2018-03-04 12:34:32",
"name": "Demande de carte de stationnement",
"status": "En attente d'information",
"form_number": "1234",
"form_status_is_endpoint": false,
"url": "https://portail-metier/demandes/1234/",
"draft": false
}
]
}
GET /api/invoices/?sub=xxx
{
"err": 0,
"data": [
{
"id": "939456",
"label": "restauration août 2015",
"amount": "37.26",
"total_amount": "37.26",
"created": "2015-08-01",
"pay_limit_date": "2015-09-29",
"paid": false,
"no_online_payment_reason": "litigation",
"payment_url": "https://portail-metier/factures/934395/pay/",
"pdf_url": "https//portail-metier/factures/934395/pdf/F20180192.pdf",
... (autres informations si le logiciel backend en donne)
},
]
}
{ "type": "block", "label": "Mes informations familles", "content": [...], "edit_url": "https://portail-metier/ma-famille/", }| Type | Description | | @block@ | un bloc composé d'autres éléments, permet de grouper | | @text@ | un paragraphe, peut contenir un texte simple, pré-formaté ou formaté en HTML, en utilisant uniquement les balises autorisés dans un noeuddu HTML (balises inline, @@, @@, @@), ainsi qu'un lien d'édition (pictogramme stylo dans le coin haut-droit du contenu) | | @table@ | un tableau, contenant des lignes qui contiennent soit des entête @header@ soit des cellules de contenu @text@ | Tous les types acceptent les attributs suivants : * @label@ qui ajoutera un titre avec le bon niveau d'imbrication avant le contenu, * @id@ et @class@ (respectivement une chaîne et une liste de chaînes) permettant de donner des valeurs pour les attributs HTML correspondant, simplifiant l'application d'une feuille de style. Exemple de présentation d'un profil famille venant d'un portail famille :
Le but de ce formalisme est de laisser à la fois un peu de liberté au portail métier sur les contenus et aussi la liberté pour Publik d'appliquer des feuilles de style aux contenus. Coté Publik, ces contenus seront présentés via des cellules JSON (cellule associant un web-service JSON avec un template). fn1. technologie équivalente https://github.com/portabletext/portabletext h3. Dépôt d'une demande Voir https://doc-publik.entrouvert.com/dev/echanges-logiciel-de-demandes-metier/ en sachant que l'information « sub » peut être envoyée dans la demande si elle doit être reliée à un compte dans le logiciel cible.{ "err": 0, "data": { "type": "block", "label": "Ma famille", "edit_url": "https://portail-famille/ma-famille/edit/", "content": [ { "type": "text", "id": "adresse", "label": "Adresse", "pre": true, "content": "1 rue du calvaire\nXX100 MAVILLE" }, { "type": "text", "id": "parent1", "class": "parent", "label": "Premier parent", "html": true, "content": "Jean-Michel DUPOND, né le 12 décembre 1964 à Marseille", }, { "type": "text", "id": "parent2", "class": "parent", "label": "Second parent", "html": true, "content": "Régine DUPOND, né MARTIN le 12 décembre 1964 à Lyon" } { "type": "block", "label": "Enfants", "content": [ { "type": "text", "content": "Kévin DUPOND, 5 ans, né le 22 mars 2013", } ] } ] } }