Intégration Scenari server 6.1.9 - Docker Kubernetes

Applications génériques SCENARIserver
1

Bonjour,

J’intègre Scenari server dans un cluster kubernetes à partir de la dernière image docker.

Je rencontre des difficultés pour connecter l’application à notre LDAP :
env:
- name: SC_LDAP_ENABLED
value: « true »
- name: SC_LDAP_URL
value: {{ .Values.ldap.host }}
- name: SC_LDAP_BASENAME
value: {{ .Values.ldap.base_dn }}
- name: SC_LDAP_SEARCH
value: « uid={0} »
- name: SC_LDAP_SEARCH_ACCOUNT_LOGIN
value: {{ .Values.ldap.bind_username }}
- name: SC_LDAP_SEARCH_ACCOUNT_PASSWORD
value: {{ .Values.ldap.bind_password }}

Est-il possible d’avoir des logs plus verbeux pour les connexions LDAP ?

Je ne retrouve pas le user.properties et autres fichiers de configuration dans le conteneur/pod.
Comment l’image est-elle construite ? Ce dépôt source contenant le Dockerfile est-il public ?

Merci beaucoup

Cordialement

Matthieu G.

2

Bonjour,

Les infos pour les sources ou emplacement des logs sont dans « overview » Docker.

Cordialement,

3

Bonjour,

Nous avons ajouté une possibilité d’avoir des logs plus verbeux et mieux comprendre les interactions avec LDAP, mais ce sera avec la prochaine version 6.2 dont la sortie est prévue d’ici quelques semaines.

Par exemple, chez nous, l’activation de ce log donne (peut-être que cela vous donnera des pistes pour comprendre le problème dans votre contexte) :

LDAP-checkUserBySearch
java.naming.provider.url: ldaps://xxxx.yyy.fr
java.naming.security.authentication: simple
java.naming.security.credentialsSearch: (&(objectClass=shadowAccount)(|(uid=sys)(mail=sys))) (with scope: SUBTREE)

=> dn user found
Check password for this user:
java.naming.security.principal: uid=sys,ou=people,dc=kelis,dc=fr
java.naming.security.credentials: ****** 

=> auth for this dn user OK
4

Bonjour,

Après installation de la version 6.2.0 docker Scenari server et avoir appliqué la configuration LDAP ci-dessus je ne vois rien passer en log LDAP.

Avec vous une préconisation pour l’activation des logs LDAP à me fournir ? un path spécifique peut-être. Je ne retrouve pas d’information sur le sujet.

==> ./act_current.log <==
{« evt »:« svc:dialog »,« user »:« anonymous »,« cdaction »:« Login »,« svc »:« loginWeb »,« props »:{« currentPwd »:« # »,« nickOrAccount »:« mgastineau »},« result »:« accountNotFound »,« ts »:1700663589599}

La seule log d’authentification que j’ai trouvé

Merci à vous

Matthieu G.

5

Bonjour,

Pour activer cette trace au serveur, envoyer la requête POST {SC_PUBLIC_URL}/~~chain/web/u/adminServer/UpdateTraces?param=(enable 'eu.scenari.core.user.remote.LdapAuth') où {SC_PUBLIC_URL} est l’url que vous avez configurée pour docker, par exemple : SC_PUBLIC_URL=http://127.0.0.1:8080/scchainsrv62.

Pour désactiver ensuite ce log : POST {SC_PUBLIC_URL}/~~chain/web/u/adminServer/UpdateTraces?param=(disable 'eu.scenari.core.user.remote.LdapAuth')

Note : pour envoyer une requête POST, vous pouvez utiliser un utilitaire comme curl en précisant votre authentification Basic.

PS: la 6.2.1 est sortie ce matin :wink:

6

Bonjour,

De mémoire, une anomalie de connexion LDAP devrait remonter une erreur sans nécessité d’activer des traces de log.

Votre erreur semble être en amont : le compte « mgastineau » ne semble pas avoir déclaré dans votre SCENARIserver.

Note : en l’état, un compte « LDAP » signifie que son mot de passe est géré / validé par le système LDAP fournisseur d’identité… mais il n’y a pas d’auto-création de comptes LDAP sur le SCENARIserver

Cdt

Antoine

7

Merci pour les informations. Je vois que nous pouvons interagir en REST.
Savez-vous s’il existe une documentation sur les actions possibles en API (ajout/update/delete user-atelier-habilitation …) ?

8

Effectivement, je n’avais pas le use case en tête.
Plus largement, une documentation existe sur le fonctionnement du back-office (habilitations, ldap, API …)

Merci pour vos réponses

9

Bonjour @Gastineau ,

Des fragments de documentation existent sur ces différents services dans le code Java, mais il n’y a rien de formalisé ni d’exaustif sur ces points d’entrée API développeur.

Néanmoins, pour ces fonctions de base, observer par rétro-ingénierie les requêtes produites par l’interface et les réponses obtenues est généralement un point d’entrée très efficace.

Antoine
Kelis

10
  • Comme le dit Antoine, le plus simple est de regarder les requêtes et réponses REST à partir des devTools du navigateur.
  • Il faut comprendre que chaque solution serveur Scenari configurée dans SCENARIbuilder propose sa propre API, bien sûr avec de nombreux points communs, mais des variations aussi…
  • Pour des enjeux d’évolutivité, nous ne voulons pas nous engager sur la compatibilité ascendante de cette « API » REST. Ce n’est donc pas, de mon point de vue, une « API » ! Oui c’est un point de désaccord que j’ai avec de nombreux développeurs… Pour moi, si on publie une API, on s’engage au maximum à la maintenir dans le temps, au delà de chaque version.

Pour remédier à ce problème nous prévoyons de mettre à disposition une vraie « API » documentée dans le langage Python qui a vocation à :

  • garantir une bien meilleure compatibilité ascendante que la couche REST,
  • simplifier certains appels qui exigent un enchainement de plusieurs requêtes REST (générations et jobs asynchrones…),
  • abstraire les variations potentielles de la couche REST entre les différentes solutions serveurs compilées avec SCENARIbuilder.

Mais je ne peux actuellement pas fournir de date pour cette nouvelle API Python.

1 « J'aime »