Embedded Files
Première analyse de la version FIT complète
Première analyse de la version FIT complète
Le projet fit permet de construire 2 déploiements différents de Syncope. Dans Test Bed j'ai évoqué la partie Docker. Mais afin de trouver des exemples concrets de configuration il faut passer par la version complète. En effet c'est la seul qui arrive avec des connecteurs et les scripts Groovy / Java qui configurent les connecteurs évolués.
La démarche est très simple deux commandes maven suffisent pour lancer le serveur applicatif, cependant au lancement j'ai une exception mais qui ne touche pas la totalité de l'instance (en fait le port 8080 est bloqé par un NAT):
[ERROR] Async process failed for: [C:\Program Files\java\jdk-25.0.1\bin\java, -Djavax.net.ssl.trustStore=C:\Users\steph\Documents\NetBeansProjects\syncope\iam\fit/src/test/resources/keystore.jks, -Djavax.net.ssl.trustStorePassword=password, -Dreactor.netty.http.server.accessLogEnabled=true, -Dsyncope.log.dir=C:\Users\steph\Documents\NetBeansProjects\syncope\iam\fit\target/log, -jar, C:\Users\steph\Documents\NetBeansProjects\syncope\iam\fit/../sra/target/syncope-sra-exec.jar]org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1) at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:394) at org.apache.commons.exec.DefaultExecutor.lambda$execute$0 (DefaultExecutor.java:308) at java.lang.Thread.run (Thread.java:1474)Après un peux de temps l'instance est disponible:
[INFO] Press Ctrl-C to stop the container...
Une des différences c'est que tous les services sont derrières un seul port, sauf SRA (Secure Remote Access) qui lui ne semble pas actif, comme le montre le composant KeyMaster.
Mais ce qui me surprend dans la Topology c'est un serveur de connexion.
Dans l'image on voit que depuis la racine Syncope, 2 nœuds sont attachés, celui qui comment par file:// est aussi disponible dans le déploiement docker, mais celui du dessus connid est nouveau.
Dans les débuts des projets IAM il y a souvent eu la séparation technologique entre le gestion d'identité d'accès et le provisioning. Je vais creuser ce service pour le réintégrer dans mon Test Bed.
Dans le git de Syncope on trouve pour le projet FIT la classe qui lance tous les Beans supplémentaires, en particulier les ressources mais aussi notre agent de provisioning:
@Override public void onStartup(final ServletContext sc) throws ServletException { sc.addListener(new ConnectorServerStartStopListener()); sc.addListener(new LDAPStartStopListener()); sc.addListener(new H2StartStopListener()); sc.addListener(new GreenMailStartStopListener()); sc.addListener(new KafkaBrokerStartStopListener());ServletRegistration.Dynamic sts = sc.addServlet("ServiceTimeoutServlet", ServiceTimeoutServlet.class); sts.addMapping("/services/*");
super.onStartup(sc); }
Cette classe ConnectorServerStartStopListener est ce qu'il me faut extraire et ajouter à mon Test Bed, puis le déclarer dans ma configuration.
Pour faire cela, j'ai copié cette classe dans un projet Spring Boot que j'avais pour un service REST d'identité. Cette classe se déclare elle-même comme un service web d'écoute et expose des connecteurs que l'on ajoute comme des ressources (bundles). Il faut ajouter un argument pour permettre l'utilisation de la réflexion entre deux modules, on ajoute cela dans le plugin maven spring boot:
<configuration> <jvmArguments>--add-opens java.base/java.lang=ALL-UNNAMED</jvmArguments> </configuration>Et maintenant comment déclarer ce service et pour qui ? Le CORE et / ou la Console ?
Pour la déclaration il existe visiblement une propriété que l'on trouve dans un des fichiers de configuration de FIT:
provisioning.connIdLocation=${syncope.connid.location},\connid://${testconnectorserver.key}@localhost:${testconnectorserver.port}
Donc cette propriété devra se trouver dans celles du CORE avec pour ${testconnectorserver.key} une clé secrète, par exemple "connecteurs" derrière le @ on mettra l'alias du container et au final le port ${testconnectorserver.port} celui configurer pour dans la classe, soit
provisioning.connIdLocation=${syncope.connid.location},\connid://connecteurs@connidsrv:8759
Pour obtenir cela dans mon Test Bed j'ai modifier dans le fichier de ressource du module Core core.properties et procéder à la recompilation des modules et ensuite le déploiement sur docker
Mais il faut maintenant que le serveur connid expose les jars / bundle.
En fait il existe une version déployable du serveur de connexion, ce qui simplifie la tâche de trouver les bonnes versions des packages à mettre ensemble.
Donc dans mon Test Bed j'ai ajouté un nouveau container qui est basé sur le serveur de connexion, j'ai modifié le fichier pom.xml du projet FIT pour l'ajouter. Le Dockerfile en question:
FROM eclipse-temurin:21WORKDIR /appRUN mkdir bin bundles conf libCOPY bin/ /app/binCOPY bundles /app/bundlesCOPY conf /app/confCOPY lib /app/libEXPOSE 8759ENTRYPOINT ["/app/bin/ConnectorServer.sh", "-run", "-properties", "/app/conf/connectorserver.properties"]
On ajoute un connecteur au serveur à partir de la liste des bundles que l'on à préalablement chargé dans l'image. On trouve ces fichiers jar dans le repo suivant. Dans mon cas un connecteur REST en vue de charger des identités.
Mais c'est un connecteur qui doit prendre des scripts groovy pour traiter les opérations unitaires. Et là c'est le drame :-(
D'abord c'est une galère pour comprendre comment copier ces fichiers depuis le projet core dans le container et ensuite une fois sur le fileSystem il est impossible de les lire.
java.lang.IllegalArgumentException: Can't read /tmp/SearchScriptRest.groovy at net.tirasa.connid.commons.scripted.AbstractScriptedConfiguration.checkFileIsReadable(AbstractScriptedConfiguration.java:389) at net.tirasa.connid.commons.scripted.AbstractScriptedConfiguration.validate(AbstractScriptedConfiguration.java:360) at net.tirasa.connid.bundles.rest.RESTConfiguration.validate(RESTConfiguration.java:149) at org.identityconnectors.framework.impl.api.local.operations.ValidateImpl.validate(ValidateImpl.java:40)
Alors que le fichier est effectivement avec le bon niveau de permission:
9679ccfa2462:/tmp$ ls -ls SearchScriptRest.groovy4 -rw-r--r-- 1 syncope syncope 3395 Nov 24 16:47 SearchScriptRest.groovyQuand on regarde le source de méthode checkFileIsReadable, on voit l'utilisation d'une méthode java qui bloque mais pourquoi ?
private void checkFileIsReadable(final String type, final String fileName) { if (fileName == null) { LOG.ok("{0} Script Filename is null", type); } else { Path file = Path.of(AbstractScriptedConnector.resolveVariables(fileName)); try { if (Files.isReadable(file)) { LOG.ok("{0} is readable", fileName); } else { throw new IllegalArgumentException("Can't read " + fileName); } } catch (SecurityException e) { throw new IllegalArgumentException("Can't read " + fileName, e); } } }Là, moi, j'abandonne 😮💨
Page updated
Report abuse