Critères de choix

Choisissez votre ou vos méthodes d'authentification dans Olfeo selon les critères ci-dessous, en fonction de vos populations d'utilisateurs et en fonction de vos besoins réels.

Infrastructure existante et mode d'intégration

Quels critères de choix votre infrastructure impose-t-elle?

Le choix de la méthode d'authentification doit prendre en compte les contraintes liées au mode d'intégration choisi, et les deux sont étroitement liés à votre infrastructure.

Tenez compte :

Interaction avec l'utilisateur

Souhaitez-vous que vos utilisateurs aient à entrer leur mot de passe ?

Sécurité

Quel niveau de sécurité est nécessaire pour votre organisation?

Il existe plusieurs mécanismes d'authentification, plus ou moins forts, c'est-à-dire avec un niveau de fiabilité plus ou moins élevé.

Fiabilité des différentes méthodes

Dans tous les cas, gardez à l'esprit qu'aucune méthode ne garantit de façon absolue l'identité de la personne physique ayant effectué la navigation.

Identification, basée sur l'adresse IP

Une adresse IP identifie une machine et non un utilisateur. L'adresse IP n'est pas un critère fiable pour identifier un utilisateur :

  • dans certaines architectures, une même adresse IP peut correspondre à plusieurs utilisateurs : clients légers (ISO, Citrix, TSE) où une adresse IP est commune à plusieurs utilisateurs. Si plusieurs utilisateurs utilisent la même machine en même temps, l'Olfeo ne reçoit que l'adresse IP du serveur mais les identifiants de n personnes.
  • pour les utilisateurs situés derrière un NAT, l'adresse IP reçue par l'Olfeo n'est pas celle de la machine à l'origine de la requête.
  • Une adresse IP peut être dynamique (attribuée par le serveur DHCP) : un même utilisateur pourra changer fréquemment d'IP, et une même adresse IP pourra être attribuée à plusieurs personnes successivement au cours du temps.
  • L'adresse IP reçue par l'Olfeo peut aussi être celle du proxy positionné avant l'Olfeo.
  • Une adresse IP peut être modifiée.
Authentification utilisant directement ou indirectement le couple identifiant/mot de passe Lorsqu'une authentification est faite ou que l'Olfeo reçoit un identifiant, il voit qu'une personne a utilisé un certain compte utilisateur pour surfer sur tel ou tel site internet, mais cela ne garantit pas que la personne physique ayant utilisé le navigateur est bien la personne titulaire de cet identifiant. Par exemple :
  • un utilisateur peut avoir communiqué son mot de passe à un collègue
  • un utilisateur peut avoir vu le mot de passe d'un collègue et avoir utilisé ce mot de passe pour utiliser sa machine
  • un utilisateur peut avoir laissé sa machine déverrouillée et quelqu'un d'autre l'a utilisée.

Contraintes liées à la force de l'authentification

Quel niveau de contrainte êtes-vous prêts à gérer?

Une authentification forte est contraignante. Avec des méthodes fortes, chaque requête est authentifiée :
  • Vous devrez définir des exceptions pour toutes les applications ne sachant pas s'authentifier, et le nombre d'exceptions peut être conséquent.
  • En outre, il sera nécessaire d'utiliser un Active Directory comme contrôleur de domaine, et il sera obligatoire de joindre la machine Olfeo au domaine Windows.
NTLM
  • Certains services web ne sont pas tolérants à une authentification NTLM via un proxy, par exemple Windows update ou les applets Java. Vous devrez définir des exceptions dans le paramétrage de l'authentification NTLM.
  • Cette méthode présente un coût réseau élevé, chaque requête entraînant une authentification.
Kerberos
  • Utiliser la méthode Kerberos implique un coût cryptographique (et donc de ressources CPU). Cette méthode est cependant moins coûteuse que NTLM au niveau réseau car moins d'aller-retours sont faits pour établir l'authentification.
  • Pour le Kerberos natif, vous devez pouvoir extraire le fichier keytab de l'infrastructure d'authentification.
  • Pour Kerberos AD, la jonction au domaine Windows est obligatoire. (Elle ne l'est pas pour Kerberos natif).
Recommandation

Si vous êtes dans un environnement contrôlé (typiquement : postes fixes, dont les adresses IP sont attribuées au moment de l'ouverture matinale de la session utilisateur), et que votre besoin est d'appliquer des politiques de filtrage par identifiant, utilisez un portail captif. (Avec NTLM si vous souhaitez que l'utilisateur n'ait pas à entrer son mot de passe.) Cette solution vous permet de vous affranchir des contraintes imposées par les méthodes d'authentification fortes : coût réseau et/ou cryptographique, nombreuses exceptions à gérer au quotidien...

Résumé

Méthode Annuaire utilisé pour authentifier/identifier Transparent pour l’utilisateur ? Authentification/identification réalisée par ?
NTLM AD Oui (avec fallback explicite) Proxy
Kerberos AD AD Oui Proxy
Kerberos natif n/a (la méthode ne s'appuie pas sur un annuaire) Oui Proxy
LDAP basique LDAP, AD, Novell Non (fenêtre pop-up) Proxy
Portail captif LDAP, AD, Novell Non (page HTML) Moteur de filtrage
Portail captif NTLM AD Oui Moteur de filtrage
SSO Novell Novell Oui Moteur de filtrage