Il existe un petit univers de protocoles/standards d’identit茅 et d’authentification, chacun ayant ses propres avantages et diff茅rences. Cet article explore la comparaison entre SAML et OpenID Connect (OIDC), les sc茅narios dans lesquels l’un ou l’autre protocole serait b茅n茅fique pour votre organisation, et la mani猫re dont chacun contribue 脿 la gestion des identit茅s et des acc猫s (IAM). Chaque approche permet l’authentification unique (SSO), mais il existe des diff茅rences techniques et id茅ologiques distinctes 脿 茅valuer avant de commencer votre projet : SAML est plus sp茅cialis茅 dans l’octroi s茅curis茅 de l’acc猫s 脿 un site Web 脿 travers des domaines, tandis que OIDC fournit un contexte suppl茅mentaire pour les applications mobiles et Web.

SAML vs OpenID (OIDC)

Cet article pourrait simplement proposer une comparaison entre le Security Assertion Markup Language (SAML 2.0) et OAuth (Open Authorization). OAuth est la base d’OIDC, mais OIDC 茅tend la premi猫re avec une couche d’identit茅 pour authentifier vos comptes d’utilisateur existants en utilisant un service d茅centralis茅 qui est g茅r茅 par une fondation 脿 but non lucratif nomm茅e OpenID Foundation. La communaut茅 open source a initi茅 le d茅veloppement d’OpenID en 2005 avec pour objectif que les identit茅s soient d茅centralis茅es et ne soient pas d茅tenues par une tierce partie. Selon la fondation, il y a maintenant plus d’un milliard de comptes d’utilisateurs compatibles avec OpenID sur plus de 50 000 sites Web. Elle g猫re l’infrastructure qui supporte l’authentification OIDC, sa communaut茅 et toute op茅ration l茅gale ou de gouvernance.

SAML 2.0, quant 脿 lui, est une norme ouverte qui assure l’authentification et l’autorisation entre les fournisseurs d’identit茅 (IdP) et les fournisseurs de services (SP) commerciaux et priv茅s depuis 2003. Au d茅part, il s’agissait d’un moyen de mettre en 艙uvre le SSO 脿 l’aide d’un cadre bas茅 sur XML pour permettre aux fournisseurs d’identit茅 et aux services d’exister s茅par茅ment les uns des autres, avec une gestion centralis茅e des utilisateurs. Commen莽ons par examiner le fonctionnement de SAML, en l’explorant composant par composant.

Comment fonctionne SAML ?

SAML est une norme ouverte d’authentification (et d’autorisation, le cas 茅ch茅ant) qui fournit un acc猫s SSO aux applications Web par le biais de la f茅d茅ration d’identit茅s. SAML relaie les informations d’identification des utilisateurs depuis un IdP qui poss猫de et maintient les identit茅s pour v茅rifier les droits d’acc猫s et les SP. Les fournisseurs de services exigent une authentification avant d’accorder aux utilisateurs l’acc猫s 脿 la ressource. Chaque utilisateur (ou groupe) poss猫de des attributs qui d茅crivent les informations de son profil et affirment ce 脿 quoi il est exactement autoris茅 脿 acc茅der.

SAML utilise des documents de m茅tadonn茅es (jetons SAML) en langage de balisage extensible (XML) pour un processus d’assertion permettant de v茅rifier l’identit茅 d’un utilisateur et ses privil猫ges d’acc猫s.

Les d茅veloppeurs utilisent des plugins SAML dans les applications ou les ressources pour une exp茅rience de connexion SSO qui garantit que les pratiques de s茅curit茅 sont respect茅es et que les informations d’identification/assertions d茅terminent qui peut acc茅der 脿 une application. En outre, SAML peut 锚tre utilis茅 pour contr么ler les ressources auxquelles une identit茅 peut acc茅der dans une application.

SAML est compos茅 de plusieurs 茅l茅ments de base qui permettent d’茅changer des informations sur les utilisateurs pour le contr么le d’acc猫s, notamment l’IdP, le client, les attributs et le SP.

Fournisseur d’identit茅s (IdP)

Un IdP est un service qui maintient et g猫re les identit茅s num茅riques pour v茅rifier les informations d’identification des utilisateurs dans les applications, les r茅seaux et les services Web. Son r么le principal est de prot茅ger l’int茅grit茅 des informations d’identification des utilisateurs et de f茅d茅rer l’identit茅 des utilisateurs lorsque des connexions SSO sont souhait茅es.

Client

Les clients sont vos utilisateurs qui s’authentifient dans un service en utilisant les informations d’identification g茅r茅es par un IdP. Par exemple, votre employeur peut utiliser SAML pour l’acc猫s SSO aux services dont vous avez besoin pour travailler, en utilisant l’adresse 茅lectronique et le mot de passe de votre entreprise.

Attribut

SAML transf猫re des messages, appel茅s assertions, d’un IdP 脿 un fournisseur de services. Ces assertions d茅finissent toutes les exigences de s茅curit茅 pertinentes pour la transaction en authentifiant, en autorisant et en d茅terminant le niveau des autorisations qu’un client recevra. Des attributs tels que 芦 dept 禄, 芦 email 禄 et 芦 role 禄 sont utilis茅s pour appliquer la gestion et le contr么le des acc猫s. Parfois, des attributs personnalis茅s sont utilis茅s afin que SAML puisse 锚tre 茅tendu puis utilis茅 avec des logiciels personnalis茅s.

Fournisseur de services (SP)

Les fournisseurs de services sont une ressource 脿 laquelle les utilisateurs s’authentifient 脿 l’aide de SAML SSO, g茅n茅ralement un site Web ou une application priv茅e. Ils re莽oivent, acceptent ou refusent les assertions des IdP pour chaque profil client avant d’accorder l’acc猫s aux utilisateurs. Les SP envoient des requ锚tes aux IdP pour commencer le processus d’authentification, et l’assertion du client est re莽ue en r茅ponse. Le processus est parfois invers茅 lorsqu’un IdP initie le flux d’ouverture de session pour confirmer l’identit茅 de l’utilisateur. Il peut 锚tre initi茅 dans les deux sens.

Comment fonctionne OIDC

OIDC 茅tend le protocole OAuth de sorte que les services clients (vos applications) v茅rifient l’identit茅 des utilisateurs et 茅changent des informations de profil par l’interm茅diaire de fournisseurs OpenID via des API RESTful qui envoient des jetons Web JSON (JWT) pour partager des informations pendant le processus d’authentification. Les fournisseurs sont essentiellement des serveurs d’authentification. De nombreux d茅veloppeurs sont attir茅s par cette approche car elle est hautement 茅volutive, flexible sur toutes les plateformes et relativement simple 脿 mettre en 艙uvre. Ses principaux composants sont un flux d’identification unique de l’utilisateur avec des bases OAuth.

Authentification de l’utilisateur

Un propri茅taire de ressources (vos utilisateurs) s’authentifie et est autoris茅 脿 acc茅der 脿 une application client par le biais d’un serveur d’autorisation qui accorde un jeton d’acc猫s permettant aux applications de recevoir des informations consenties depuis un point de terminaison UserInfo. Ce dernier est une ressource prot茅g茅e trouv茅e sur un serveur OpenID qui contient des d茅clarations (assertions) sur chaque utilisateur dans un objet JSON. Les informations d’authentification sont ensuite encod茅es dans un jeton d’identification re莽u par l’application. Ces informations sont mises en cache pour des performances 茅volutives et personnalisent l’exp茅rience de l’utilisateur final.

Fond茅 sur le protocole OAuth 2.0

L’OIDC repose sur le cadre OAuth 2.0, une norme qui permet aux applications et services tiers d’acc茅der aux ressources d’identification des utilisateurs. Aucune information d’identification de l’utilisateur n’est envoy茅e sur le r茅seau ou stock茅e sur des serveurs tiers, ce qui accro卯t la s茅curit茅 et la facilit茅 d’utilisation pour les administrateurs informatiques.

Similitudes

• Les deux cadres sont des protocoles d’identit茅 qui rendent le SSO possible.
• Les deux cadres sont s没rs, bien document茅s et matures.
• Les utilisateurs s’authentifient via un IdP, g茅n茅ralement une fois, et peuvent ensuite acc茅der 脿 d’autres applications qui 芦 font confiance 禄 脿 l’IdP. Certains services de Zero Trust s’authentifient 脿 chaque point de la cha卯ne et v茅rifient p茅riodiquement l’acc猫s 脿 l’aide d’une autre m茅thode d’authentification.
• Le flux de travail de connexion peut sembler tr猫s similaire aux yeux de l’utilisateur final, qui n’a aucune connaissance des multiples techniques vari茅es qui se d茅ploient en coulisses.

顿颈蹿蹿茅谤别苍肠别蝉

• De nombreux d茅veloppeurs pensent qu’OpenID Connect est plus simple 脿 mettre en 艙uvre car il n’y a pas de manipulation XML.
• OpenID ne dispose pas de donn茅es d’autorisation des utilisateurs (telles que les permissions) et se concentre principalement sur l’affirmation d’identit茅. SAML est un 茅change de donn茅es d’identit茅 et est tr猫s riche en fonctionnalit茅s.
• L’authentification est d茅centralis茅e avec OpenID.
• SAML a recours 脿 des assertions par opposition 脿 l’architecture de jetons d’identification utilis茅e par OpenID et OAuth.
• OIDC est con莽u pour les charges de travail des API et peut 锚tre utilis茅 pour s茅curiser les API.

Cas d’utilisation

Les d茅veloppeurs et les services informatiques doivent choisir la solution qui convient le mieux 脿 leur(s) cas d’utilisation particuliers. Cependant, il est parfois possible d’en utiliser plusieurs simultan茅ment. Quoi qu’il en soit, les cas d’utilisation se sont d茅velopp茅s de mani猫re organique, l’OIDC 茅tant utilis茅 pour les applications Web et mobiles de canal arri猫re qui demandent des jetons d’acc猫s.

SAML est presque toujours utilis茅 pour l’acc猫s au site Web du canal frontal o霉 les utilisateurs sont ceux qui d茅clenchent l’authentification de l’application. Dans ce dernier cas, on suppose que les applications clientes (un service Web) fonctionnent 脿 partir de appareils diff茅rents de ceux du propri茅taire de la ressource (vous). Vous trouverez ci-dessous quelques directives g茅n茅rales pour les cas d’utilisation :

• Une application mobile utilise g茅n茅ralement un service tel que l’OIDC, parce qu’il est plus l茅ger et que de nombreuses fonctions utilis茅es par les d茅veloppeurs sont pr茅茅tablies ou disponibles dans des biblioth猫ques compl茅mentaires.
• Les applications qui int猫grent SAML sont une 茅vidence, il suffit d’utiliser SAML.
• Utilisez SAML pour acc茅der aux applications d’entreprise via un portail.
• La protection des API ou l’exposition des API sont des services qui n茅cessiteront OAuth 2.0 ou OIDC.
• Les entreprises privil茅gient parfois SAML en raison de sa capacit茅 de personnalisation et de sa priorit茅 accord茅e 脿 l’茅change s茅curis茅 de donn茅es. Les secteurs r茅glement茅s devraient presque toujours opter pour SAML afin de prot茅ger les informations sensibles des utilisateurs.

Utilisation conjointe d’OIDC et de SAML

Ces protocoles ne s’excluent pas mutuellement. Envisagez d’utiliser SAML pour le SSO d’entreprise afin de s茅curiser l’acc猫s aux ressources de votre organisation et OIDC pour les cas d’utilisation mobile qui ont des exigences d’茅volutivit茅 茅lev茅es. Chacun de ces protocoles pr茅sente des avantages inh茅rents et chacun peut fournir des services de SSO.

En savoir plus

Si vous souhaitez en savoir plus sur la mani猫re de combiner le meilleur des deux mondes, en utilisant SAML et OIDC, contactez-nous. La plateforme 探花大神 utilise les attributs des utilisateurs pour faire des suggestions intelligentes d’appartenance 脿 un groupe, et bien plus encore. Vous pouvez 茅galement explorer ce que 探花大神 a 脿 offrir en programmant une d茅monstration personnalis茅e gratuite.