Meilleures pratiques pour l’authentification mixte

Avant d’examiner les faiblesses de l’authentification
mixte et comment y pallier,
voyons rapidement pourquoi développeurs
et DBA pourraient choisir à 
tort l’authentification mixte ou répugner
à  utiliser l’authentification Windows.
En réalité, beaucoup de développeurs
d’applications et de DBA SQL
Server qui pratiquent l’utilisation mixte
ne connaissent pas ses dangers. Ils
choisissent généralement l’authentification
mixte pour deux raisons.
Premièrement, la plupart des exemples
qu’ils trouvent sur Internet ou
dans les livres montrent des chaînes de
connexion SQL Server qui utilisent des
comptes SQL Server et n’expliquent
pas comment utiliser l’authentification
Windows pour se connecter à  SQL
Server.
Deuxièmement, la plupart des
DBA et développeurs pensent qu’il est
plus rapide d’écrire des applications
avec authentification mixte et que le
code ainsi obtenu sera plus facile à  déboguer.
L’authentification Windows
peut ajouter une couche de complexité
à  l’application. Comme ce
mode d’authentification demande
d’utiliser un compte Windows pour
toute la connectivité base de données,
les développeurs ASP (Active Server
Pages), par exemple, pourraient être
obligés d’utiliser COM+ pour accéder
à  SQL Server au lieu d’incorporer directement
l’information de connexion
dans le code ASP. Avec l’authentification
mixte, les développeurs codent un
nom d’utilisateur et un mot de passe
dans une chaîne de connexion dans la
page ASP. Avec cette méthode de stockage,
les développeurs connaissent
toujours le compte par l’intermédiaire
duquel un utilisateur se connecte à 
SQL Server. En revanche, quand les développeurs
utilisent l’authentification
Windows sur une simple page ASP, le
compte par le biais duquel un utilisateur
se connecte à  la page ASP est aussi
le compte qui connecte à  SQL Server.
Le plus souvent, le compte que l’utilisateur
emploie pour se connecter au serveur Web qui héberge la page ASP,
est le compte d’accès anonyme Microsoft
IIS (IUSR_machinename). La plupart
des DBA ne veulent pas permettre
à  ce compte anonyme d’accéder à  SQL
Server – et ils ont raison. Mais cette
restriction oblige le développeur à 
fournir l’une des deux méthodes de
connexion suivantes aux utilisateurs.
Le développeur peut demander aux
utilisateurs de se connecter au serveur
Web qui héberge la page Web en utilisant
l’authentification IIS ou un formulaire
Web sur la page ASP. Ou bien, le
développeur peut créer un fichier
COM+ .dll et utiliser les propriétés du
package COM+ pour savoir quel
compte la page ASP appelle pour se
connecter à  SQL Server. On voit bien
que l’authentification Windows semble
plus ardue.
En outre, les développeurs d’applications
Web utilisent souvent l’authentification
mixte parce qu’elle permet
d’utiliser facilement ADO pour se
connecter aux bases de données SQL
Server. Et comme ADO anime les applications
Web pilotées par base de
données et basées sur ASP, les développeurs
Web pourraient légitimement
penser que l’authentification mixte est
le meilleur choix.
S’il est vrai que l’authentification
Windows est plus difficile à  mettre en
oeuvre, les développeurs qui prennent
le temps de bien la comprendre peuvent
éliminer les failles de sécurité potentielles
inhérentes à  l’authentification
mixte. D’ailleurs, les développeurs
doivent souvent réécrire des applications
ASP précisément à  cause des lacunes
de sécurité de l’authentification
mixte. Il faut choisir : soit écrire des applications
rapidement et simplement
pour être obligé de les réécrire plus
tard ; soit prendre le temps d’écrire
d’emblée des applications plus sûres.
Voyons maintenant les problèmes associés
à  l’authentification mixte et au
compte sa et comment s’en protéger.