Aller au contenu

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 :

https://keycloak.agata-consent.com

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, un username et un password.
    Le type de grant utilisé est : password.

  • agata-consent-hooks :
    L'authentification repose sur un client applicatif utilisant un client_id et un client_secret.
    Le type de grant utilisé est : client_credentials.

Note sur Swagger :
Le client_id affiché 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_id par 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://keycloak.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://keycloak.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