Portail, manager et handlers
Documenter le rôle, l’exposition, la configuration et les dépendances de chaque composant au lieu de traiter le WebSSO comme un bloc.
API
Intégrateur LemonLDAP::NG : relier vos applications au SSO
Dawap raccorde LemonLDAP::NG à vos annuaires, applications historiques et services modernes. Nous adaptons les connexions, configurons les règles d’accès et organisons la migration avec votre DSI. Chaque application est testée pour les accès autorisés, les refus et la fermeture des sessions.
Premier lot LemonLDAP::NG
Raccorder une application représentative, puis préparer la migration.
Le pilote choisit une application représentative, un annuaire, deux profils et une action sensible. Il suit l’authentification, la création de session, l’évaluation de la règle, l’injection ou l’échange des attributs, puis la fermeture d’accès après retrait du groupe.
Applications
Annuaire
Règles d’accès
Migration
À l’issue du cadrage
- Inventorier domaines SSO, virtual hosts, portal, manager, handlers, backends d’authentification et de données, sessions et personnalisations.
- Choisir un mode d’intégration par application : handler et headers, CAS, SAML, OIDC, rejeu ou adaptation bornée.
- Attribuer un propriétaire à chaque identifiant, groupe, attribut exporté, macro, règle et durée de session.
- Tester contournement du handler, header forgé, règle modifiée, session persistante, backend indisponible, logout partiel et rollback.
Réponse courte
Une intégration LemonLDAP::NG protège chaque application selon ses capacités réelles.
L’intégrateur cartographie portail, manager, handlers, domaines, virtual hosts, annuaires, règles et sessions ; choisit headers, CAS, SAML ou OIDC pour chaque application ; puis vérifie qu’aucun accès ne contourne le handler et qu’un droit retiré cesse réellement d’agir.
- Ne jamais accepter directement un header d’identité sur un chemin accessible sans le handler de confiance.
- Distinguer authentification, variables de session, règle d’accès et attributs transmis à l’application.
- Migrer application par application avec critères de sortie et rollback, sans bascule générale fondée sur le seul login.
3 briques
portail pour authentifier, handler pour protéger et manager pour administrer la configuration
4 modes
headers contrôlés, CAS, SAML ou OIDC choisis application par application
Identité
source des comptes et des attributs identifiée
Contrôles
accès autorisés, refus et fermeture des sessions testés
Architecture LemonLDAP::NG
Les composants et règles à vérifier pour raccorder vos applications
Nous vérifions comment l’utilisateur est identifié, quelle règle autorise son accès et quelles informations l’application reçoit. Les modifications sont documentées et testées avec vos responsables applicatifs.
Domaines et virtual hosts
Relier host, domaine SSO, chemin, règle par défaut, exceptions et chaîne proxy réellement traversée.
Backends et identité
Séparer authentification, base utilisateur, mot de passe et attributs, puis nommer la source faisant foi.
Règles et variables
Versionner macros, groupes, expressions et ordre des décisions ; rendre le refus aussi observable que l’autorisation.
Headers et protocoles
Choisir le contrat adapté : attributs HTTP minimaux pour le legacy, CAS, SAML ou OIDC pour les clients compatibles.
Sessions et exploitation
Cadrer cookies, stockage, expiration, MFA, logout, REST, logs, rotation, sauvegarde et reprise.
Parcours LemonLDAP::NG
Les parcours à prendre en compte dans votre intégration
Chaque cas suit la confiance de bout en bout : requête entrante, handler, session, règle, attribut transmis, application et effet d’un retrait de droit.
Transmettre une identité sans permettre son usurpation
Placer le handler sur l’unique chemin de confiance, supprimer les headers entrants et n’exporter que les attributs nécessaires.
Une application historique consomme une identité contrôlée sans devenir fournisseur implicite.Faire cohabiter headers, SAML et OIDC
Classer les applications par capacité, dépendance de session et criticité, puis migrer une famille avec critères de sortie.
Une migration progressive, avec des étapes et un retour arrière définis.Conserver l’identité source à travers les protocoles
Rapprocher issuer, subject, NameID ou identifiant CAS avec une clé locale durable et des attributs versionnés.
Les tests vérifient la continuité des identifiants et des droits lors du changement de protocole.Expliquer pourquoi un utilisateur passe ou reste bloqué
Corréler backend, niveau d’authentification, session, groupes, macro, règle, header et réponse applicative.
Le support dispose des éléments nécessaires pour localiser la cause d’un refus.Scénarios de recette LemonLDAP::NG
Trois situations de sécurité à tester avant la migration
Ces scénarios décrivent notre méthode de livraison, pas une référence client LemonLDAP::NG. Ils sont adaptés à votre version, votre topologie et vos modules actifs.
Le chemin direct ne peut jamais fabriquer une identité
Un appel contourne le reverse proxy ou présente déjà les headers attendus. Le test vérifie que le réseau, le handler et l’application retirent toute valeur non produite par la chaîne de confiance.
À auditer
DNS, load balancer, proxy, virtual host, handler, règle, header entrant, header exporté, port backend et journal applicatif.
Livrable
Diagramme des chemins autorisés, liste blanche des attributs exportés et recette d’usurpation automatisable.
Traces
Host, chemin, IP source, session, règle évaluée, headers supprimés, headers ajoutés et verdict applicatif.
Décision
Bloquer le go-live tant qu’un backend accepte le trafic utilisateur en dehors du handler prévu.
Le retrait de droit produit un refus mesurable
Un utilisateur perd son groupe sensible alors que son cookie SSO reste valide. La recette mesure quand la session, la règle et l’application reflètent le retrait, puis teste la procédure d’urgence.
À auditer
Annuaire, cache éventuel, variables de session, fréquence de rafraîchissement, règle, session persistante, logout et action métier.
Livrable
Contrat de fraîcheur par droit avec délai, mécanisme de fermeture, métrique, alerte et responsable.
Traces
Modification source, groupe relu, session invalidée ou régénérée, règle recalculée, accès refusé et durée totale.
Décision
Ne pas promettre une révocation immédiate si l’architecture ne sait que l’appliquer à la prochaine session.
La nouvelle session ne prolonge pas l’ancienne politique
Le client OIDC reçoit des claims pendant qu’un ancien chemin header subsiste. Les tests retirent tour à tour un attribut, changent le subject et ferment la session sur un seul canal.
À auditer
Client, redirect URIs, issuer, subject, claims, scopes, session LL::NG, session locale, logout, ancien virtual host et règles résiduelles.
Livrable
Matrice de coexistence et décision de décommissionnement avec dates, dépendances, rollback et preuves de non-usage.
Traces
Protocole emprunté, identité rapprochée, claims reçus, règle locale, session créée, logout propagé et ancien chemin sollicité.
Décision
Retirer l’accès historique seulement après disparition mesurée de ses usages et exercice réussi du retour arrière.
Livrables LemonLDAP::NG
Ce que Dawap met en place sur une intégration LemonLDAP::NG
La livraison comprend les configurations et adaptations retenues, les tests et les procédures d’exploitation. Votre DSI dispose d’une documentation pour faire évoluer les connexions et diagnostiquer les incidents.
- Inventaire de la version LemonLDAP::NG, des composants déployés et des dépendances réseau.
- Liste des applications, modes de connexion, responsables et règles d’accès.
- Correspondance des identifiants et attributs nécessaires à chaque application.
- Configuration documentée et tests des accès autorisés, des refus et des sessions.
Méthode
Valider un parcours complet avec votre DSI
Nous choisissons une application et des profils représentatifs. Nous vérifions la connexion, les droits, les refus et la fermeture des sessions, puis préparons la bascule avec un retour arrière. Les autres applications sont raccordées par étapes selon leur compatibilité et leur criticité.
Résultats attendus
- Une architecture LemonLDAP::NG lisible composant par composant.
- Un contrat d’identité minimal pour chaque application protégée.
- Des règles d’accès versionnées, testées et attribuées à un propriétaire.
- Des chemins directs fermés pour les applications fondées sur les headers.
Applications et protocoles
Choisir le mode de connexion adapté à vos applications
LemonLDAP::NG peut protéger une application par handler ou fournir des protocoles de fédération. Chaque approche déplace les responsabilités sans supprimer celles de l’application.
Des clients témoignent de nos intégrations et applications métier.
Bruno Pichot
« Nous disposons aujourd’hui d’une application robuste, performante et parfaitement intégrée. »
Mathilde Bordeaux
« Là où j’utilisais auparavant des intégrations fragiles via Zapier, ils ont mis en place de vraies intégrations directes en API, beaucoup plus fiables et performantes. »
Loic O
« Aujourd’hui, tous nos flux produits, stocks et prix sont synchronisés automatiquement : plus besoin de ressaisir les données manuellement. »
Technologies et partenaires
Nous concevons des plateformes digitales robustes à partir de technologies éprouvées. Applications métier, marketplaces, middleware et APIs sont sélectionnés pour leur fiabilité, leur performance et leur intégration dans des environnements complexes.
-
Docker
-
Symfony
-
Mysql
-
Postman
-
Swagger
-
Redis
-
Memcached
-
Algolia
-
Arch Linux
-
Ubuntu
-
Drupal
-
Magento
-
Prestashop
-
Shopify
-
Docker
-
Symfony
-
Mysql
-
Postman
-
Swagger
-
Redis
-
Memcached
-
Algolia
-
Arch Linux
-
Ubuntu
-
Drupal
-
Magento
-
Prestashop
-
Shopify
Expérience et périmètre
Une expérience des projets SSO et des applications métier
Les réalisations présentées concernent notamment Keycloak, les comptes B2B et les échanges API. Elles illustrent notre travail d’intégration ; elles ne sont pas des références LemonLDAP::NG.
Pour Branchassist, passer du SSO historique à Keycloak ne devait pas transférer aveuglément les autorisations. Dawap a séparé la connexion externe des droits internes : échange du code, contrôle de l’utilisateur actif, rôles Symfony, accès par ressource, révocation des jetons et trace des connexions. Une migration IAM ancrée dans l’application métier.
Pour Art’Sacs, activité reprise depuis par France Appro, Dawap a relié Aster et PrestaShop afin de transformer le catalogue fournisseur, synchroniser les quantités, enrichir les fiches et préparer les commandes dropshipping. Les tâches, états et erreurs donnent aux équipes un flux pilotable plutôt qu’une synchronisation opaque.
FAQ
Contacter un expert API
Questions fréquentes sur l’intégration LemonLDAP::NG API
Réponses précises sur LemonLDAP::NG, applications legacy, règles, sessions et migration SSO.
Ce qu’on clarifie dès le premier échange
- Les systèmes source et cible à connecter.
- Les flux à sécuriser, leurs volumes et leurs incidents actuels.
- Le bon mode de mission : cadrage, forfait, lots agiles, reprise, hébergement ou run.
La question à poser avant de coder
Si un flux critique décroche demain matin, qui le voit, qui décide, qui corrige et comment prouve-t-on que la reprise n’a pas créé un nouvel incident ?
Quand LemonLDAP::NG doit protéger plusieurs applications, rejoindre un annuaire ou un IdP, moderniser un WebSSO existant, sécuriser des headers, introduire CAS, SAML ou OIDC, ou rendre les règles et sessions exploitables.
Le portail porte notamment l’authentification et les protocoles, le handler protège les applications et applique les règles, tandis que le manager administre la configuration. Leur exposition et leurs responsabilités doivent être séparées.
On impose le passage par le handler, bloque tout accès direct au backend, supprime les headers d’identité entrants et n’exporte que les attributs nécessaires. L’application ne doit faire confiance qu’à cette chaîne contrôlée.
Oui, selon les rôles configurés et les applications. La coexistence doit conserver des identifiants stables, des mappings attribués, des sessions comprises et un plan de retrait pour les anciens chemins.
Des services existent pour l’authentification, les sessions et certains usages de configuration. Ils ne doivent pas être exposés par défaut : accès réseau, authentification, attributs exportés, journalisation et procédure de reprise sont cadrés au cas par cas.
Le devis tient compte du nombre d’applications, des protocoles, des adaptations nécessaires et des contraintes de disponibilité. Il détaille analyse, configuration, développement, recette et migration. Les responsabilités de support, de mise à jour et de reprise sont convenues avec votre DSI.
Non, aucune n’est revendiquée sur cette page. Dawap présente des projets IAM et API proches, puis vérifie votre version, votre topologie et vos modules avant de valider le périmètre.
On parle concret
Raccordez vos applications à un SSO documenté et maintenable.
Décrivez vos applications, votre annuaire et les difficultés d’accès. Nous définirons le périmètre, les tests et le calendrier de migration avec votre DSI, puis les modalités de support et de maintenance.
