Révision 345085 sur Vue d'ensemble du protocole

  • Raccourci de la révision : Persona/vue_densemble_du_protocole
  • Titre de la révision : Vue d'ensemble du protocole
  • ID de la révision : 345085
  • Créé :
  • Créateur : Flaburgan
  • Version actuelle ? Non
  • Commentaire

Contenu de la révision

Persona est construit sur le protocole BrowserID. Cette page décrit le fonctionnement haut niveau de BrowserID.

Acteurs

Le protocole implique trois acteurs:

  • Les utilisateurs : Les personnes voulant se connecter a des sites web en utilisant Persona.
  • Relying Parties (RPs): Les sites web autorisant la connexion avec Persona.
  • Fournisseur d'identite (IdPs): Domains that can issue Persona-compatible identity certificates to their users.

Persona et le protocole BrowserID utilisent les adresses e-mail comme identifiant, il est donc naturel que les fournisseurs d'e-mail deviennent des IdPs.

Mozilla intervient en tant qu'IdP par défaut pour que les utilisateurs puissent utiliser n'importe quelle adresse e-mail, même si son fournisseur n'est pas un IdP.

Étapes du protocole

Il y a trois étapes distinctes dans le protocole :

  1. Fourniture du certificat de l'utilisateur
  2. Génération de l'assertion
  3. Vérification de l'assertion

Comme prérequis, l'utilisateur doit avoir une adresse e-mail active qu'il souhaite utiliser pour se connecter. Le protocole ne requière pas que le fournisseur d'identité soit un routeur SMTP, mais il requière que l'identité soit au format utilisateur@domaine.

Fourniture du certificat de l'utilisateur

Pour se connecter à un site, un utilisateur doit prouver qu'il est le propriétaire de l'e-mail. La base de cette preuve est un certificat signé et chiffré fourni par l'IdP attestant le lien entre le navigateur d'un utilisateur et une identité donnée par l'IdP.

Comme Persona utilise les techniques standard de cryptographie par clef publique, le certificat de l'utilisateur est signé avec la clef privée de l'IdP et contient :

  • L'adresse e-mail de l'utilisateur.
  • La clef publique de l'utilisateur pour cette adresse sur ce navigateur.
  • La date où le certificat a été publié.
  • La date où le certificat expire.
  • Le nom de domaine de l'IdP.

The user's browser generates a different keypair for each of the user's email addresses, and these keypairs are not shared across browsers. Thus, a user must obtain a fresh certificate whenever one expires, or whenever using a new browser or computer. Certificates must expire within 24 hours of being issued.

When a user selects an identity to use when signing into an RP, the browser checks to see if it has a fresh user certificate for that address. If it does, this step is complete and the browser continues with the assertion generation step below. If the browser does not have a fresh certificate, it attempts to obtain one from the domain associated with the chosen identity.

  1. The browser fetches the /.well-known/browserid support document over SSL from the identity's domain.
  2. Using information from the support document, the browser passes the user's email address and associated public key to the IdP and requests a signed certificate.
  3. If necessary, the user is asked to sign into the IdP before provisioning proceeds.
  4. The IdP creates, signs, and gives a user certificate to the user's browser.

With the certificate in hand, the browser can continue with generating an identity assertion and signing into an RP.

user-certificate-provisioning.png

Génération de l'assertion

The user certificate establishes a verifiable link between an email address and a public key. However, this is alone not enough to log into a website: the user still has to show their connection to the certificate by proving ownership of the private key.

In order to prove ownership of a private key, the user's browser creates and signs a new document called an "identity assertion." It contains:

  • The domain of the RP that the user wants to sign into.
  • An expiration time for the assertion, generally less than five minutes after it was created.

The browser then presents both the user certificate and the identity assertion to the RP for verification.

Vérification de l'assertion

The combination of user certificate and identity assertion is sufficient to confirm a user's identity.

First, the RP checks the domain and expiration time in the assertion. If the assertion is expired or intended for a different domain, it's rejected. This prevents malicious re-use of assertions.

Second, the RP validates the signature on the assertion with the public key inside the user certificate. If the key and signature match, the RP is assured that the current user really does possess the key associated with the certificate.

Last, the RP fetches the IdP's public key from its /.well-known/browserid document and verifies that it matches the signature on the user certificate. If it does, then the RP can be certain that the certificate really was issued by the domain in question.

Once verifying that this is a current login attempt for the proper RP, that the user certificate matches the current user, and that the user certificate is legitimate, the RP is done and can authenticate the user as the identity contained in the certificate.

assertion-generation-and-verify.png

The Persona Fallback IdP

What if a user's email provider doesn't support Persona? In that case, the provisioning step would fail. By convention, the user's browser handles this by asking a trusted third party, https://login.persona.org/, to certify the user's identity on behalf of the unsupported domain. After demonstrating ownership of the address, the user would then receive a certificate issued by the fallback IdP, login.persona.org, rather than the identity's domain.

RPs follow a similar process when validating the assertion: the RP would ultimately request the fallback IdP's public key in order to verify the certificate.

Source de la révision

<p>Persona est construit sur le protocole BrowserID. Cette page décrit le fonctionnement haut niveau de BrowserID.</p>
<h2 id="Acteurs">Acteurs</h2>
<p>Le protocole implique trois acteurs:</p>
<ul>
  <li><strong>Les utilisateurs :</strong> Les personnes voulant se connecter a des sites web en utilisant Persona.</li>
  <li><strong>Relying Parties (RPs): </strong>Les sites web autorisant la connexion avec Persona.</li>
  <li><strong>Fournisseur d</strong>'<strong>identite (IdPs): </strong>Domains that can issue Persona-compatible identity certificates to their users.</li>
</ul>
<p>Persona et le protocole BrowserID utilisent les adresses e-mail comme identifiant, il est donc naturel que les fournisseurs d'e-mail deviennent des IdPs.</p>
<p>Mozilla intervient en tant qu'IdP par défaut pour que les utilisateurs puissent utiliser n'importe quelle adresse e-mail, même si son fournisseur n'est pas un IdP.</p>
<h2 id="Protocol_Steps">Étapes du protocole</h2>
<p>Il y a trois étapes distinctes dans le protocole :</p>
<ol>
  <li>Fourniture du certificat de l'utilisateur</li>
  <li>Génération de l'assertion</li>
  <li>Vérification de l'assertion</li>
</ol>
<p>Comme prérequis, l'utilisateur doit avoir une adresse e-mail active qu'il souhaite utiliser pour se connecter. Le protocole ne requière pas que le fournisseur d'identité soit un routeur SMTP, mais il requière que l'identité soit au format <code>utilisateur@domaine</code>.</p>
<h3 id="User_Certificate_Provisioning">Fourniture du certificat de l'utilisateur</h3>
<p>Pour se connecter à un site, un utilisateur doit prouver qu'il est le propriétaire de l'e-mail. La base de cette preuve est un certificat signé et chiffré fourni par l'IdP attestant le lien entre le navigateur d'un utilisateur et une identité donnée par l'IdP.</p>
<p>Comme Persona utilise les techniques standard de <a href="https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique" title="https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique">cryptographie par clef publique</a>, le certificat de l'utilisateur est signé avec la clef privée de l'IdP et contient :</p>
<ul>
  <li>L'adresse e-mail de l'utilisateur.</li>
  <li>La clef publique de l'utilisateur pour cette adresse sur ce navigateur.</li>
  <li>La date où le certificat a été publié.</li>
  <li>La date où le certificat expire.</li>
  <li>Le nom de domaine de l'IdP.</li>
</ul>
<p>The user's browser generates a different keypair for each of the user's email addresses, and these keypairs are not shared across browsers. Thus, a user must obtain a fresh certificate whenever one expires, or whenever using a new browser or computer. Certificates must expire within 24 hours of being issued.</p>
<p>When a user selects an identity to use when signing into an RP, the browser checks to see if it has a fresh user certificate for that address. If it does, this step is complete and the browser continues with the assertion generation step below. If the browser does not have a fresh certificate, it attempts to obtain one from the domain associated with the chosen identity.</p>
<ol>
  <li>The browser fetches the <a href="/en-US/docs/Persona/.well-known-browserid" title="/en-US/docs/Persona/.well-known-browserid">/.well-known/browserid</a> support document over SSL from the identity's domain.</li>
  <li>Using information from the support document, the browser passes the user's email address and associated public key to the IdP and requests a signed certificate.</li>
  <li>If necessary, the user is asked to sign into the IdP before provisioning proceeds.</li>
  <li>The IdP creates, signs, and gives a user certificate to the user's browser.</li>
</ol>
<p>With the certificate in hand, the browser can continue with generating an identity assertion and signing into an RP.</p>
<p><img alt="user-certificate-provisioning.png" class="internal default" src="/@api/deki/files/6043/=user-certificate-provisioning.png" /></p>
<h3 id="Assertion_Generation">Génération de l'assertion</h3>
<p>The user certificate establishes a verifiable link between an email address and a public key. However, this is alone not enough to log into a website: the user still has to show their connection to the certificate by proving ownership of the private key.</p>
<p>In order to prove ownership of a private key, the user's browser creates and signs a new document called an "identity assertion." It contains:</p>
<ul>
  <li>The domain of the RP that the user wants to sign into.</li>
  <li>An expiration time for the assertion, generally less than five minutes after it was created.</li>
</ul>
<p>The browser then presents both the user certificate and the identity assertion to the RP for verification.</p>
<h3 id="Assertion_Verification">Vérification de l'assertion</h3>
<p>The combination of user certificate and identity assertion is sufficient to confirm a user's identity.</p>
<p>First, the RP checks the domain and expiration time in the assertion. If the assertion is expired or intended for a different domain, it's rejected. This prevents malicious re-use of assertions.</p>
<p>Second, the RP validates the signature on the assertion with the public key inside the user certificate. If the key and signature match, the RP is assured that the current user really does possess the key associated with the certificate.</p>
<p>Last, the RP fetches the IdP's public key from its <a href="/en-US/docs/Persona/.well-known-browserid" title="/en-US/docs/Persona/.well-known-browserid">/.well-known/browserid</a> document and verifies that it matches the signature on the user certificate. If it does, then the RP can be certain that the certificate really was issued by the domain in question.</p>
<p>Once verifying that this is a current login attempt for the proper RP, that the user certificate matches the current user, and that the user certificate is legitimate, the RP is done and can authenticate the user as the identity contained in the certificate.</p>
<p><img alt="assertion-generation-and-verify.png" class="internal default" src="/@api/deki/files/6042/=assertion-generation-and-verify.png" /></p>
<h2 id="The_Persona_Fallback_IdP">The Persona Fallback IdP</h2>
<p>What if a user's email provider doesn't support Persona? In that case, the provisioning step would fail. By convention, the user's browser handles this by asking a trusted third party, <a href="https://login.persona.org/" title="https://login.persona.org/">https://login.persona.org/</a>, to certify the user's identity on behalf of the unsupported domain. After demonstrating ownership of the address, the user would then receive a certificate issued by the fallback IdP, <code>login.persona.org</code>, rather than the identity's domain.</p>
<p>RPs follow a similar process when validating the assertion: the RP would ultimately request the fallback IdP's public key in order to verify the certificate.</p>
Revenir à cette révision