Merci d'avoir répondu si rapidement et merci pour ton aide !
Mais encore? Plus précisément qui échange avec qui?
J'aurais dû donner plus de détails désolé.
La on réfléchit en terme d'applications qui discutent à travers une architecture fédérée (ni centralisée, ni pair à pair). On voudrait garder le même avantage que XMPP : ne pas avoir à configurer quoi que ce soit pour que les applications puissent discuter entre elles. Et c'est le cas avec notre POC puisque nos applications utilisent le protocole XMPP.
On sort le cas de l'IoT et de l'acquisition de données de l'équation pour le moment (mais on garde ça dans un coin de notre tête).
Scénario complexe (car tripartite) :
- l'appli A possède des données de courbes de charges d'énergie.
- l'utilisateur final a un compte sur une appli C qui permet d'afficher de jolies courbes sur une GUI WEB
- l'appli C utilise une appli B pour récolter les données de l'appli A, les stocker et les traiter (ex : fournir à la demande des jeux de données minimaux à l'appli C pour afficher un graphe entre telle date et telle date, autre exemple : envoyer une alerte à l'appli B quand il n'y a plus du tout de consommation électrique dans un cas de coupure de disjoncteur différentiel par exemple)
Un scénario plus simple serait que l'appli C fasse le boulot de l'appli B elle même, et ce sera possible techniquement. Mais on ne s'empêche pas d'avoir des relations multiple. L'idée finale est de pouvoir faire en sorte qu'une appli ait accès à N jeux de données de N applications ET d'avoir un chaînage avec N applications pour pouvoir créer ou répondre à de nouveaux usages avec des données multiples.
Un exemple concret du POC est expliqué p10 du rapport de conclusion du POC (voir : rapport_conclusion.pdf). La figure 1 représente des échanges entre applications. Les applications n'ayant pas été prévus pour se "brancher" directement en fédération, nous avons ajouté des composants d'interface que l'on a appelé "proxy de données"
Quel est l'impact du RGPD dans ton cas?
Nous avons fait une étude non experte sur le RGPD appliqué au cadre d'une architecture fédérée. Voir : Rapport-RGPD.pdf. Ce qu'il en ressort c'est que l'on a tout intérêt à prévoir des mécanismes les plus automatisés possibles pour aider les applications à être en conformité (voir les encadrés "recommandations" dans le rapport). Ce que l'on a vu également c'est que le lien contractuel (ou non) joue beaucoup sur les responsabilités entre applications qui échangent des données. Un appli (et donc un organisme) peut être considérée comme co-traitante, sous-traitante ou indépendante. Nous allons contacter la CNIL et/ou le Pôle d'excellence cyber de Bretagne pour avoir des éclaircissements sur le sujet.
Chaque application est connue du serveur OAuth2 par un identifiant/mot de passe.
Du coup, ce paradigme n'est pas souhaitable. Le besoin c'est de faire de l'autorisation avec un serveur "que l'on ne connaît pas encore". Le but étant que les utilisateurs donnent leur consentement pour tout échange/traitement de données. Dans le scénario complexe exposé ci-dessus, l'utilisateur donne son consentement dans l'appli C (GUI WEB) pour que cette dernière traite/affiche ses données. Puis on imagine que l'appli C va utiliser Oauth2 ou OIDC avec l'appli A (source des données). Mais après, l'appli B doit avoir le consentement de l'utilisateur pour aller chercher les données de l'appli A... Et tout ça sans configuration préalable (sauf à avoir une sorte de catalogue central, chose que l'on aimerait éviter car on ne veut pas ajouter une composante centralisée...). Et c'est là que je ne vois pas comment y arriver.
Nous avons regardé oAuth2 et nous avons implémenté la partie "client" pour récupérer des données auprès d'une application du type A justement :-) Et je pense que je vais devoir potasser sérieusement avant d'aller plus loin. Tu aurais des documentations à me conseiller ou c'est préférable que j'aille voir directement aux sources :
- https://openid.net/connect/
- https://tools.ietf.org/html/rfc6749
[^] # Re: SSO et autorisation en mode fédéré : possible ?
Posté par ghusson (site web personnel) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 1.
Merci d'avoir répondu si rapidement et merci pour ton aide !
J'aurais dû donner plus de détails désolé.
La on réfléchit en terme d'applications qui discutent à travers une architecture fédérée (ni centralisée, ni pair à pair). On voudrait garder le même avantage que XMPP : ne pas avoir à configurer quoi que ce soit pour que les applications puissent discuter entre elles. Et c'est le cas avec notre POC puisque nos applications utilisent le protocole XMPP.
On sort le cas de l'IoT et de l'acquisition de données de l'équation pour le moment (mais on garde ça dans un coin de notre tête).
Scénario complexe (car tripartite) :
- l'appli A possède des données de courbes de charges d'énergie.
- l'utilisateur final a un compte sur une appli C qui permet d'afficher de jolies courbes sur une GUI WEB
- l'appli C utilise une appli B pour récolter les données de l'appli A, les stocker et les traiter (ex : fournir à la demande des jeux de données minimaux à l'appli C pour afficher un graphe entre telle date et telle date, autre exemple : envoyer une alerte à l'appli B quand il n'y a plus du tout de consommation électrique dans un cas de coupure de disjoncteur différentiel par exemple)
Un scénario plus simple serait que l'appli C fasse le boulot de l'appli B elle même, et ce sera possible techniquement. Mais on ne s'empêche pas d'avoir des relations multiple. L'idée finale est de pouvoir faire en sorte qu'une appli ait accès à N jeux de données de N applications ET d'avoir un chaînage avec N applications pour pouvoir créer ou répondre à de nouveaux usages avec des données multiples.
Un exemple concret du POC est expliqué p10 du rapport de conclusion du POC (voir : rapport_conclusion.pdf). La figure 1 représente des échanges entre applications. Les applications n'ayant pas été prévus pour se "brancher" directement en fédération, nous avons ajouté des composants d'interface que l'on a appelé "proxy de données"
Nous avons fait une étude non experte sur le RGPD appliqué au cadre d'une architecture fédérée. Voir : Rapport-RGPD.pdf. Ce qu'il en ressort c'est que l'on a tout intérêt à prévoir des mécanismes les plus automatisés possibles pour aider les applications à être en conformité (voir les encadrés "recommandations" dans le rapport). Ce que l'on a vu également c'est que le lien contractuel (ou non) joue beaucoup sur les responsabilités entre applications qui échangent des données. Un appli (et donc un organisme) peut être considérée comme co-traitante, sous-traitante ou indépendante. Nous allons contacter la CNIL et/ou le Pôle d'excellence cyber de Bretagne pour avoir des éclaircissements sur le sujet.
Du coup, ce paradigme n'est pas souhaitable. Le besoin c'est de faire de l'autorisation avec un serveur "que l'on ne connaît pas encore". Le but étant que les utilisateurs donnent leur consentement pour tout échange/traitement de données. Dans le scénario complexe exposé ci-dessus, l'utilisateur donne son consentement dans l'appli C (GUI WEB) pour que cette dernière traite/affiche ses données. Puis on imagine que l'appli C va utiliser Oauth2 ou OIDC avec l'appli A (source des données). Mais après, l'appli B doit avoir le consentement de l'utilisateur pour aller chercher les données de l'appli A... Et tout ça sans configuration préalable (sauf à avoir une sorte de catalogue central, chose que l'on aimerait éviter car on ne veut pas ajouter une composante centralisée...). Et c'est là que je ne vois pas comment y arriver.
Nous avons regardé oAuth2 et nous avons implémenté la partie "client" pour récupérer des données auprès d'une application du type A justement :-) Et je pense que je vais devoir potasser sérieusement avant d'aller plus loin. Tu aurais des documentations à me conseiller ou c'est préférable que j'aille voir directement aux sources :
- https://openid.net/connect/
- https://tools.ietf.org/html/rfc6749
PS : j'ai déterré ça : https://linuxfr.org/news/authentifiez-vous-sans-mot-de-passe-grace-a-xmpp, ça va peut être m'intéresser pour les authentifications entre applis...