ADFS 3.0 et OpenAM, fédérer des applications non compatibles SAML

Si vous possédez dans votre infrastructure un serveur “Active Directory Federation Service”, alors cet article peut vous intéresser. Nous allons voir comment il est possible de faire intéragir ADFS 3.0 avec OpenAM pour gérer l’authentification de vos applications non compatibles SAML.

Nous allons commencer par un court rappel sur les notions de fédération qui vont nous servir dans la suite de cette article:

Fournisseur d’identités (Identity provider ou IDP): il sert à authentifier l’utilisateur. Il permet de récupérer des informations supplémentaires associées à l’identité de l’utilisateur
Fournisseur de service (Service provider ou SP): protège l’accès aux applications de tout utilisateur non authentifié et le redirige vers le fournisseur d’identités
SAML request: c’est une requête envoyé par le SP à l’IDP pour lui demander d’authentifier un utilisateur
SAML response: c’est une requête qui contient le résultat de l’authentification de l’utilisateur. Elle est envoyée par l’IDP au SP
HTTP Post Binding: ce mode permet de faire passer tous les flux par le navigateur de l’utilisateur. Les explications de cet article requièrent que nous soyons dans ce mode.

1 – Les rôles

La partie OpenAM est composée d’un agent et d’un serveur. Le serveur héberge la configuration (mode d’authentification, applications protégés, politique sur les URL..). L’agent nous permet d’intercepter les flux à destination de l’application et de rediriger vers le serveur toute personne non authentifiée. Il applique les politiques de sécurités sur les URL si vous décidez de les mettre en place. Le serveur OpenAM sera configuré en tant que fournisseur de service pour la partie fédération.

Le serveur ADFS est le fournisseur d’identité. Il s’appuie sur l’Active Directory pour authentifier les utilisateurs et inclure des informations supplémentaires dans l’assertion SAML (par exemple le sAMAccountname).

2 – Illustration

Le schéma ci-dessous nous montre comment la solution s’intègre au sein d’un système d’information. Les flèches montrent les différentes interactions entre les machines.

schéma d’architecture cible

3 – Scénario Type

Le diagramme de séquence ci-dessous présente un scénario d’accès à une application :

Diagramme de séquence d’accès à une application protégée par OpenAM et fédéré avec ADFS

1 – L’utilisateur tente de se connecter à l’application. L’agent OpenAM intercepte la requête. L’utilisateur n’est pas authentifié, il est donc redirigé vers OpenAM.

2 – OpenAM reçoit la demande d’authentification. Il est configuré pour déléguer son authentification à l’ADFS. Il redirige donc l’utilisateur vers la mire d’authentification ADFS. C’est la SAML request.

3 – Ici deux cas sont possibles. Cas numéro 1: vous êtes sur un réseau local et votre navigateur est configuré pour envoyer l’authentification de la session Windows à l’ADFS. Alors l’utilisateur sera authentifié sans avoir à renseigner ses identifiants. Cas numéro 2: vous êtes sur un réseau externe ou sur un réseau interne mais votre navigateur n’est pas configuré pour envoyer les identifiants de la session Windows, alors la mire d’authentification ADFS apparaît. L’utilisateur entre ses informations. Dans les deux cas, en cas d’authentification réussie, l’ADFS émet une réponse à la SAML request, c’est la SAML response.

4 – OpenAM reçoit la SAML response. Avec les informations contenues dans cette dernière, il est capable de réaliser une authentification Unique. L’utilisateur possède maintenant un token d’authentification OpenAM. Il est redirigé vers l’application.

5 – L’utilisateur accède à l’application

Vincent

Consultant sécurité