Un Fournisseur d'Identité (Identity Provider ou IdP) Persona est un domaine qui enregistre et certifie directement l'identité de ses utilisateurs. Parce que les identités de Persona sont basées sur les adresses email, tous domaine offrant des emails à leurs utilisateurs peut simplement devenir un IdP.
Si vous avez un nom de domaine, vous pouvez devenir un IdP Persona en implémentant un support pour le protocole BrowserID.
If you have a domain name, you can become a Persona IdP by implementing support for the underlying BrowserID protocol.
Le document support IdP
Domains advertise their ability to act as IdPs by publishing a support document at
/.well-known/browserid. This JSON-formatted document contains three values:
public-key: The public part of the domain's cryptographic key.
authentication: The domain's page for asking users to log in.
provisioning: The domain's page for certifying its users' identities.
Websites use the
public-key to verify the authenticity of users' identity assertions.
Browsers use the
provisioning values to obtain certification of their user's identity.
For more information, including how domains can delegate to other IdPs, see the
Comment le navigateur interagit-t-il avec les IdPs ?
Pour montrer l'interaction entre les Navigateurs et les IdPs, nous allons regarder ce qui doit se passer la première fois que
email@example.com essaie de se connecter à un site en utilisant Persona.
- Le navigateur d'alice récupère le document support à l'url
- Alice's browser invisibly loads the
example.comand asks it to sign a public key certifying Alice's identity.
- Before signing the key,
example.comneeds proof that the user really is Alice, so it tells the browser that she needs to authenticate.
- Alice's browser shows Alice the
example.comand she signs in, establishing a new session at
- Alice's browser reloads the
provisioningpage and again asks it to sign a public key certifying Alice's identity.
provisioningpage can verify Alice's identity by inspecting the new session. Satisfied, it signs a certificate containing Alice's public key, her email address, and an expiration date for the certificate.
For the duration of the signed certificate, Alice's browser can create valid identity assertions for
firstname.lastname@example.org whenever she wants to log into a web site with Persona.
Steps 3-5 can be skipped if Alice already has a valid session with
example.com, for example, from logging into her webmail or an intranet portal.
Comment les Sites Web interagissent avec les IdPs ?
Let's say Alice wants to sign in to 123done.org. Her browser would generate and sign an identity assertion containing the certificate from above and present it as proof of her identity.
By comparing Alice's signature on the identity assertion with the public key inside the signed certificate, 123done can be confident that the certificate was issued to the same person that generated the identity assertion. However, 123done still needs to check that the certificate itself is valid by examining its signature.
Because the certificate was issued for
email@example.com, 123done fetches the support document from
https://example.com/.well-known/browserid. It then extracts the
public-key and compares that to the signature on Alice's certificate. If the key matches the signature, 123done knows that the certificate is legitimate and can finish logging Alice in.
Note that 123done never "phoned home" or otherwise revealed Alice's identity when she logged in. Rather, it only needed to request a single, cacheable document from
Security and trust
The BrowserID protocol, and thus Persona, are built on standard public key crytography techniques.