SSO - Single Sign On
Les architectures
Il existe plusieurs type d'architecture de SSO, outre les techniques utilisées il s'agit ici de concept et de philosophie différentes. L'architecture d'un SSO est déterminante, ce choix doit être fait avec une visions globale du réseau cible. En effet ce choix est très fortement influencé par la politique de confiance établie entre les différentes entités à fédérer au sein du SSO, et également du service souhaité. Les architectures se divisent en trois types d'approche dont voici les caractéristiques :
Approche centralisée
Le principe de base est ici de disposer d'une base de données globale et centralisée de tous les utilisateurs ou d'un annuaire. Cela permet également de centraliser la gestion de la politique de sécurité. Un exemple de mise en œuvre est le logiciel libre LemonLDAP, un autre exemple est le logiciel libre Vulture.
Cette approche est principalement destinée à des services dépendant tous d'une même entité, par exemple à l'intérieur d'une société au sein de leur gestion des Middleware. Chaque service à complètement confiance dans l'authentification validé par le CA (Centre Authentification).
On peut citer comme exemple les comptes Google, qui permet d'accédé à une multitude de service tel que GoogleDoc (traitement de texte communautaire en ligne), gmail (messagerie et messagerie instantané), iGoogle (un iBureau interfacé avec le moteur recherche), etc., avec un seul compte et une seule authentification.
Approche fédérative
Dans cette approche, dont le système Liberty Alliance est le principal exemple, chaque service gère une partie des données d'un utilisateur (l'utilisateur peut donc disposer de plusieurs comptes), mais partage les informations dont il dispose sur l'utilisateur avec les services partenaires.
Cette approche a été développée pour répondre à un besoin de gestion décentralisée des utilisateurs, où chaque service partenaire désire conserver la maîtrise de sa propre politique de sécurité, comme par exemple un ensemble de sites marchands indépendants d'un point de vue commercial et organisationnel.
On peut imaginer un partenariat commercial composé de plusieurs sociétés, par exemple Amazone et Ebay. L'utilisateur possède un compte commun pour les deux sites, mais il doit pour chacun remplir les informations critiques, tel que sont adresse de livraison. En revanche son nom utilisateur, son adresse mail, et on peut imaginer un système de favoris, sont échangé afin de mieux ciblé les préférences de l'utilisateur.
Approche coopérative
L'approche coopérative, dont les systèmes Shibboleth et Central Authentication Service sont les principaux représentants, part du principe que chaque utilisateur dépend d'une des entités partenaires. Ainsi, lorsqu'il cherche à accéder à un service du réseau, l'utilisateur est authentifié par le partenaire dont il dépend, comme dans l'approche fédérative. Cependant, chaque service du réseau gère indépendamment sa propre politique de sécurité.
Cette approche est principalement utilisé par les communautés universitaire, où chaque université fait confiance à ses partenaires, mais dispose d'un système d'authentification local (car la gestion des nouveaux arrivants ce fait localement). L'authentification se fait donc au près de l'organisme de rattachement de l'utilisateur, le CA local décide donc de l'authentification et peut délivrer un niveau d' autorisation (par exemple niveau 1 pour les enseignants, niveau 2 pour les élèves). Et c'est l'organisme distant qui gère l'accès aux ressources comme il le désire.
On peut imaginer, deux universités (A et B) menant des recherches en partenariat, le fruit de ces recherches est hébergé chez B. Un enseignant de l'école A, s'authentifie au près de l'établissement A, il obtient une autorisation niveau 1. Cette autorisation est présentée à l'établissement B qui lui procure un accès total au projet partagé. Ce qui ne serait pas le cas d'un élève de A ou B qui obtiendrai une autorisation niveau 2, et donc pas d'accès ou un accès limité au projet. Les niveaux autorisations ne sont que des exemples et peuvent être affiné.