Ce n'est pas trop compliqué, à condition que les deux applications puissent accéder à des données de session similaires. Mais seulement si vous pouvez jouer un peu avec le code. Étant donné que vous parlez de différentes entreprises fournissant le logiciel, cette deuxième partie pourrait ne pas être possible.
Essentiellement, lorsque qu'une session est démarrée avec AppA, le nom d'utilisateur et le mot de passe sont vérifiés par rapport à une source (que ce soit une base de données, un serveur IMAP, un serveur LDAP, peu importe), ce n'est en réalité pas la partie importante du processus. Après cette première collection de nom d'utilisateur/mot de passe, un jeton de session est émis. AppA vérifie le jeton de session lors de l'accès et s'il est valide ; charge la session (donc il n'est pas nécessaire de saisir le nom d'utilisateur/mot de passe à chaque fois que vous faites quelque chose).
Pour que cela fonctionne, vous avez besoin que AppB puisse (a) accéder à ce jeton de session (assez simple, il est probablement stocké sous forme de cookie), (b) accéder aux données de session qui répertorient les jetons valides et le lien avec l'utilisateur (si l'utilisateur n'est pas inclus avec le jeton dans le cookie) et (c) créer une session dans AppB sans un démarrage avec nom d'utilisateur/mot de passe, ou valider par rapport à la session existante.
Accès au jeton de session :
Cela devrait simplement être une question de lire les cookies fournis à AppB. Tant que AppA émet le cookie sans une valeur de path restrictive (faible risque puisque la société A ne peut pas connaître tous les dossiers sous lesquels AppA pourrait fonctionner).
Accès aux données de session :
Typiquement, une application stockerait des informations de session dans une sorte de table de base de données. La seule astuce pourrait être de savoir le nom d'utilisateur associé à une session (le jeton pourrait inclure le nom d'utilisateur, ou une sorte d'identifiant, ou aucun des deux). La validité de session telle que définie par AppA doit être respectée par AppB
Créer une session AppB :
Probablement la partie la plus délicate, si AppB a une injection de dépendance sur le module d'authentification, (incluant le démarrage de session, la détection de session et la terminaison de session) alors il suffit de faire en sorte que l'application lise le même jeton de session que AppA, compare/valide par rapport aux données de session et traduise et étende si nécessaire. Remarque à moins que les deux applications soient modifiées, vous voudrez également que AppB reporte les connexions et éventuellement les déconnexions à AppA
Sécurité :
Si AppA utilise un cookie pour stocker/récupérer des informations de session sans une valeur de chemin, notons que n'importe quelle autre partie du même site web peut également voir ce cookie. Si une partie du site est servie sous http - y compris les images, les feuilles de style et le javascript - ce cookie de session sera exposé et accessible par des logiciels de renifleurs (comme firesheep) ou du matériel. Servir du contenu statique à partir d'un serveur différent (ou du même serveur sous un nom différent) aide à atténuer cela.
