Bienvenue
AGATA CONSENT est un Système de Gestion de Consentement décentralisé bâti sur une Blockchain qui s’inscrit dans un contexte de pluralité d’acteurs qui sont à la fois partenaires et (parfois) concurrents.
L’intégralité de l’architecture est pensée autour de la sécurité, la scalabilité et la résilience.
La plateforme AGATA CONSENT permet de résoudre de manière simple et fiable l'épineux sujet du recueil et de la fiabilisation du consentement au partage des données entre entreprises. La plateforme peut s'interfacer à tout système d'échange de données chez vous.
Avec AGATA CONSENT, vous avez la possibilité d'envoyer des demandes de consentement à vos clients. Une fois signées, celles ci vous autorisent à exploiter un périmètre de données selon un usage précisé. Vous avez également la possibilité de vous assurer qu'un consentement existe pour un périmètre et un usage spécifique.
Lorsque cela est possible, les fonctionnalités détaillées dans ce guide sont illustrées par des références et captures d'écran du portail Entreprise AGATA CONSENT.
Pré requis à l'utilisation du Système de Gestion de Consentements
Avec AGATA CONSENT, les données sont organisées par Domaines fonctionnels.
Toute entreprise qui distribue des données et souhaitant s'assurer de la présence des consentements avant de distribuer les données aux Bénéficiaires doit contractualiser avec :
- FAST pour acquérir une licence AGATA CONSENT Gestionnaire afin de créer son Domaine ;
- Tout Bénéficiaire souhaitant exploiter les données distribuées par le Gestionnaire.
Parallèlement, une entreprise bénéficiaire souhaitant valoriser les données d'un Domaine existant sur AGATA CONSENT doit contractualiser avec :
- le Gestionnaire du Domaine désiré selon les conditions spécifiques définies par celui-cî ;
- FAST pour acquérir une licence Bénéficiaire.
Une entreprise souhaitant uniquement signer une demande de consentement lui étant adressée doit créer un compte sur AGRI MAKER. Aucun achat de licence n'est nécessaire.
Environnements
Recette
Espace PRO : https://espacepro-preprod.agata-consent.com
API AGATA CONSENT : https://api-preprod.agata-consent.com
URL Hooks : https://sign-preprod.agata-consent.com
URL d’authentification : https://account-preprod.agata-consent.com
Documentation Swagger : https://api-preprod.agata-consent.com
Production
Espace PRO : https://espacepro.agata-consent.com
API AGATA CONSENT : https://api.agata-consent.com
URL Hooks : https://sign.agata-consent.com
URL d’authentification : https://account.agata-consent.com
Documentation AGATA CONSENT : https://doc.agata-consent.com/index.html
Documentation Swagger : https://api.agata-consent.com
Authentification
L'url d'authentification d'AGATA CONSENT est :
Mode d’authentification
Les API AGATA CONSENT utilisent le protocole OIDC, basé sur le protocole Oauth2.
OAuth2 permet d’autoriser une application (un Client) à utiliser l’API d’une autre application (Resource Server) pour le compte d’un utilisateur (Resource Owner).
En plus des mécanismes OAuth2, OIDC permet à un Client, de demander des informations sur l’utilisateur « connecté » (son adresse, ses droits …).
Pour les URLs, se référer à la partie Environnements
Précision selon les versions d'API
Les informations d’authentification varient selon l’API utilisée :
-
agata-consent, agata-consent-cne, agata-consent-router : L'authentification s’effectue via un client public en utilisant un
client_id, unusernameet unpassword. Le type de grant utilisé est :password. -
agata-consent-hooks : L'authentification repose sur un client applicatif utilisant un
client_idet unclient_secret. Le type de grant utilisé est :client_credentials.
Note sur Swagger : Le
client_idaffiché par défaut dans Swagger est automatiquement prérempli en fonction de l’environnement (préprod, prod) pour les API agata-consent, agata-consent-cne et agata-consent-router. Vous n’avez pas besoin de le modifier : la valeur renseignée est déjà correcte.En revanche, pour l’API agata-consent-hooks, veillez à remplacer manuellement le
client_idpar celui de votre application.
Client public
Ce client peut s’authentifier en utilisant un identifiant et un mot de passe lui permettant de récupérer un jeton (token) qu’il utilisera par la suite dans l’en-tête (Header) de ses requêtes HTTP.
Le type de Grant utilisé est « password ».
curl --location --request POST 'https://account.agata-consent.com/auth/realms/sgc/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Cookie: KEYCLOAK_LOCALE=fr' \
--data-urlencode 'client_id=<client id>' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'username=<user>' \
--data-urlencode 'password=<password>'
Client applicatif
Ce client peut s’authentifier en utilisant le type de grant « client_credentials » associé à un client_id et un secret.
curl --location --request POST 'https://account.agata-consent.com/auth/realms/sgc/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Cookie: KEYCLOAK_LOCALE=fr' \
--data-urlencode 'client_id=<client id>' \
--data-urlencode 'client_secret=<client secret>' \
--data-urlencode 'grant_type=client_credentials'
Liste des erreurs remontées par les API
Nos API renvoient les codes d'état HTTP standard (succès ou erreur). Les principaux codes d'état HTTP pouvant être renvoyés sont :
| Code HTTP | Réponse | Description |
|---|---|---|
| 200 | OK | Succès |
| 201 | Created | Ressource a été créée avec succès |
| 204 | No content | Requête traitée avec succès, mais pas d’information à renvoyer |
| 400 | Bad request | Syntaxe de la requête invalide |
| 401 | Unauthorized | Authentification absente ou invalide |
| 403 | Forbidden | Droits de l'utilisateur insuffisants |
| 404 | Not Found | La ressource est introuvable |
| 409 | Conflict | La ressource est déjà connue |
| 50X | Internal Server Error | Une erreur est survenue |