SSO - Single Sign On
Le SSO, Single Sign On ou authentification unique, est une architecture complexe permettant idéalement, à un utilisateur, de s'authentifier une seule fois, puis d'avoir un accès libre à toutes les ressources (applications, données, ...) auxquelles il est autorisé à accéder.
Le SSO est donc une architecture informatique composé de plusieurs systèmes tel que le centre d'authentification, les serveurs applicatifs, etc., permettant de propager l'identité d'un utilisateur déjà authentifié à toutes les applications.
Webographie
Voici une liste non exhaustive des documents qui m'ont permis de mieux comprendre la technologie des SSO. Ils traitent beaucoup de solution libre (surtout CAS) car la majorité des documents trouvés sur internet sont issus d'université, et donc privilégie bien souvent le domaine libre.
Site référençant les différentes études mené ou utilisé par la CRU (comité des réseaux universitaire) lors de la mise en place d'un SSO pour RENATER. Beaucoup des documents suivant en sont issus, directement ou indirectement.
Présentation power point sur les SSO, introduction et avantages. Schéma d’une architecture classique. Puis une réflexion sur les problèmes des architectures multi-tiers (architecture fédéré ou coopérative).
Un n-ième lien de présentation SSO. Il a cependant la particularité de présenté plusieurs produits payants ( dont IBM Access Manager ) et d'expliquer les solutions techniques qu'ils utilisent.
Document issus du Ministère de l'éducation nationale, qui fournit un ensemble de recommandation pour la mise en place d'un service AAS (Authentification-Autorisation-SSO).
Site référençant les différents comptes rendu de réunion pour la mise en place d'un SSO au sein d'un réseau entre plusieurs universités. On peut donc suivre le court des comptes rendu l'évolution du projet, les questions qu'ils se posent et les choix qui sont fait. Il propose aussi un listing de liens vers les documentations utilisé dans leur projet (mise en place de CAS).
Réflexion sur les problèmes d'ordre technique sur la mise en place d'un SSO, mais il est très orienté pour le cas particulier de l'université qui a produit le document. Néanmoins il reste quelques points important, qui peut être intéressant de connaitre.
Les avantages et Inconvénients
Avantages
La mise en place d'un système SSO apporte beaucoup d'avantage, en voici une liste non exhaustive qui présente les principaux que l'on peut recenser. Le SSO permet l'amélioration de la sécurité :
- En limitant le nombre de mot de passe pour chaque utilisateur.
- En limitant le nombre d'échange réseau pour l'authentification.
- En centralisant l'authentification un seul système:
- moins de risque de faille
- permet un système de trace plus facile
- limite les risques d'inconstance
Le SSO permet l'amélioration du confort : Des utilisateurs :
- En limitant le nombre de saisi pour les authentifications (mot de passe ou code pin).
- En limitant les appels au support informatique (perte de mot de passe, blocage de compte, etc.)
- Permettant bien souvent une centralisation sur un portail des applications.
Des développeurs :
- En permettant une meilleure intégration des services dans le système d'information.
- En utilisant des APIs d'authentification commune qui simplifie le développement.
Inconvénients
Malgré les avantages majeur qu'apporte le SSO il est important de signaler les quelques inconvénients. Tout d'abord la compatibilité avec toutes les applications est loin d'être garantie notamment pour tous les clients lourds. Bien que l'on parle parfois de SSO lourd cela reste très marginale et ne concerne très peux d'applications.
Le SSO peut également nuire à la sécurité, en effet il donne accès à une multitude de ressources une fois l'utilisateur authentifier (la métaphore de la clé du château illustre bien cela). C'est pour cette raison qui il préférable de couplé les solutions de SSO, avec un système d'authentification forte, comme les certificats sur carte à puce proposé par l'IGC générique.
Le principe même du SSO peut aussi être vu comme un défaut, car le centre authentification est un élément indispensable, une mise en échec ou une indisponibilité de celui-ci paralyse alors tout le système d'information. Cela peut rendre le SSO difficilement déployable pour les systèmes critiques qui ont besoin d'être accessible à tous moment.
Généralités
Les composants
Un système SSO minimum est composé de trois « briques », ces briques apportent des fonctionnalités qui permettent la mise en place du SSO. Les trois briques qui composent un système classiques sont :
- Le serveur authentification : c'est l'élément central du SSO, il gère :
- l'authentification des utilisateurs
- le maintien de sessions
- la propagation d'identité entre les applications (souvent par création de jeton)
- Les applications : se sont celle utilisé par l'utilisateur final, elles doivent être compatible avec le système SSO, c'est à dire pouvoir d'interfacé avec l'agent d'authentification
- L'agent d'authentification : c'est l'interface de communication entre les applications et le serveur d'authentification. Son rôle est de vérifié que l'utilisateur est authentifié. S’il ne l'est pas il doit être redirigé vers le serveur d'authentification. L'agent d'authentification est souvent un plug-in intégré dans chaque application.
Le principe de fonctionnement
Les composants d'un système SSO interagisse ensemble comme le montre le schéma suivant. Les rôles indiqué ici ne représente pas de technologie particulière, le centre d'authentification peut être ce que l'on désire (LDAP, IGC, etc..), l'agent d'authentification peut lui aussi être différent d'un système à l'autre, les plus connus sont les modules apache (pour le SSO web) et le « reverse proxy ».
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é.
0 commentaires:
Enregistrer un commentaire