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 :
- Fourniture du certificat de l'utilisateur
- Génération de l'assertion
- 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.
Le navigateur de l'utilisateur génére une paire de clef différente pour chaque adresse de l'utilisateur, et ces paires ne sont pas partagées entre les navigateurs. En conséquence, un utilisateur doit obtenir un nouveau certificat à chaque fois qu'un expire, ou à chaque fois qu'il utilise un nouveau navigateur ou ordinateur. Les certificats doivent expirer dans les 24h après leur emission.
Quand un utilisateur séléctionne une identité à utiliser quand il se connécte a un site, le navigateur vérifie s'il a un certificat valide pour cette identité. Si c'est le cas, l'étape est terminée et la navigation continue avec l'étape d'après : la génération de l'assertion. Si le navigateur n'a pas de certificat valide, il essaye d'en obtenir un du domaine associé avec l'identité choisie.
- Le navigateur va chercher le document de support /.well-known/browserid par SSL depuis le domaine de l'identité.
- Avec les informations du document, le navigateur transmet l'adresse e-mail de l'utilisateur et la clef publique associée au fournisseur d'identité et demande un certificat signé.
- Si nécessaire, l'utilisateur est invité à se connecter chez le fournisseur avant la fourniture du certificat.
- Le fournissseur crée, signe et donne le certificat de l'utilisateur au navigateur de l'utilisateur.
Le certificat en main, le navigateur peut continuer avec la génération de l'assertion et la connexion au site.
Génération de l'assertion
Le certificat de l'utilisateur établie un lien vérifiable entre une adresse e-mail et une clef publique. Cependant, seul, ce n'est pas suffisant pour se connecter à un site web : l'utilisateur doit encore monter son lien avec le certificat en prouvant sa possession de la clef privée.
Pour cela, le navigateur de l'utilisateur crée et signe un nouveau document appelé "assertion de l'identité". Il contient :
- Le domaine du site où l'utilisateur veut se connecter.
- Une date d'expiration de l'assertion, généralement moins de 5 minutes après sa création.
Le navigateur présente alors à la fois le certificat de l'utilisateur et l'assertion de l'identité au site web pour la vérification.
Vérification de l'assertion
La combinaison du certificat et de l'assertion est suffisante pour confirmer l'identité d'un utilisateur.
D'abord, le site vérifie le domaine et la date d'expiration dans l'assertion. Si l'assertion est expirée ou destinée a un domaine different, elle est rejetée. Cela évite la réutilisation malicieuse de l'assertion
Ensuite, le site valide la signature de l'assertion avec la clef publique de l'utilisateur contenu dans le certificat. Si la clef et la signature correspondent, le site est assuré que l'utilisateur posséde vraiment la clef associée au certificat.
En dernier, le site va chercher la clef publique du fournisseur depuis son document /.well-known/browserid et verifie qu'il correspond a la signature du certificat de l'utilisateur. Si c'est le cas, le site peut etre certain que le certificat a vraiment ete issue du domaine en question.
Une fois cela vérifié, 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.
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.