SAML


Le (Security Assertion Markup Language) est un standard ouvert d’authentification qui rend possible l’accès en single sign-on (SSO) à des applications web. Le SSO permet aux utilisateurs de se connecter à de multiples applications et services basés sur le web avec une seule paire d’identifiants. Conçu pour simplifier les expériences de connexion des utilisateurs, le SAML est plus largement utilisé dans les entreprises, et permet aux utilisateurs d’accéder aux applications et aux services pour lesquelles ils payent. 


Surtout, les expériences de connexion SAML sont sécurisées car les identifiants des utilisateurs ne sont jamais transmis. Au lieu de cela, ils sont gérés par des fournisseurs d’identité (IdP) et des fournisseurs de service (SP) :
 

  • L’IdP stocke tous les identifiants et les informations des utilisateurs nécessaires à l’autorisation et il les fournit au SP lorsqu’on le lui demande. C’est la mission de l’IdP de dire « Je connais cette personne et elle doit pouvoir accéder à ces ressources ». 
     

  • Le SP héberge les applications et les services auxquels les utilisateurs veulent accéder. Ces applications ou services peuvent inclure des plateformes de messagerie électronique, comme Google ou Microsoft Office, ou des applis de communication, comme Slack ou Skype. C’est le travail de SP de dire, « Vous pouvez accéder à ces applications ou services pour une durée précisée sans devoir vous reconnecter ».

Lorsqu’un utilisateur tente d’accéder à ces applications ou services, le SP demande à l’IdP de vérifier son identité. L’IdP délivre des assertions SAML, ou des jetons, qui contiennent les informations nécessaires pour confirmer l’identité de l’utilisateur, notamment le moment où les assertions ont été délivrées et les conditions qui rendent ces assertions valides. Après leur réception, le SP donne aux utilisateurs accès aux ressources demandées.


Vous pouvez comparer une expérience de connexion SAML avec l’emprunt d’un livre dans une bibliothèque :
 

  • Vous trouvez un livre que vous voulez lire et vous l’emmenez au guichet.
     

  • Le bibliothécaire vous demande si vous avez votre carte de bibliothèque. Vous répondez, « Non, je viens d’arriver en ville ». Le bibliothécaire déclare, « Alors, je ne peux pas vous laisser emprunter le livre tant que vous n’avez pas de carte de bibliothèque. Vous devez aller au bureau et demander à l’assistant de vous faire une carte pour que vous puissions créer votre dossier et savoir qui vous êtes ».
     

  • Vous allez au bureau et donnez votre permis de conduire à l’assistant. L’assistant enregistre votre nom et votre adresse dans le système de la bibliothèque, crée la carte et vous la donne. Vous ramenez la carte au bibliothécaire, qui la scanne, et vous permet d’emprunt le livre. Vous pouvez alors emmener le livre chez vous pour une durée donnée.

Dans ce scénario, vous vous authentifiez auprès de l’assistant (IdP) en lui présentant votre pièce d’identité. Puis l’assistant (IdP) crée une carte en utilisant les informations qui y figurent. Lorsque vous présentez votre carte au bibliothécaire (SP), il l’utilise pour valider l’emprunt du livre à votre nom.


Cette brève vidéo présente des exemples supplémentaires de la manière dont le SAML est utilisé pour connecter rapidement et en toute sécurité des employés, des partenaires et des clients avec les ressources numériques d’une entreprise.
 

Cloud applications are taking the business world by storm.
Whether you're an enterprise with employees accessing critical applications, Or a business offering Web and Mobile software and services to the marketplace, The cloud is changing the way IT infrastructure is accessed and utilized.
Today, as employees, partners, and customers increasingly rely on cloud applications to Conduct business, they inevitably accumulate numerous and often weak passwords to access There are dozens of cloud applications.
The proliferation of these non-standardized cloud identities, Many of which are forgotten, lost, and easy to steal, adds significant corporate risk and management expense, while also frustrating users.
To help secure Cloud identities, many of today's cloud-based applications increasingly Use a standard known as Security Assertion Markup Language, or SAML.
SAML is a secure XML-based communication Mechanism that shares identities between multiple organizations and applications.
But SAML's power in the cloud is its ability to eliminate most passwords and enable single sign-on Single sign-on.
Single sign-on with SAML gives faster, Easier, and trusted access to cloud applications without storing passwords or Requiring users to log into each application Individually.
Instead of passwords, applications that use SAML accept secure tokens.
Which only reveal what is needed for access to the application.
Since no passwords exist, there is nothing for customers, partners, or employees to forget, lose, or have stolen.
For SAML to work, there are three entities involved.
First is the Identity-Provider-IDP.
An Identity-Provider-IDP maintains a directory of users and an authentication Second is the Service-Provider-SP.
Service Providers run the target website, application, or service.
Identity and Service Providers may be separate organizations, such as when an employee accesses an external cloud application like Salesforce.com, or when consumers access Comcast for online content from programmers like HBO or ESPN.
The third entity is the user who has a known account with the Identity Provider.
SAML simplifies the relationship between these entities and strengthens the security of their Interactions.
A user signs into their company network with Corporate credentials.
When they click a link to access applications or secured content at the Service-Provider-SP's application, the Identity-Provider-IDP generates a SAML token to be sent to the Service-Provider.
The token grants access to APPs and content, but it does not pass any info that could be used by anyone else to access them.
The user is free to navigate securely across the applications they need.
A properly architected and deployed SAML 2.0 solution increases security by eliminating Multiple weak passwords for each cloud application while streamlining the secure Access process.
It delivers substantial business value by Reducing costs and boosting employee productivity.
And it enhances customer satisfaction, all by providing one-click access to Cloud Applications.
Although SAML is one of the fundamental cloud Identity security standards, there are other standards needed to fully construct a secure Cloud identity solution.
To learn more about SAML 2.0 and other security standards, visit the Resource Center at PingOne identity.com.

 

Fonctionnement du SAML


Le SAML est un modèle basé sur XML, ce qui signifie qu’il est extrêmement flexible, qu’il peut être utilisé sur n’importe quelle plateforme, et peut être transmis par une variété de protocoles dont HTTP et SMTP. Les partenaires de la fédération peuvent choisir de partager les informations de leur choix dans une assertion SAML tant que ces informations peuvent être représentées en XML.  


Un processus d’authentification SAML typique fonctionne de la manière suivante :

 

 

  1. L’utilisateur se connecte et demande un accès à l’application ou au service web cible du SP.

  2. Le SP demande les informations d’authentification de l’utilisateur auprès de l’IdP.

  3. L’IdP crée une réponse signée numériquement et en format SAML qui authentifie l’utilisateur. Cette réponse peut être sous la forme d’une assertion SAML ou d’un jeton SAML. La réponse peut aussi inclure des informations sur les privilèges de l’utilisateur.

  4. L’IdP signe l’assertion et l’envoie au SP.

  5. Le SP récupère l’assertion, s’assure de sa validité et authentifie l’utilisateur.

  6. L’utilisateur accède à l’application ou au service du fournisseur d’accès.

 

Les expériences de connexion SAML sont sécurisées car les identifiants des utilisateurs ne sont jamais transmis. Au lieu de cela, des assertions ou des jetons SAML sont utilisés.
 

Les assertions SAML, c’est quoi ?


Les assertions SAML sont des documents XML envoyés depuis un IdP vers un SP qui identifie les utilisateurs, contient des informations pertinentes à leur sujet et précise leurs privilèges dans l’application ou le service cible. Ces messages fournissent aussi des assurances sur le fait que ces informations soient valident et précisent la durée pendant laquelle les utilisateurs peuvent accéder à ces ressources sans devoir se reconnecter.


Les assertions SAML sont principalement utilisées à des fins d’authentification, mais elles peuvent également inclure des informations sur les autorisations :
 

  • Assertions sur l’authentification : Identify users and provide sign-on information, including the time sign-on occurred and the method used to authenticate.

  • Assertions sur les attributs : Contiennent les informations sur les attributs de l’utilisateur qui existent dans les annuaires de l’IdP et du SP, et qui correspondent lors du processus d’authentification.

  • Assertions sur l’autorisation : Indiquent si l’utilisateur est autorisé à accéder à l’application ou au service.  

Le SAML est largement utilisé dans les organisations commerciales pour partager les informations sur l’identité entre les systèmes d’IAM existants et les applications web. La manière dont ces processus sont mis en place dépend de la manière dont les processus de connexion sont initiés, soit par l’IdP, soit par le SP.

 

SSO initié par l’IdP


Le SSO initié par l’IdP se trouve souvent dans les solutions pour les collaborateurs. Les étapes incluses dans ce type de processus figurent sur le diagramme ci-dessous.
 

 

  1. Un utilisateur se connecte au système avec un nom d’utilisateur et un mot de passe, et on lui présente un catalogue d’application qui affiche des icones représentant les applications et les services basées sur le web auxquels ils peuvent accéder. 

  2. L’utilisateur clique sur un icone pour accéder à l’un des ces services ou applications. 

  3. L’IdP crée et signe une assertion SAML qui inclue des informations sur l’identité de l’utilisateur, ainsi que d’autres informations sur les attributs que l’IdP et le SP ont accepté de partager pour authentifier les utilisateurs.

  4. L’IdP envoie ensuite cette assertion au SP via le navigateur de l’utilisateur ou il envoie une référence de cette assertion que le SP peut utiliser en toute sécurité pour récupérer l’assertion.

  5. Le SP valide la signature pour s’assurer que l’assertion SAML venait vraiment de son IdP de confiance et qu’aucune des valeurs de l’assertion n’avaient été modifiées. Il extrait également les informations sur l’identité, l’attribut et l’autorisation sont il a besoin pour savoir si un accès devrait être accordé ou non et quels privilèges l’utilisateur aura.

  6. Les utilisateurs accèdent à l’application ou au service.
     

SSO initié par le SP


Le SSO initié par le SP commence lorsqu’un utilisateur essaye d’accéder directement à une application ou à un service, au lieu de s’authentifier d’abord par l’IdP. Les étapes incluses dans ce type de processus figurent sur le diagramme ci-dessous.
 

 

  1. L’utilisateur tente d’accéder à l’application ou au service.

  2. Le SP renvoie l’utilisateur vers l’IdP pour être authentifié et fournit à l’utilisateur une URL ressource pour accéder à l’application ou au service après l’authentification.

  3. Le SP détermine quel IdP le SP devrait utiliser pour authentifier l’utilisateur. Des méthodes courantes incluent :

    Le SP pourrait demander à l’utilisateur de fournir son adresse électronique et utiliser le domaine de cette adresse, comme bill@pingidentity.com, pour identifier l’IdP approprié.

    Le prestataire de services peut afficher une liste des fournisseurs d’identité qu’il prend en charge et demander à l’utilisateur de choisir celui qui convient.

    L’URL de la ressource pourrait être spécifique à un IdP.

    Le SP pourrait avoir placé un cookie contenant les informations de l’IdP dans le navigateur de l’utilisateur lors de la première connexion effective de l’utilisateur et utilisera ces informations lors des connexions suivantes.

  4. Le SP redirige l’utilisateur vers l’IdP approprié. 

  5. L’IdP authentifie l’identité de l’utilisateur.

  6. L’IdP crée et signe une assertion SAML basée sur XML qui inclue des informations sur l’identité de l’utilisateur, ainsi que d’autres informations sur les attributs que l’IdP et le SP ont accepté de partager pour authentifier les utilisateurs.

  7. L’IdP envoie ensuite cette assertion au SP via le navigateur de l’utilisateur ou il envoie une référence de cette assertion que le SP peut utiliser en toute sécurité pour récupérer l’assertion.

  8. Le SP valide la signature pour s’assurer que l’assertion SAML venait vraiment de son IdP de confiance et qu’aucune des valeurs de l’assertion n’avaient été modifiées. Il extrait également les informations sur l’identité, l’attribut et l’autorisation sont il a besoin pour savoir si un accès devrait être accordé ou non et quels privilèges l’utilisateur aura.

  9. Les utilisateurs accèdent à l’application ou au service.
     

Le SAML est utilisé uniquement pour les applications web


Étant donné qu’il s’agit d’un cadre XML, le SAML est extrêmement polyvalent. Plusieurs connexions SSO différentes avec plusieurs partenaires d’identité différents peuvent être pris en charge avec une seule mise en œuvre, c’est pourquoi on l’utilise souvent dans les entreprises et les organisations commerciales.


Toutefois, le SAML n’est compatible qu’avec le SSO pour les applications et les services basés sur un navigateur. Il ne prend pas en charge le SSO pour les applications mobiles et les applications qui accèdent aux ressources à travers l’API.
 

Ressources Annexes

Lancez-vous dès Aujourd'hui

Contactez-Nous

sales@pingidentity.com

Découvrez comment Ping peut vous aider à offrir des expériences sécurisées aux employés, partenaires et clients dans un monde numérique en constante évolution.