La technique de l’authentification basée sur des assertions (ou « claims-based identity ») est un concept extrêmement intéressant sur lequel est basé SAML. Un des principaux attraits de cette technologie est de permettre la fédération d’identité.
Principes
Très concrètement, un système de jetons de sécurité (STS an anglais, pour Security Token Service) permet la gestion de l’identité d’un utilisateur (et de ses droits). Un des grands intérêts de ce concept est de permettre des relations de confiance entre STS, ce qui permet à différents systèmes d’authentification de propager une identité, et donc de créer des fédérations d’identité.
Les briques
Il y a 3 composants dans un tel système :
- Le fournisseur d’identité, qui est un STS ;
- Un fédérateur d’identité, qui est aussi un STS ;
- Une bibliothèque permettant d’utiliser les jetons, au niveau de l’application cible.
Chez Microsoft
Microsoft permet la mise en œuvre d’un tel mécanisme soit dans son propre système d’information, soit dans le cloud.
Attention : L’Active Directory d’Azure est différent de l’Active Directory classique, car ses fonctionnalités sont limitées à celles utiles pour la gestion d’identité. Il n’y a par exemple rien sur la gestion des politiques des postes Windows rattachés, ce qui est une fonctionnalité très importante dans Active Directory.
Dans le cas où on part d’un fournisseur d’identité interne (ex : Windows Server Active Directory with ADFS) pour se connecter à une application externe via Azure Active Directory, on a besoin d’une synchronisation entre le fournisseur d’identité et le fédérateur. ==> A creuser. A contrario, on peut utiliser Azure AD Access Control en tant que fédérateur d’identité, où la synchronisation est inutile, ce qui est beaucoup plus propre.
