Dans le cadre des services Cloud et de la fédération d’identité le SAML est le protocole qui monte au point de devenir incontournable. Avant d’essayer d’en expliquer le succès voyons de quoi il est question !
le principe ou comment ça marche
Le SAML « Security Assertion Markup Language » est un protocole ouvert et standardisé basé sur le langage XML pour échanger des informations d’authentification et d’autorisation entre des entités ou domaines de sécurité.
Le SAML va gérer à la fois le format du message XML, appelé assertion, ainsi que les renseignements nécessaires à l’authentification et le process d’échange entre deux grands partenaires :
- Le SP (Service Provider) ou fournisseur de service, qui protège l'accès aux ressources demandées (sites web, applications etc) en appliquant une politique de sécurité. Par exemple, il bloque tout accès à un utilisateur non authentifié et le dirige vers son fournisseur d'identité.
- L'IdP (Identity Provider) est le fournisseur d'identité qui répond à la demande du SP. Il est chargé d'authentifier l'utilisateur et de forger la réponse contenant les informations associées à l’identité (groupe en général) et demandées par le SP.
illustration par l’exemple
Prenons maintenant le cas simple d’une entreprise utilisant un proxy dans le nuage comme ceux des solutions décrites dans cet article. Supposons que l’entreprise de cet utilisateur dispose d’une solution de Single Sign On basée sur SAML dans un datacenter et illustrons ce qui se passe quand un utilisateur veut accéder à un site Internet en s’authentifiant à l’aide du protocole SAML.
Lorsqu’une requête d’authentification arrive sur le proxy Cloud, celui-ci examine les règles de sécurité et cherche à savoir si l’utilisateur peut accéder au site demandé. Le SP regarde si le navigateur possède un cookie d’authentification. Si le cookie d’authentification est déjà présent, l’utilisateur est identifié et la politique de sécurité est appliquée en fonction du profil et des droits de l’utilisateur.
Si le SP ne trouve pas de cookie, une requête d’authentification est créée et le processus d’authentification débute. Les flux passent par l’intermédiaire du navigateur à l’intérieur de la même session et sont adressés à l’IdP.
L’IdP vérifie les paramètres de l’utilisateur en interrogeant l’annuaire de l’entreprise et récupère les paramètres liés à l’utilisateur. Il forge avec tout cela l’assertion SAML.
Une fois l’authentification finalisée, l’information provenant de l’assertion SAML est stockée de façon sécurisée dans un cookie pour le domaine visité. L’accès au domaine est accordé selon la requête d’origine de l’utilisateur et le cookie est stocké dans le navigateur en accord avec la politique de sécurité définie par l’administrateur. L’assertion sera valide jusqu’à l’expiration du cookie. Celui-ci peut être supprimé à l’expiration de la session, à l’issu d’un délai ou être permanent.
les raisons du succès
Comment expliquer le succès du SAML ? 4 raisons à mon avis :
- La neutralité de la plateforme : le SAML offre un cadre de sécurité indépendant de la plateforme technique qui l’utilise. Ceci est valable pour la partie SP (application) et pour la partie IdP.
- Une nouvelle expérience utilisateur : avez-vous remarqué que dans le marketing tout est expérience et qu’un slogan est réussi si vous avez fait une expérience ? Soyons pragmatique : gérer des mots de passe pour X applications c’est la galère. Alors une solution de SSO basée sur un protocole standard qui vous affranchit de cette corvée pour vous donner accès à vos applications préférées potentiellement chez de nombreux SP (dans le Cloud bien sûr !) je ne sais pas si c’est une nouvelle expérience mais c’est sacrément pratique !
- Une réduction de la complexité pour le Service Provider ! En effet, le SP se contente d’émettre une demande vers un IdP, soit hébergé par le client lui-même, soit par un tiers de confiance assurant la fédération d’identité. Le SP est donc déchargé de la fastidieuse phase d’authentification pour faire ce qu’il sait faire le mieux : fournir un service. En plus un SP peut réutiliser l’authentification stockée dans un cookie autant de fois que nécessaire ! Intéressant non ?
- La sécurité : enfin me direz-vous, il était temps ! En quoi la sécurité y gagne ? Tout simplement parce que tout se passe par l’intermédiaire du navigateur au cours d’une même session sans que le SP ne fasse de requête entrante sur le réseau du client. Donc plus besoin d’ouvrir des ports sur les FW, seul le flux http est impliqué et surveillé.
Nul doute que la carrière du SAML ne fait que commencer mais c’est déjà un beau début non?
Philippe Macia qui remercie Philippe Glaume pour ses talents de dessinateur.
crédit photo : © Pavel Ignatov - Fotolia.com