Posté par romain .
En réponse au message SSO.
Évalué à 2.
Un sso, c'est :
1. une base centrale d'authentification, et de gestion de session,
2. une base et un mécanisme de gestion de session (création/destruction d'un lien entre un utilisateur, une date, et une clé de session),
3. des mécanismes de propagation de sessions entres applications.
Le 1. existe déjà un peu partout, et déjà certainement dans ta boîte (base d'utilisateurs, peu importe le format, "l'idéal" dépendant de nombreux facteurs - LDAP peut l'être, mais pas forcément).
Le 2. est assez rapide à faire (une table, et une API la liant au 1.).
Le 3. dépend strictement de tes applications. S'il ne s'agit que du web, le plus simple est de mettre en place un (ou des) cookie global contenant le couple (login/clé de session) que chaque application vérifiera contre la base centrale de gestion des sessions avant d'ouvrir une session locale, ou d'accorder l'accès. S'il s'agit d'autre chose que le web, c'est à peine plus compliqué.
Est-ce que tout ça existe déjà tout fait ? En briques, sans aucun doute. Mais pour coller exactement à l'architecture du système de ta boîte (qui n'est pas forcément "standard"), tu n'as pas vraiment besoin d'autre chose que de briques (tu as sans doute le 1, le 3. correspond à un mécanisme classique d'authentification web, le 2. est le seul "truc" à personnaliser vraiment en fonction de ta boîte).
# Un sso, c'est quoi ?
Posté par romain . En réponse au message SSO. Évalué à 2.
1. une base centrale d'authentification, et de gestion de session,
2. une base et un mécanisme de gestion de session (création/destruction d'un lien entre un utilisateur, une date, et une clé de session),
3. des mécanismes de propagation de sessions entres applications.
Le 1. existe déjà un peu partout, et déjà certainement dans ta boîte (base d'utilisateurs, peu importe le format, "l'idéal" dépendant de nombreux facteurs - LDAP peut l'être, mais pas forcément).
Le 2. est assez rapide à faire (une table, et une API la liant au 1.).
Le 3. dépend strictement de tes applications. S'il ne s'agit que du web, le plus simple est de mettre en place un (ou des) cookie global contenant le couple (login/clé de session) que chaque application vérifiera contre la base centrale de gestion des sessions avant d'ouvrir une session locale, ou d'accorder l'accès. S'il s'agit d'autre chose que le web, c'est à peine plus compliqué.
Est-ce que tout ça existe déjà tout fait ? En briques, sans aucun doute. Mais pour coller exactement à l'architecture du système de ta boîte (qui n'est pas forcément "standard"), tu n'as pas vraiment besoin d'autre chose que de briques (tu as sans doute le 1, le 3. correspond à un mécanisme classique d'authentification web, le 2. est le seul "truc" à personnaliser vraiment en fonction de ta boîte).