Discussion :

[nuke_y]

Bonjour à tous.

J'ai plusieurs applications propriétaires qui se basent sur des LDAP pour l'authentification. Suite à une mauvaise architecture, il existe 1 LDAP par application. De fait, il faut se logger sur chaque application, alors que le login et le mot de passe sont normalement les mêmes (des différences peuvent exister vu qu'il s'agit de LDAP différents, mais elles ne devraient pas).

Comme il s'agit d'applications propriétaires, je ne peux pas activer sur le produit un module de SSO qui permettrait d'utiliser l'AD. Par contre nous avons imaginé la solution suivante:
- un portail unique de connexion dans lequel l'utilisateur saisit son login et son mot de passe (à noter que le login et le mot de passe est celui des LDAP, pas celui de l'AD, impossible donc d'éviter cette phase de saisie).
- sur ce portail une page contenant des liens vers chaque application.
- lors du clic sur un lien d'une application, le portail unique, qui a mémorisé dans les paramètres de la session le login et le mot de passe, connecte l'utilisateur sur l'application puis rend la main à l'utilisateur qui peut utiliser l'application.

Avantages:
- 1 seule saisie pour l'utilisateur
- pas de référentiel de login/mdp supplémentaire à gérer (cad pas de correspondance compte AD <-> compte LDAP)
- les login et mdp ne sont jamais stockés, seulement dans les variables de session du portail unique.

Inconvénients:
- il faut imposer à l'utilisateur d'avoir le même mot de passe sur tous les LDAP
- si la session de l'utilisateur tombe en time-out sur une des applications (plus d'1h d'inactivité par exemple), il devra se re-connecter directement sur l'application ou tout fermer et repasser par le portail. Par exemple si l'utilisateur a ouvert 4 applis puis est parti manger, quand il revient il doit se re-connecter sous chaque appli ou les ré-ouvrir depuis le portail unique.
- difficulté technique pour coder la connexion automatique sur chaque page (il faut faire du spécifique pour chaque application).
- sécurité ?


Autre solution envisagée:
fournir aux utilisateurs des scripts de connexion ou des raccourcis pré-programmés à stocker sur leur poste de travail, 1 script/raccourci par application. Chaque utilisateur saisi dans le script/raccourci son login et son mot de passe. En cliquant dessus ça ouvre Internet Explorer et ça connecte l'utilisateur sur l'application avec une requête GET (on a pas encore trouvé comment faire un POST).

Avantages:
- simplicité

Inconvénients:
- Maintenance
- Sécurité


Informations techniques:
- postes utilisateurs sous Windows XP, vista ou Seven
- IE est obligatoire (v7 en cours de déploiement)
- serveurs d'application Unix
- AD disponible
- LDAP propriétaires Sun One

Merci de vos commentaires, idées et surtout solutions pour résoudre ce problème.

Merci

[EMMREY]

Bonjour,

A mon avis, il y a 2 possibilités qui s'appuient sur un client SSO installé sur les postes users (cela permet de ne pas toucher aux applis) :

- une approche centrale, s'appuyant sur un ADAM ou ADLDS (c'est gratos chez MS), connecté à votre AD, avec un mécanisme de synchro AD/ADAM unidirectionnel. C'est facile en mettre en œuvre. Les utilisateurs utilisent un token qui contient leur login/mdp qui est le même pour chaque appli (ou différent) : le token renseigne les mdp dans l'application, à la place des users et gère le changement de mdp si vos applis propriétaires sont capables de générer une fenêtre de changement de mdp. Ce token est synchronisé avec l'ADAM qui contient les credentiels applicatifs.
Avantage : vous gérez les users d'un point central et vous ne touchez pas à vos applis.

- une approche décentralisée ou il n'y a pas d'ADAM ou ADLDS : le token contient également les credentiels applicatifs mais vous ne gérez pas une base centrale.

Par déontologie, je vous informe que je travaille pour un éditeur de sso www.idactis.com. Toutefois, il existe, sur le marché, d'autres éditeurs capables de répondre également à votre besoin.

Bonne continuation

ER