La gestion de l’identité des utilisateurs est une tâche récurrente du développement des applications internet, qu’il s’agisse de réellement contrôler l’accès à certaines ressources ou simplement de personnaliser l’expérience utilisateur. Dans cette gestion, il convient de séparer deux parties : la vérification de l’identité du visiteur (authentification) et l’exploitation de cette identité (autorisations, personnalisation, etc.).

La gestion des autorisations ainsi que la personnalisation peuvent selon les cas relever d’une configuration technique assez simple ou de vraies règles applicatives mais la vérification des identités est quasiment toujours une tâche purement technique, n’ayant pas de rapport direct avec l’application qui exploite ensuite les identités « reconnues », aussi il est généralement bénéfique d’extraire cette vérification de l’application elle-même. Cette séparation présente des bénéfices à la fois pour le développeur de l’application et pour ses utilisateurs et elle permet en outre des scénarios de fédération d’identité impossibles à réaliser si chaque application définit ses propres mécanismes d’authentification. Dans le cas d’applications internes dans des environnements 100% Windows, l’authentification des utilisateurs est généralement confiée à Active Directory : cette approche est fiable, immédiatement disponible aux applications ASP.NET et permet aux utilisateurs de bénéficier du confort d’un Single Sign On. Dans le cas d’applications internet ou d’environnements hétérogènes, il faut trouver une alternative. Par ailleurs, les solutions b2b ont besoin de mécanismes d’authentification plus riches comme la fédération d’identité : imaginons une entreprise A qui offre des services aux utilisateurs de ses partenaires. Il peut s’agir par exemple d’une agence de voyage d’affaires qui s’occupe des réservations des employés de ses clients, d’un site de commerce en ligne offrant des réductions aux clients de certains partenaires, etc.

Alain Zanchetta