Création automatique d'un utilisateur depuis un appel API

Support
Tags: #<Tag:0x00007f491538af08>
#1

Bonjour
Notre instance Simplicité est paramétrée pour se connecter via un idp. Cela crée automatiquement un utilisateur et lui affecte un droit en lecture.
Nous souhaiterions étendre cet comportement aux appels API.
Notre instance expose plusieurs API via APIGEE.
Toutes personnes connues de l’IDP peut requêter les api apigee. Nous souhaiterions que lorsque l’appel arrive sur l’instance, cela créé aussi automatiquement un utilisateur.
Nous comptions surcharger le hook preAuth, est-ce la bonne solution ?

Cordialement
Amandine T.

[Platform]
Status=OK
Version=4.0.P24
BuiltOn=2020-10-14 23:22 (revision 3c63448f648587d9a89ec04d597946d26e4f7937)
Encoding=UTF-8
EndpointIP=21.1.32.165
EndpointURL=http://b161d38d38e4:8080
TimeZone=Europe/Paris
SystemDate=2021-01-13 11:06:05

#2

Dans quel hook avez vous implémenté votre création d’utilisateur dans le cas de la UI ?

#3

Bonjour David,
il me semble que c’est codé historiquement dans ce que tu as mis en place en 2017 lors de l’intégration de notre IDP…

#4

Oui mais je ne me rappelle pas ce qui avait été fait à l’époque… Envoie moi le contenu complet du GrantHooks(ou PlatformHooks en v5) en message privé si besoin.

Je voudrais comprendre pourquoi la logique mise en place pour la UI ne s’applique pas aux appels API

#5

Il n’y a rien concernant la création de User dans notre GrantHook (par contre on y a implémenté le preLoadResponsiblity pour ajouter à la volée des responsabilités au User fraichement créé par le login/UI).

#6

OK c’est donc sans doute le sync: true dans la config de l’authentification qui créé l’utilisateur à la volée. Tu confirmes qu’il y a bien ce paramètre ?

#7

Une question => est-il impératif de créer cet utilisateur sur appel API ou est-ce qu’une “substitution” du user (après authent) pour un user technique dédié API ne ferait pas l’affaire ?

Je pose la question vis à vis de la charge induite par une multiplication des grants/objets APIs. De mémoire vous ne faites que de la consultation via API, donc connaitre le “vrai” utilisateur n’est pas forcément nécessaire puisque les appels en consultation ne laissent pas de traces et qu’il n’y a à priori pas de filtrages liés à l’utilisateur

#8

En effet, dans la plupart des cas il ne sera pas nécessaire de tracer nominativement l’accès dans le cas des GET (accès simples en lecture seule) -> la solution consistant à substituer l’appelant par un user technique dédié est très intéressante.

Néanmoins, d’autres usecases nécessiteront des habilitations spécifiquement octroyées à certains user identifiés -> dans ce cas, soit leur profil est déjà initialisé soit on le crée (ce contexte précis d’appel devra être spécifié avec l’appelant dans le cadre d’un processus défini).

Il suffirait ensuite de procéder à cette substitution si et seulement si l’appelant n’a pas de compte…

#9

OK je vais regarder comment procéder au mieux à cette “substitution” (et uniquement si le user n’est pas déjà dument déclaré).

Sinon tu confirmes que la config de l’authent via votre IdP a bien sync: true ?