Critères de choix

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.

Selon le mode d'intégration, l'Olfeo ne recevra pas les mêmes informations : IP, identifiant...
Suivant votre infrastructure, l'authentification peut être réalisée par l'Olfeo lui-même, ou bien l'Olfeo peut récupérer des informations d’authentification d'un équipement tiers.

Tenez compte :

Des mécanismes d'authentification utilisés dans votre infrastructure (par exemple, si vous utilisez déjà NTLM).
Des types d'annuaires utilisés. Les méthodes supportées sont les suivantes :
- LDAP : authentification LDAP basique, portail captif
- Active Directory : Kerberos, NTLM, authentification LDAP basique, portail captif
- Novell : authentification LDAP basique, portail captif ou identification via le mécanisme SSO Novell.
Des types de machines que vous gérez. Par exemple, avec des architectures client léger (serveurs TSE ou Citrix), utilisez uniquement des authentifications fortes.

Interaction avec l'utilisateur

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

Oui : portail captif sans NTLM, LDAP basique.
Non : NTLM, Kerberos, portail captif transparent pour l'utilisateur avec NTLM.
On parle parfois d'authentification transparente : l'expression "authentification transparente" s'entend au sens de "transparente pour l'utilisateur". On ne demande jamais à l'utilisateur de saisir son identifiant/mot de passe à la main, l'authentification se fait de façon automatique. Mais par nature une authentification n'est pas transparente pour l'application cliente (le proxy demande toujours explicitement au client de s'authentifier).

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é.

Mécanisme fort : l'utilisateur est authentifié pour chaque requête. Attention, ce mécanisme a de fortes contraintes : voir ci-dessous, Contraintes liées à la force de l'authentification.
Mécanismes d'authentification forts proposés par Olfeo : Kerberos, NTLM.
Mécanisme faible : à la première requête, la solution réalise une action d'authentification. Une fois l'authentification faite, la solution stocke la correspondance entre l'identifiant de l'utilisateur et son adresse IP, et par la suite elle fait simplement une identification en se basant sur l'adresse IP. La fiabilité de cette méthode diminue au cours du temps car l'adresse IP et l'identifiant sont susceptibles de ne plus se correspondre.
Mécanismes d'authentification faibles proposés par Olfeo : portail captif, authentification LDAP basique, portail public.

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.

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).

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