Single Sign-On (SSO) – 2ème partie
Date : 09 Juin 2010
Alors que la première partie donnait une approche théorique du SSO, celle-ci est plus pratique.
1. Les fonctionnalités SSOCe chapitre décrit les caractéristiques SSO. Certaines des caractéristiques mentionnées ci-dessous peuvent déjà exister dans une ou plusieurs applications. La mise en œuvre du produit SSO peut être utile pour aligner la politique d'authentification à toutes les applications dans l'organisation.
1.1 Les caractéristiques de base
1.1.1 L’authentification- Les méthodes d’authentification
o Le mot de passe
Les mots de passe sont les moyens d’authentification les plus utilisés. Ils doivent être changés régulièrement, et fondés sur une politique efficace pour les rendre moins vulnérables.
o One Time Password (OTP)
OTP est un mot de passe qui n'est valable que pour une seule connexion ou transaction. Il existe deux types d‘OTP, le mot de passe « défi-réponse » (répond avec une valeur de challenge après avoir reçu un identifiant d'utilisateur) et la « liste de mots de passe consommables » (liste de mots de passe qui sont successivement utilisés par la personne qui souhaite accéder à un système).
o La cryptographie à clé publique
La cryptographie à clé publique est une approche cryptographique qui utilise des algorithmes de clés asymétriques au lieu d’algorithmes de clés symétriques. La cryptographie à clé publique utilise deux clés, une privée et l'autre publique. La clé privée est utilisée pour décrypter et crypter les messages entre les machines communicantes. Le cryptage et la vérification de la signature se fait avec la clé publique.
o Le certificat numérique
Un certificat numérique est un document électronique qui utilise une signature numérique pour relier une clé publique à une identité.
o Security Token
Les “jetons de sécurité » sont utilisés pour prouver son identité par voie électronique. Le jeton est utilisé en complément ou à la place d'un mot de passe pour prouver que le client est bien celui qu'il prétend être.
o Les cartes à puce
Une carte à puce est une carte au format de poche avec des circuits intégrés qui peuvent traiter des données. Des applications logicielles supplémentaires utilisent la carte à puce, et évitent à l'utilisateur d’entrer à nouveau ses informations d’authentification. La carte à puce à base de « Single Sign-On » peut soit utiliser des certificats, soit des mots de passe stockés dans la puce.
o Biométrie
Les utilisateurs peuvent s'authentifier de façon biométrique via leurs empreintes digitales, la voix, ou l'iris de l’œil à l'aide d’un matériel approprié.
-
Les protocoles d’authentification
o Kerberos
Kerberos est un protocole d'authentification réseau qui repose sur un mécanisme de clés secrètes (chiffrement symétrique) et l'utilisation de tickets. Il n’y a pas de mots de passe en clair qui circulent sur le réseau, ce qui évite le risque d'interception des mots de passe des utilisateurs.
o Lightweight Third-Party Authentication (LTPA)
Lightweight Third Party Authentication (LTPA) est un processus d’authentification dont le principe est que tous les serveurs impliqués dans le processus SSO partagent une clé de chiffrement/déchiffrement. Quand un client fait une requête d’authentification sur un des serveurs, celui-ci renvoie un cookie contenant un jeton LTPA chiffré avec la clé partagée. Si l’utilisateur fait une requête sur un autre serveur, le cookie est encapsulé dans celle-ci, et le jeton LTPA est déchiffré avec la clé partagée. Aucune demande d’authentification supplémentaire n’est alors faite par ce dernier serveur.
o Simple and Protected GSSAPI NEGOtiation mechanism (SPNEGO)
L'authentification SPNEGO fournit une authentification unique (SSO) aux utilisateurs Windows qui veulent accéder à un serveur Web sécurisé en utilisant Internet Explorer. Un plug-in s’exécute côté serveur et Internet Explorer côté client.
o RADIUS
Le RADIUS est un protocole client / serveur qui permet une gestion centralisée des authentifications. Le poste utilisateur transmet une requête d'accès à un client RADIUS pour entrer sur le réseau en demandant des informations identifiant l'utilisateur.
Le client RADIUS génère selon le protocole une requête « Access-Request » contenant les informations d'authentification. Le serveur RADIUS traite la requête, valide ou refuse l'identification en renvoyant un paquet de type : « Access-Accept » ou « Access-Reject ». Plusieurs serveurs radius peuvent être en cascade (passage à chacun d’eux de la requête « Access-Request ») et c’est le dernier qui génère la requête « Access-Accept » ou « Access-Reject ».
Le client RADIUS génère selon le protocole une requête « Access-Request » contenant les informations d'authentification. Le serveur RADIUS traite la requête, valide ou refuse l'identification en renvoyant un paquet de type : « Access-Accept » ou « Access-Reject ». Plusieurs serveurs radius peuvent être en cascade (passage à chacun d’eux de la requête « Access-Request ») et c’est le dernier qui génère la requête « Access-Accept » ou « Access-Reject ».
o NT Lan Manager (NTLM)
Lorsqu'un utilisateur veut accéder à une application protégée, les demandes non authentifiées sont redirigées vers une URL qui nécessite l'authentification NTLM. Les informations d'identification NTLM sont demandées par le navigateur, puis vérifiées par un contrôleur de domaine NTLM. Une fois l’authentification vérifiée, un cookie de session est envoyé au navigateur et l'utilisateur est redirigé vers la page à laquelle il veut accéder.
o La persistance de l’authentification
Lorsque l'agent SSO est basé sur le poste de l'utilisateur, pour chaque demande, l'agent peut envoyer les informations d'identification utilisateur à la place de l'utilisateur.
Mais il existe d'autres mécanismes qui permettent le maintien de session. L’utilisation des cookies est le mécanisme le plus largement utilisé dans les applications web. Après avoir reçu un cookie, si l'utilisateur veut accéder à une autre application qui fait partie du SSO, le cookie est présenté par le navigateur pour directement se connecter à l'application.
Mais il existe d'autres mécanismes qui permettent le maintien de session. L’utilisation des cookies est le mécanisme le plus largement utilisé dans les applications web. Après avoir reçu un cookie, si l'utilisateur veut accéder à une autre application qui fait partie du SSO, le cookie est présenté par le navigateur pour directement se connecter à l'application.
1.1.2 « Credential Database »
Pour mémoriser les règles d'authentification et d'autorisation, le SSO peut utiliser une base de données locale (sa propre base de données) ou centralisée. Pour être intégré dans l'infrastructure déjà existante, le produit SSO peut être interfacé avec l'annuaire d'entreprise existant. Par conséquent, la plupart des systèmes « Single Sign-On » récents utilisent les répertoires LDAP (Lightweight Directory Access Protocol) répertoires car ils sont devenus avec l’authentification LDAP l'une des pierres angulaires de l'infrastructure de l’entreprise.
1.1.3 Gestion des mots de passe
Le SSO permet de définir la politique de mot de passe qui est un ensemble de règles garantissant que les utilisateurs utilisent des mots de passe fiables.
Certains produits SSO offre la réinitialisation de mot de passe en libre-service qui permet de réinitialiser le mot de passe après avoir fourni les bonnes réponses à quelques questions prédéfinies.
Certains produits SSO offre la réinitialisation de mot de passe en libre-service qui permet de réinitialiser le mot de passe après avoir fourni les bonnes réponses à quelques questions prédéfinies.
1.1.4 Applications
Le SSO peut être configuré pour authentifier un utilisateur sur pratiquement toutes les applications, même très personnalisées ou développées en interne.
1.1.5 Flexibilité du produit
Cette fonction permet de personnaliser les pages de connexion afin quelles prennent l'apparence de la page de connexion d'une application. Quand un utilisateur veut utiliser une application partenaire, il est redirigé vers le « Single Sign-On » serveur. Ce serveur vérifie le nom d'utilisateur et mot de passe, et redirige l'utilisateur vers l'URL de l'application. Si l'authentification échoue, le serveur redirige l'utilisateur vers la page de connexion et affiche un message d'erreur.
1.1.6 Reverse Proxy
Un reverse-proxy est un serveur proxy permettant non pas aux utilisateurs d'accéder au réseau internet, mais aux utilisateurs d'internet d'accéder indirectement à certains serveurs internes.
Il sert ainsi de relais pour les utilisateurs d'internet souhaitant accéder à un site web interne en lui transmettant indirectement les requêtes. Grâce au reverse-proxy, le serveur web est protégé des attaques directes de l'extérieur, ce qui renforce la sécurité du réseau interne. D'autre part, la fonction de cache du reverse-proxy peut permettre de soulager la charge du serveur pour lequel il est prévu.
Il sert ainsi de relais pour les utilisateurs d'internet souhaitant accéder à un site web interne en lui transmettant indirectement les requêtes. Grâce au reverse-proxy, le serveur web est protégé des attaques directes de l'extérieur, ce qui renforce la sécurité du réseau interne. D'autre part, la fonction de cache du reverse-proxy peut permettre de soulager la charge du serveur pour lequel il est prévu.
1.1.7 Sécurité du réseau
SSO permet aux utilisateurs de ne pas se rappeler d’un grand nombre de connexions et mots de passe.
Tous les messages d'authentification et d'autorisation et les décisions doivent être sécurisés lorsqu'ils sont transmis sur le réseau de l'infrastructure SSO. La communication utilise des connexions HTTPS.
Tous les messages d'authentification et d'autorisation et les décisions doivent être sécurisés lorsqu'ils sont transmis sur le réseau de l'infrastructure SSO. La communication utilise des connexions HTTPS.
1.1.8 Audit et traçabilité
Le SSO doit vérifier toutes les opérations exécutées dans la base de données des identifiants des utilisateurs.
Les fonctions de vérification permettent à l’entreprise d'être en conformité avec les règlements comme Sarbanes-Oxley.
Les fonctions de vérification permettent à l’entreprise d'être en conformité avec les règlements comme Sarbanes-Oxley.
1.1.9 Fonctions de gestion et de suivi
Le SSO offre des fonctionnalités avancées de suivi et de reporting à l'aide d'une console (interface web ou console d'administration).
SNMP permet l'activité de contrôle des composants sur le réseau qui héberge le SSO.
Certains produits SSO vous permettent de gérer et de surveiller les agents SSO basés sur l'extension JMX (Java Management) standard.
Vous pouvez protéger l'administration et la gestion des opérations sur la console d'administration au moyen d'un cryptage SSL. Pour l'administration du système d'exploitation et des opérations, l'utilisation standard des mécanismes de protection au niveau des OS comme Secure Shell (SSH), l'interdiction de la connexion de root, l’accès restreint, et le contrôle d'accès devraient être disponible.
SNMP permet l'activité de contrôle des composants sur le réseau qui héberge le SSO.
Certains produits SSO vous permettent de gérer et de surveiller les agents SSO basés sur l'extension JMX (Java Management) standard.
Vous pouvez protéger l'administration et la gestion des opérations sur la console d'administration au moyen d'un cryptage SSL. Pour l'administration du système d'exploitation et des opérations, l'utilisation standard des mécanismes de protection au niveau des OS comme Secure Shell (SSH), l'interdiction de la connexion de root, l’accès restreint, et le contrôle d'accès devraient être disponible.
1.2 Les caractéristiques de l’architecture
L'architecture SSO devrait être la première étape qui aidera à choisir la solution SSO à mettre en œuvre. L'intégration dépend des différentes zones dans lesquelles les composants du produit SSO seront implémentés. Dans le cas du SSO fédéré, les différents serveurs SSO peuvent être répartis sur différents sites de l'entreprise.
Le SSO doit être capable de s'intégrer facilement dans les solutions IT existantes, par exemple les solutions existantes de gestion des identités, les solutions de gestion d'événements de sécurité, les solutions de gestion des applications, du bureau ou des solutions de distribution de logiciels.
Le SSO peut être mis en œuvre soit par des logiciels soit par des dispositifs matériel. Les modules logiciels doivent être personnalisés et installés sur des serveurs. Les dispositifs matériel bien que personnalisables, ne sont pas aussi souples.
Le point faible du SSO est qu’il s’agit d’un point de défaillance unique. Ainsi, il est indispensable de sécuriser à la fois le produit SSO et ses connexions réseaux. Les matériels et les logiciels du SSO doivent être sur des serveurs dédiés qui sont durcis.
La redondance est nécessaire pour minimiser les risques de défaillance unique.
Certaines solutions de SSO nécessitent d'équilibrer les charges. En utilisant plusieurs composants de type « Load balancer », au lieu d'un seul, on peut augmenter la fiabilité.
La redondance est nécessaire pour minimiser les risques de défaillance unique.
Certaines solutions de SSO nécessitent d'équilibrer les charges. En utilisant plusieurs composants de type « Load balancer », au lieu d'un seul, on peut augmenter la fiabilité.
2. Quelques produits SSO
Ce chapitre liste des produits SSO du marché. La première partie est basée sur l'étude Gartner 2009 appelée « Magic Quadrant for Web Access Management ».
Les produits présentés dans l’étude Gartner :
- Tivoli Federated Identity Manager (TFIM) and Tivoli Access Manager for e-business (TAMeb) - IBM
- Oracle Access Manager - Oracle
- SiteMinder - CA
- Novell Access Manager - Novell
- Sun OpenSSO enterprise – Sun Microsystems
- Web Access Manager - Evidian
- RSA Access Manager - EMC (RSA)
- GetAccess - Entrust
- DirX Access - Siemens
- maXecurity – P2 Security
- Cams - Cafesoft
Autres produits :
- SecureLogin SSO - ActivIdentity
- Remedy Access Request System - BMC software
- SSOX - Avencis
- OneSign - Imprivata
- USO - i-sprint Innovations
- v-Go SSO - PassLogix
- expreSSO - Sentillion
- Protect Tools Security Manager : SSO - HP
- Quest Software
- PingFederate - PingIdentity
- open-source product - Vulture
- Sign&Go - Ilex
- i-Suite, i-Trust - Bee Ware
- CAS : protocol developed by Yale University
