Votre infrastructure .NET peut comporter différentes sortes d'interfaces client et administrateur. Selon l'objectif des interfaces et les données qui leur sont accessibles, elles peuvent demander différents niveaux d'authentification. Ainsi, des interfaces et données publiques ne demandent aucune authentification.
Le choix d'un protocole d'authentification dépend du protocole d'accès et de
l’application client concernée. Au travers de connexions basées sur RPC, on peut utiliser Kerberos ou NTLM (NT LAN Manager). Les connexions de type HTTP offrent davantage d’options : authentification de base ou digest, Kerberos, NTLM, ou authentification basée sur un certificat client. Dans le cas d’un ensemble hétérogène d’applications clients provenant de fournisseurs différents, il ne faut pas choisir NTLM ou Kerberos. (NTLM est un protocole propre à Microsoft et Kerberos est un standard ouvert dont le support n’est pas généralisé.) Rappelons également que Kerberos et NTLM ne sont disponibles sur HTTP que quand l’utilisateur est déjà enregistré auprès d’un domaine Windows. Si la plupart des clients se connectent par Internet, on préfèrera l’authentification de base à SSL pour de petites populations d’utilisateurs. Pour un grand nombre d’utilisateurs, on peut songer à fournir les protocoles d’authentification standard avec une méthode d’authentification fondée sur des formulaires ou cookies personnalisés (custom). On peut aussi songer à Microsoft Passport, une technologie SSO (single sign-on) destinée aux grands environnements Internet.
La qualité d’une solution d’authentification dépend pour beaucoup du nombre de facteurs par lesquels la solution identifie sans équivoque une entité. Une solution par mot de passe simple qui s’appuie uniquement sur la connaissance (d’une identification et d’un mot de passe utilisateur, par exemple) offre une qualité d’authentification inférieure à une solution qui s’appuie à la fois sur la possession (d’une carte intelligente, par exemple) et la connaissance (d’un code PIN, par exemple). La première solution est une méthode d’authentification par facteur unique, tandis que la seconde est une méthode d’authentification par deux facteurs. Pour des solutions de type .NET dans un environnement sensible à la sécurité, on peut même envisager des méthodes d’authentification à trois facteurs combinant la connaissance, la possession, et des données biométriques (empreintes digitales, par exemple).
La qualité d’une solution d’authentification est affectée par un autre facteur : la technologie cryptographique sous-jacente. Un protocole d’authentification comme Kerberos ou NTLM est généralement plus facile à casser qu’une système d’authentification à base de certificat client SSL. Le premier utilise des chiffres symétriques, tandis que le second utilise des chiffres asymétriques. Kerberos PKINIT, utilisé par le processus d’enregistrement par carte intelligente Win2K, fait exception à la règle. Cette extension du protocole Kerberos utilise à la fois les chiffres symétriques et les chiffres asymétriques. (L’utilisation de chiffres asymétriques peut nécessiter la mise en place d’un PKI.)
Lorsqu’on conçoit les solutions d’authentification pour l’infrastructure .NET, il faut également prendre en compte la base de données des références (credential). La configuration des bases de données de référence dépend une fois de plus de l’usage qui est fait des références d’authentification. (La base de données de mots de passe pour une application publique demande moins de protection que la base de données dont les mots de passe servent à … lancer un missile nucléaire.) Dans un environnement Windows, on peut parfaitement stocker les références dans AD. Dans l’exemple illustré par la figure 1, on peut choisir de stocker toutes les références sur des serveurs AD dans la zone de confiance, ou bien de stocker un sous-ensemble des références sur des serveurs AD dans la DMZ. Pour établir ce dernier scénario, on peut soit définir une forêt AD distincte pour la DMZ, soit définir un domaine AD distinct pour la DMZ et l’intégrer à la forêt AD dans la zone de confiance. Je recommande la première méthode (c’est-à -dire, la forêt AD distincte dans la DMZ), parce qu’elle isole complètement les comptes de la zone de confiance de ceux de la DMZ. Cette méthode dispense également d’utiliser des RPC au travers des pare-feu protégeant le réseau de confiance et permettent d’utiliser LDAP sur SSL pour mettre en place un mécanisme de synchronisation sécurisé entre l’interne et le domaine DMZ AD.
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
