From da78a9e329e272dedb2400b79a3bdeebff387d47 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:17 -0500 Subject: initial commit --- .../persona/.well-known-browserid/index.html | 44 ++++ .../compatibilit\303\240_con_i_browser/index.html" | 86 +++++++ files/it/archive/mozilla/persona/index.html | 175 +++++++++++++ .../persona/internationalization/index.html | 49 ++++ .../persona/libraries_and_plugins/index.html | 195 +++++++++++++++ .../it/archive/mozilla/persona/marchio/index.html | 13 + .../archive/mozilla/persona/quick_setup/index.html | 273 +++++++++++++++++++++ .../persona/remote_verification_api/index.html | 171 +++++++++++++ .../persona/security_considerations/index.html | 55 +++++ .../persona/the_implementor_s_guide/index.html | 57 +++++ .../the_implementor_s_guide/testing/index.html | 8 + .../persona/the_navigator.id_api/index.html | 148 +++++++++++ .../archive/mozilla/persona/why_persona/index.html | 59 +++++ 13 files changed, 1333 insertions(+) create mode 100644 files/it/archive/mozilla/persona/.well-known-browserid/index.html create mode 100644 "files/it/archive/mozilla/persona/compatibilit\303\240_con_i_browser/index.html" create mode 100644 files/it/archive/mozilla/persona/index.html create mode 100644 files/it/archive/mozilla/persona/internationalization/index.html create mode 100644 files/it/archive/mozilla/persona/libraries_and_plugins/index.html create mode 100644 files/it/archive/mozilla/persona/marchio/index.html create mode 100644 files/it/archive/mozilla/persona/quick_setup/index.html create mode 100644 files/it/archive/mozilla/persona/remote_verification_api/index.html create mode 100644 files/it/archive/mozilla/persona/security_considerations/index.html create mode 100644 files/it/archive/mozilla/persona/the_implementor_s_guide/index.html create mode 100644 files/it/archive/mozilla/persona/the_implementor_s_guide/testing/index.html create mode 100644 files/it/archive/mozilla/persona/the_navigator.id_api/index.html create mode 100644 files/it/archive/mozilla/persona/why_persona/index.html (limited to 'files/it/archive/mozilla/persona') diff --git a/files/it/archive/mozilla/persona/.well-known-browserid/index.html b/files/it/archive/mozilla/persona/.well-known-browserid/index.html new file mode 100644 index 0000000000..66614c5b3d --- /dev/null +++ b/files/it/archive/mozilla/persona/.well-known-browserid/index.html @@ -0,0 +1,44 @@ +--- +title: .well-known-browserid +slug: Archive/Mozilla/Persona/.well-known-browserid +translation_of: Archive/Mozilla/Persona/.well-known-browserid +--- +

Domains advertise their ability to act as Persona Identity Providers (IdPs) by publishing a support document at /.well-known/browserid. This JSON-formatted document must be served over HTTPS with the content type application/json.

+

This document may either specify how to provision and authenticate users, or may delegate its authority to another Identity Provider.

+

Note: you should also consult the BrowserID Protocol Specification as the authoritative technical reference.

+

Basic Support

+

A domain which directly acts an an IdP must provide three values in its support document:

+ +

Example /.well-known/browserid file:

+
{
+    "public-key": {
+        "algorithm": "RS",
+        "n": "82818905405105134410187227495885391609221288015566078542117409373192106382993306537273677557482085204736975067567111831005921322991127165013340443563713385983456311886801211241492470711576322130577278575529202840052753612576061450560588102139907846854501252327551303482213505265853706269864950437458242988327",
+        "e": "65537"
+    },
+    "authentication": "/browserid/sign_in.html",
+    "provisioning": "/browserid/provision.html"
+}
+

Delegated Support

+

HTTP redirects and other means of "moving" a /.well-known/browserid file are not permitted. If an IdP would like to delegate to another domain for authentication and provisioning, it may publish a support document which only contains an authority entry.

+

Example /.well-known/browserid:

+
{
+  "authority": "subdomain.example.com"
+}
+
+

Then subdomain.example.com would host its own support document, as per the example above.

+

The authority field is specified as a hostname plus, optionally, a port. It may not contain a path. So "example.com", "subdomain.example.com", and "subdomain.example.com:8080" are all valid, but "subdomain.example.com/login" is not.

+

A domain may delegate to any other domain, so long as the other domain publishes a /.well-known/browserid document.

+

Checklist

+ +

Many of these can be tested automatically with the check_primary_support script from the Persona codebase.

diff --git "a/files/it/archive/mozilla/persona/compatibilit\303\240_con_i_browser/index.html" "b/files/it/archive/mozilla/persona/compatibilit\303\240_con_i_browser/index.html" new file mode 100644 index 0000000000..33af33db7c --- /dev/null +++ "b/files/it/archive/mozilla/persona/compatibilit\303\240_con_i_browser/index.html" @@ -0,0 +1,86 @@ +--- +title: Browser compatibility +slug: Archive/Mozilla/Persona/Compatibilità_con_i_Browser +translation_of: Archive/Mozilla/Persona/Browser_compatibility +--- +

Browser supportati

+

Persona è sviluppato, testato e supportato dai seguenti browser. Grazie alla libreria JavaScript multipiattaforma di Persona, gli utenti non hanno bisogno di componenti aggiuntivi per usare il sistema.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Browser Desktop
Internet Explorer8.0*, 9.0†, 10.0** (vedi Modalità Compatibilità più sotto)
FirefoxVersione Stabile Corrente, Beta, Aurora, Nightly, e Extended Support Releases
+ Versione Stabile Precedente
ChromeUltima Versione Stabile
SafariUltima Versione Stabile
OperaUltima Versione Stabile‡
Browser iOS
Safari MobileiOS 5.x — 6.x
Browser Android
Browser Predefinito2.2 — 4.x
FirefoxVersione Stabile Corrente, Beta, Aurora, Nightly
+ Versione Stabile Precedente
ChromeUltima Versione Stabile
+

*: Per Windows XP. †: Per Windows Vista e Windows 7. **Windows 8.  ‡: Tempo permettendo.

+

Browser non supportati

+ +

"Modalità compatibilità" di Internet Explorer

+

Dalla versione 8.0 in poi, Internet Explorer supporta la cosiddetta Modalità Compatibilità, nella quale il browser può emulare una versione del browser precedente alla 8.0 nel renderizzare una pagina. Questa funzionalità può essere controllata in tre modi

+
    +
  1. come impostazione locale del browser
    2. +
  2. basandosi sulla presenza e il valore della dichiarazione DOCTYPE nella pagina
    3. +
  3. come istruzione inviata dal sito stesso, utilizzando l'intestazione "X-UA-Compatible" come intestazione HTTP o tramite l'uso del tag <meta> nella pagina. Questo metodo bypassa gli altri due.
    4. +
+

Poiché le versioni di Internet Explorer precedenti alla 8.0 non sono supportate da Persona, qualsiasi versione di Internet Explorer configurata per emulare versioni pre-8.0 non funzioneranno con Persona. Il problema solitamente si verifica per una di queste ragioni:

+ +

Per ulteriori informazioni, vedere "Comprendere le Modalità Compatibilità in Internet Explorer 8" e "Complicazioni su IE8 e IE9".

+

Altri Browser

+

Anche se non esplicitamente supportato, qualunque browser includa sia {{ domxref("window.postMessage()") }} che {{ domxref("Storage", "localStorage") }} dovrebbe funzionare. Queste API sono disponibli in tutti i principali browser da Marzo 2010.

+

Problemi noti

+ diff --git a/files/it/archive/mozilla/persona/index.html b/files/it/archive/mozilla/persona/index.html new file mode 100644 index 0000000000..ae58667799 --- /dev/null +++ b/files/it/archive/mozilla/persona/index.html @@ -0,0 +1,175 @@ +--- +title: Persona +slug: Archive/Mozilla/Persona +translation_of: Archive/Mozilla/Persona +--- +
+
Sistema di autenticazione singola semplice e attento alla privacy: permetti ai tuoi utenti di autenticarsi sul tuo sito con il proprio indirizzo email e liberati dalla gestione delle password.
+ +
+

Mozilla Persona è un sistema di login per il Web utilizzabile con qualsiasi browser, facile da usare e da integrare. Funziona su tutti i principali browser e puoi iniziare a usarlo subito.

+ +

Perché dovresti usare Persona sul tuo sito?

+ +
    +
  1. Persona elimina completamente le password per i singoli siti, liberando l'utente dalla necessità di creare, gestire e tenere al sicuro le password.
    2. +
  2. Persona è facile da usare. In solo due clic, un utente Persona può autenticarsi su un nuovo sito, come Voost, aggirando gli ostacoli associati alla creazione di un account.
    3. +
  3. Persona è facile da implementare. Gli sviluppatori possono aggiungere Persona sul proprio sito in mezza giornata.
    4. +
  4. Non c'è alcun vincolo. Gli sviluppatori ottengono da tutti i loro utenti un indirizzo verificato, mentre gli utenti possono utilizzare qualsiasi indirizzo email con Persona.
    5. +
+ +

Inoltre, Persona può solo migliorare: è sviluppato su un protocollo aperto e decentralizzato, che è progettato per permettere un'integrazione diretta all'interno dei browser e il supporto nativo da parte dei provider di posta. I siti che implementano Persona oggi, otterranno automaticamente questi miglioramenti, senza bisogno di modificare il proprio codice.

+
+ +
+
+

Usare Persona sul proprio sito

+ + +
+

Per iniziare

+ +
+
Perché Persona?
+
Che cosa ha di speciale persona rispetto ad altri sistemi di identificazione e autenticazione.
+
Preparazione veloce
+
Una guida passo passo che insegna come aggiungere Persona al proprio sito web.
+
+ +

Riferimento delle API

+ +
+
La API navigator.id
+
L'API del browser.
+
Riferimento dell'API di verifica
+
L'API di verifica remota.
+
+
+ +
+

Guide

+ +
+
Considerazioni sulla sicurezza
+
Pratiche e tecniche per assicurarsi che il proprio deploy di Persona sia sicuro.
+
Compatibilità con i browser
+
Scopri esattamente quali browser supportano Persona.
+
Internazionalizzazione
+
Scopri come Persona gestisce lingue diverse.
+
Guida dell'implementatore
+
Suggerimenti dai siti che hanno già aggiunto il supporto a Persona.
+
+
+ +
+

Risorse

+ +
+
Librerie e plugin
+
Trova librerie semplici da aggiungere per il tuo linguaggio di programmazione, framework web, blog o content management system preferito.
+
Ricette per Persona
+
Codice sorgente di esempio per i siti che usano Persona. Include esempi per C# (MVC3), PHP, Node.js e altri.
+
Linee guida per l'interfaccia utente
+
Come presentare l'autenticazione con Persona ai propri utenti.
+
+
+
+ +
+

Diventare un Identity Provider

+ +

Se sei un provider di email o un servizio di provider di identificazione, controlla i link qui sotto per scoprire come diventare un Identity Provider di Persona.

+ +
+
+
+
Panoramica di Identity Provider
+
Una visione di alto livello su Persona Identity Providers.
+
+
+ +
+
+
Implementare un Identity Provider
+
Una guida minuziosa ai dettagli tecnici su come diventare un Identity Provider.
+
+
+ +
+
+
.well-known/browserid
+
Una panoramica sul file .well-known/browserid, che gli Identity Provider utilizzano per indicare il proprio supporto al protocollo.
+
+
+
+ +
+

Il progetto Persona

+ +
+
+
+
Glossario
+
Definizioni sulla terminologia di BrowserID e Persona.
+
FAQ
+
Risposte alle domande più comuni.
+
Visione di insieme del protocollo
+
Una visione di insieme tecnica a medio livello del protocollo BrowserID sottostante.
+
+
+ +
+
+
Crittografia
+
Informazioni riguardo i concetti crittografici che sono alla base di Persona e BrowserID.
+
Specifiche
+
Qui si trovano i dettagli più tecnici.
+
+
+ +
+
+
Il sito di Persona
+
Per far funzionare Persona stiamo ospitando tre servizi su https://login.persona.org: un Identity Provider per quando gli altri non funzionano, un implementazione delle API {{domxref("navigator.id")}}, e un servizio di veifica.
+
Il codice sorgente di Persona
+
Il codice sorgete di persona è su GitHub. Le pull request sono le benvenute!
+
+
+
+ + + +
    +
  1. Usare persona su un sito + +
      +
    1. Perché usare Persona?
      2. +
    2. Per cominciare
      3. +
    3. Consigli per implementare Persona
      4. +
    4. Considerazioni sulla sicurezza
      5. +
    5. Compatibilità con i browser
      6. +
    6. Internazionalizzazione
      7. +
    7. L'API navigator.id
      8. +
    8. L'API di verifica remota
      9. +
    9. Librerie e plugin
      10. +
    10. Linee guida per l'interfaccia utente
      11. +
    +
    2. +
  2. Diventare un Identity Provider +
      +
    1. Visione di insieme di Identity Provider
      2. +
    2. Implementare un Identity Provider
      3. +
    3. Formato .well-known-browserid
      4. +
    +
    3. +
  3. Il progetto Persona +
      +
    1. Glossario
      2. +
    2. FAQ
      3. +
    3. Servizi ospitati di Persona
      4. +
    4. Visione di insieme del protocollo
      5. +
    5. Crittografia
      6. +
    +
    4. +
+
diff --git a/files/it/archive/mozilla/persona/internationalization/index.html b/files/it/archive/mozilla/persona/internationalization/index.html new file mode 100644 index 0000000000..29ebccf30a --- /dev/null +++ b/files/it/archive/mozilla/persona/internationalization/index.html @@ -0,0 +1,49 @@ +--- +title: Internazionalizzazione +slug: Archive/Mozilla/Persona/Internationalization +translation_of: Archive/Mozilla/Persona/Internationalization +--- +

What's localized in Persona

+

In the future, the user interface for signing into sites with Persona will be directly integrated into the browser, and thus localized along with the browser's own localization. For browsers without integrated support, Persona's user interface consists of a series of dialogs served from login.persona.org. These dialogs are translated by a team of community volunteers, and more than 45 locales are currently enabled in production.

+

How Persona chooses localizations

+

The Persona service selects a language using the Accept-Language header sent alongside the browser's requests. The algorithm used to map an Accept-Language header to a language is the same as that used by mozilla.org:

+
    +
  1. For each language tag in the Accept-Language header: +
      +
    • check if we have an exact match for the language identified by the language tag
      • +
    • check if we have an exact match for the language identified by the first part of the language tag
      • +
    +
    2. +
  2. If a match can't be made using rule (1), fall back to en-US. However, en or en-US is almost always the last accept-lang header sent by most browsers.
    3. +
+

For example, the table below lists the language selected for various Accept-Language headers, if the following locales were supported: en-US, es, es-MX:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Accept-Language HeaderSelected language
es-AR,es;q=0.8,en-us;q=0.5es
es-MX,es;q=0.8,en-us;q=0.5es-MX
es-es,en-us;q=0.5en-US
es-esen-US
+

There is currently no way for a website to force the dialogs to appear in another language. This is because the Persona UI is logically (and in future native implementations will actually be) part of the browser UI, so its language should be consistent with the language selected for the browser.

+

How you can help

+

Persona uses Mozilla Verbatim to help volunteers create new translations. If you want to help out, read about getting started with Verbatim and check out the "BrowserID" project on Verbatim.

+

 

diff --git a/files/it/archive/mozilla/persona/libraries_and_plugins/index.html b/files/it/archive/mozilla/persona/libraries_and_plugins/index.html new file mode 100644 index 0000000000..2e11654b68 --- /dev/null +++ b/files/it/archive/mozilla/persona/libraries_and_plugins/index.html @@ -0,0 +1,195 @@ +--- +title: Librerie e plugin +slug: Archive/Mozilla/Persona/Libraries_and_plugins +translation_of: Archive/Mozilla/Persona/Libraries_and_plugins +--- +

Want to use Persona on your website or blog? Implementing Persona from scratch is easy, but the plugins and libraries listed here might get you going faster!
+
+ This page lists three types of libraries:
+
+ 1. Plugins that integrate Persona with existing frameworks and content management systems
+ 2. Utility libraries that are useful when building new plugins or integrating Persona into a site from scratch
+ 3. Everything else related to Persona, including libraries for turning your domain into a Persona Identity Provider
+
+ This is a community-maintained list. If you've created a library or plugin, please add it to this page.

+
+ This page is currently being revised and some plugins may be out of date. Please review plugins before using them.
+

Plugins

+

Clojure

+ +

Cold Fusion

+ +

Haskell

+ +

Java

+ +

JavaScript

+ +

Node.js

+ +

PHP

+ +

Python

+ +

Ruby

+ +

Perl

+ +

Erlang

+ +

Miscellaneous

+ +

Didn't see your language or framework listed? LoginRadius, a hosted authentication widget, offers Persona integration for a wide variety of platforms.

+

Verification Libraries

+

Go

+ +

Java

+ +

Node.js

+ +

Perl

+ +

PHP

+ +

Ruby

+ +

Utility Libraries

+

C

+ +

Go

+ +

Haskell

+ +

.Net

+ +

Node.js

+ +

PHP

+ +

Python

+ +

Ur/Web

+ +

Everything Else

+

Perl

+ +

Python

+ +

Ruby

+ +

PHP

+ +

Racket

+ +

Orchard CMS

+ diff --git a/files/it/archive/mozilla/persona/marchio/index.html b/files/it/archive/mozilla/persona/marchio/index.html new file mode 100644 index 0000000000..e7ac828695 --- /dev/null +++ b/files/it/archive/mozilla/persona/marchio/index.html @@ -0,0 +1,13 @@ +--- +title: Personalizzazione dei bottoni +slug: Archive/Mozilla/Persona/marchio +translation_of: Archive/Mozilla/Persona/User_interface_guidelines +--- +

I bottoni per l'accesso con Persona

+

Immagini

+

I bottoni "Accesso con Persona" sono disponibili in tre colorazioni:

+

Scarica (.psd)

+

Versioni basate su CSS

+

Sawyer Hollenshead ha creato un set eccellente di bottoni basati su CSS. Demo / Scarica (.zip)

+

Ulteriori informazioni

+

Puoi trovare ulteriori informazioni sul visual design di Persona alla pagina style primer di Sean Martell (disponibile solo in Inglese).

diff --git a/files/it/archive/mozilla/persona/quick_setup/index.html b/files/it/archive/mozilla/persona/quick_setup/index.html new file mode 100644 index 0000000000..076e004ca1 --- /dev/null +++ b/files/it/archive/mozilla/persona/quick_setup/index.html @@ -0,0 +1,273 @@ +--- +title: Setup veloce +slug: Archive/Mozilla/Persona/Quick_Setup +translation_of: Archive/Mozilla/Persona/Quick_Setup +--- +

Aggiungere il sistema di login Persona al tuo sito richiede solo cinque passaggi:

+ +
    +
  1. Includere la libreria JavaScript di Persona nelle tue pagine.
    2. +
  2. Aggiungere i bottoni di “login” e “logout”.
    3. +
  3. Watch for login and logout actions.
    4. +
  4. Verificare le credenziali dell'utente.
    5. +
  5. Rivedere le best practices.
    6. +
+ +

Dovresti riuscire a implementarlo e farlo funzionare in un solo pomeriggio, ma innanzitutto: se hai intenzione di usare Persona sul tuo sito, per piacere prendi un momento per sottoscrivere la mailing list Persona notices. Genera un traffico estremamente basso, viene solo usata per annunciare cambiamenti o questioni di sicurezza che potrebbero avere un impatto negativo sul tuo sito.

+ +

Step 1: Includi la libreria di Persona

+ +

Persona é progettato per essere indipendente dal browser e funzionare bene su tutti i maggiori browser per desktop e mobile.

+ +

Ci aspettiamo che in futuro i browser supporteranno nativamente Persona, ma nel frattempo forniamo una libreria JavaScript che implementa completamente l'interfaccia utente e la parte client-side del protocollo. Includendo questa libreria, i tuoi utenti saranno in grado di registrarsi con Persona anche se il loro browser non lo supporta nativamente.

+ +

Questa libreria è caricata nella tua pagina, Persona funziona necessita di ({{ domxref("navigator.id.watch()", "watch()") }}, {{ domxref("navigator.id.request()", "request()") }}, and {{ domxref("navigator.id.logout()", "logout()") }}) sarà disponibile al mondo navigator.id object.

+ +

Includere la libreria JavaScript di Persona, tu puoi mettere questo script tag in fondo al body della pagina:

+ +
<script src="https://login.persona.org/include.js"></script>
+
+ +

Devi includere questo script in ogni pagina dove gli utenti utilizzeranno Persona {{ domxref("navigator.id") }}. Ciò perchè Persona è ancora in svilippo, tu non dovresti auto accogliere il file include.js

+ +

Step 2: Aggiungere il bottone di login e di logout

+ +

Because Persona is designed as a DOM API, you must call functions when a user clicks a login or logout button on your site. To open the Persona dialog and prompt the user to log in, you should invoke {{ domxref("navigator.id.request()") }}. For logout, invoke {{ domxref("navigator.id.logout()") }}. Note, the call to {{ domxref("navigator.id.logout()", "logout()") }} must be made in the click handler of the logout button.

+ +

For example:

+ +
var signinLink = document.getElementById('signin');
+if (signinLink) {
+  signinLink.onclick = function() { navigator.id.request(); };
+}
+
+var signoutLink = document.getElementById('signout');
+if (signoutLink) {
+  signoutLink.onclick = function() { navigator.id.logout(); };
+}
+
+ +

What should those buttons look like? Check out our Branding Resources page for premade images and CSS-based buttons!

+ +

Step 3: Watch for login and logout actions

+ +

For Persona to function, you need to tell it what to do when a user logs in or out. This is done by calling the {{ domxref("navigator.id.watch()") }} function and supplying three parameters:

+ +
    +
  1. +

    The email address of the user currently logged into your site from this computer, or null if no one is logged in. For example, you might examine the browser's cookies to determine who is signed in.

    +
    2. +
  2. +

    A function to invoke when an onlogin action is triggered. This function is passed a single parameter, an “identity assertion,” which must be verified.

    +
    3. +
  3. +

    A function to invoke when an onlogout action is triggered. This function is not passed any parameters.

    +
    4. +
+ +
+

Note: You must always include both onlogin and onlogout when you call {{ domxref("navigator.id.watch()") }}.

+
+ +

For example, if you currently think Bob is logged into your site, you might do this:

+ +
var currentUser = 'bob@example.com';
+
+navigator.id.watch({
+  loggedInUser: currentUser,
+  onlogin: function(assertion) {
+    // A user has logged in! Here you need to:
+    // 1. Send the assertion to your backend for verification and to create a session.
+    // 2. Update your UI.
+    $.ajax({ /* <-- This example uses jQuery, but you can use whatever you'd like */
+      type: 'POST',
+      url: '/auth/login', // This is a URL on your website.
+      data: {assertion: assertion},
+      success: function(res, status, xhr) { window.location.reload(); },
+      error: function(xhr, status, err) { alert("Login failure: " + err); }
+    });
+  },
+  onlogout: function() {
+    // A user has logged out! Here you need to:
+    // Tear down the user's session by redirecting the user or making a call to your backend.
+    // Also, make sure loggedInUser will get set to null on the next page load.
+    // (That's a literal JavaScript null. Not false, 0, or undefined. null.)
+    $.ajax({
+      type: 'POST',
+      url: '/auth/logout', // This is a URL on your website.
+      success: function(res, status, xhr) { window.location.reload(); },
+      error: function(xhr, status, err) { alert("Logout failure: " + err); }
+    });
+  }
+});
+
+ +

In this example, both onlogin and onlogout are implemented by making an asynchronous POST request to your site’s backend. The backend then logs the user in or out, usually by setting or deleting information in a session cookie. Then, if everything checks out, the page reloads to take into account the new login state.

+ +

You can, of course, use AJAX to implement this without reloading or redirecting, but that’s beyond the scope of this tutorial.

+ +

Here is another example, this time not using jQuery.

+ +
function simpleXhrSentinel(xhr) {
+    return function() {
+        if (xhr.readyState == 4) {
+            if (xhr.status == 200)
+                // reload page to reflect new login state
+                window.location.reload();
+            else
+                alert("XMLHttpRequest error: " + xhr.status); } } }
+
+function verifyAssertion(assertion) {
+    // Your backend must return HTTP status code 200 to indicate successful
+    // verification of user's email address and it must arrange for the binding
+    // of currentUser to said address when the page is reloaded
+    var xhr = new XMLHttpRequest();
+    xhr.open("POST", "/xhr/sign-in", true);
+    // see http://www.openjs.com/articles/ajax_xmlhttp_using_post.php
+    var param = "assert="+assertion;
+    xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
+    xhr.setRequestHeader("Content-length", param.length);
+    xhr.setRequestHeader("Connection", "close");
+    xhr.send(param); // for verification by your backend
+
+    xhr.onreadystatechange = simpleXhrSentinel(xhr); }
+
+function signoutUser() {
+    // Your backend must return HTTP status code 200 to indicate successful
+    // sign out (usually the resetting of one or more session variables) and
+    // it must arrange for the binding of currentUser to 'null' when the page
+    // is reloaded
+    var xhr = new XMLHttpRequest();
+    xhr.open("GET", "/xhr/sign-out", true);
+    xhr.send(null);
+    xhr.onreadystatechange = simpleXhrSentinel(xhr); }
+
+// Go!
+navigator.id.watch( {
+    loggedInUser: currentUser,
+         onlogin: verifyAssertion,
+        onlogout: signoutUser } );
+
+ +

You must call navigator.id.watch() on every page with a login or logout button. To support Persona enhancements like automatic login and global logout for your users, you should call this function on every page of your site.

+ +

Persona will compare the email address you've passed into loggedInUser with its own knowledge of whether a user is currently logged in, and who they are. If these don't match, it may automatically invoke onlogin or onlogout on page load.

+ +

 

+ +

Step 4: Verify the user’s credentials

+ +

Instead of passwords, Persona uses “identity assertions,” which are kind of like single-use, single-site passwords combined with the user’s email address. When a user wants to log in, your onlogin callback will be invoked with an assertion from that user. Before you can log them in, you must verify that the assertion is valid.

+ +

It’s extremely important that you verify the assertion on your server, and not in JavaScript running on the user’s browser, since that would be easy to forge. The example above handed off the assertion to the site’s backend by using jQuery’s $.ajax() helper to POST it to /auth/login.

+ +

Once your server has an assertion, how do you verify it? The easiest way is to use a helper service provided by Mozilla. Simply POST the assertion to https://verifier.login.persona.org/verify with two parameters:

+ +
    +
  1. assertion: The identity assertion provided by the user.
    2. +
  2. audience: The hostname and port of your website. You must hardcode this value in your backend; do not derive it from any data supplied by the user.
    3. +
+ +

For example, if you’re example.com, you can use the command line to test an assertion with:

+ +
$ curl -d "assertion=<ASSERTION>&audience=https://example.com:443" "https://verifier.login.persona.org/verify"
+
+ +

If it’s valid, you’ll get a JSON response like this:

+ +
{
+  "status": "okay",
+  "email": "bob@eyedee.me",
+  "audience": "https://example.com:443",
+  "expires": 1308859352261,
+  "issuer": "eyedee.me"
+}
+
+ +

You can learn more about the verification service by reading The Verification Service API. An example /api/login implementation, using Python, the Flask web framework, and the Requests HTTP library might look like this:

+ +
@app.route('/auth/login', methods=['POST'])
+def login():
+    # The request has to have an assertion for us to verify
+    if 'assertion' not in request.form:
+        abort(400)
+
+    # Send the assertion to Mozilla's verifier service.
+    data = {'assertion': request.form['assertion'], 'audience': 'https://example.com:443'}
+    resp = requests.post('https://verifier.login.persona.org/verify', data=data, verify=True)
+
+    # Did the verifier respond?
+    if resp.ok:
+        # Parse the response
+        verification_data = json.loads(resp.content)
+
+        # Check if the assertion was valid
+        if verification_data['status'] == 'okay':
+            # Log the user in by setting a secure session cookie
+            session.update({'email': verification_data['email']})
+            return resp.content
+
+    # Oops, something failed. Abort.
+    abort(500)
+
+ +

For an example on how to use Persona in a C# ASP.Net MVC3 application, visit this application demo or see the Controller code below:

+ +

 

+ +
public class AuthController : Controller
+{
+    [HttpPost]
+    public ActionResult Login(string assertion)
+    {
+        if (assertion == null)
+        {
+            // The 'assertion' key of the API wasn't POSTED. Redirect,
+            // or whatever you'd like, to try again.
+            return RedirectToAction("Index", "Home");
+        }
+
+        using (var web = new WebClient())
+        {
+            // Build the data we're going to POST.
+            var data = new NameValueCollection();
+            data["assertion"] = assertion;
+            data["audience"] = "https://example.com:443"; // Use your website's URL here.
+
+
+            // POST the data to the Persona provider (in this case Mozilla)
+            var response = web.UploadValues("https://verifier.login.persona.org/verify", "POST", data);
+            var buffer = Encoding.Convert(Encoding.GetEncoding("iso-8859-1"), Encoding.UTF8, response);
+
+
+            // Convert the response to JSON.
+            var tempString = Encoding.UTF8.GetString(buffer, 0, response.Length);
+            var reader = new JsonReader();
+            dynamic output = reader.Read(tempString);
+
+            if (output.status == "okay")
+            {
+                string email = output.email; // Since this is dynamic, convert it to string.
+                FormsAuthentication.SetAuthCookie(email, true);
+                return RedirectToAction("Index", "Home");
+            }
+
+            // Could not log in, do something else.
+            return RedirectToAction("Index", "Home");
+        }
+    }
+}
+ +

The session management is probably very similar to your existing login system. The first big change is in verifying the user’s identity by checking an assertion instead of checking a password. The other big change is ensuring that the user’s email address is available for use as the loggedInEmail parameter to {{ domxref("navigator.id.watch()") }}.

+ +

Logout is simple: you just need to remove the user’s session cookie.

+ +

Step 5: Review best practices

+ +

Once everything works and you’ve successfully logged into and out of your site, you should take a moment to review best practices for using Persona safely and securely.

+ +

If you're making a production-ready site, you may want to write integration tests that simulate logging a user in and out of your site using Persona. To facilitate this action in Selenium, consider using the bidpom library. The sites mockmyid.com and personatestuser.org may also be helpful.

+ +

Lastly, don’t forget to sign up for the Persona notices mailing list so you’re notified of any security issues or backwards incompatible changes to the Persona API. The list is extremely low traffic: it’s only used to announce changes which may adversely impact your site.

+ +

 

diff --git a/files/it/archive/mozilla/persona/remote_verification_api/index.html b/files/it/archive/mozilla/persona/remote_verification_api/index.html new file mode 100644 index 0000000000..05a0e1e7b5 --- /dev/null +++ b/files/it/archive/mozilla/persona/remote_verification_api/index.html @@ -0,0 +1,171 @@ +--- +title: API di verifica remota +slug: Archive/Mozilla/Persona/Remote_Verification_API +translation_of: Archive/Mozilla/Persona/Remote_Verification_API +--- +

Summary

+

When a user tries to log into a website, their browser generates a data structure called an assertion, which is essentially a cryptographically signed email address. The browser sends this assertion to the web site, which must verify that the assertion is valid before logging the user in.

+

Assertions can be verified locally, or with an API hosted at https://verifier.login.persona.org/verify. This page describes how to use the API.

+

Method

+

HTTP POST request to https://verifier.login.persona.org/verify.

+

Parameters

+
+
+ assertion
+
+ The assertion supplied by the user. Available as the first parameter passed to the onlogin function in {{ domxref("navigator.id.watch()") }}.
+
+ audience
+
+ The protocol, domain name, and port of your site. For example, "https://example.com:443".
+
+

Return values

+

The call returns a JSON structure containing a status element, which may be either "okay" or "failure". Depending on the value of status, the structure contains additional elements listed below.

+

"okay"

+

The assertion is valid.

+

In this case the JSON structure contains the following additional elements:

+ + + + + + + + + + + + + + + + + + + +
"email"The address contained in the assertion, for the intended person being logged in.
"audience"The audience value contained in the assertion. Expected to be your own website URL.
"expires"The date the assertion expires, expressed as the primitive value of a Date object: that is, the number of milliseconds since midnight 01 January, 1970 UTC.
"issuer"The hostname of the identity provider that issued the assertion.
+

"failure"

+

The assertion is invalid. In this case the JSON structure contains one additional element:

+ + + + + + + +
"reason"A string explaining why verification failed.
+

Examples

+

node.js

+

This example uses a node.js server using express.js

+
var express = require("express"),
+    app = express.createServer(),
+    https = require("https"),
+    querystring = require("querystring");
+/* ... */
+
+// The audience must match what your browser's address bar shows,
+// including protocol, hostname, and port
+var audience = "http://localhost:8888";
+
+app.post("/authenticate", function(req, res) {
+  var vreq = https.request({
+    host: "verifier.login.persona.org",
+    path: "/verify",
+    method: "POST"
+  }, function(vres) {
+    var body = "";
+    vres.on('data', function(chunk) { body+=chunk; } )
+        .on('end', function() {
+          try {
+            var verifierResp = JSON.parse(body);
+            var valid = verifierResp && verifierResp.status === "okay";
+            var email = valid ? verifierResp.email : null;
+            req.session.email = email;
+            if (valid) {
+              console.log("assertion verified successfully for email:", email);
+              res.json(email);
+            } else {
+              console.log("failed to verify assertion:", verifierResp.reason);
+              res.send(verifierResp.reason, 403);
+            }
+          } catch(e) {
+            console.log("non-JSON response from verifier");
+            // bogus response from verifier!
+            res.send("bogus response from verifier!", 403);
+
+          }
+        });
+  });
+
+  vreq.setHeader('Content-Type', 'application/x-www-form-urlencoded');
+
+  var data = querystring.stringify({
+    assertion: req.body.assertion,
+    audience: audience
+  });
+
+  vreq.setHeader('Content-Length', data.length);
+  vreq.write(data);
+  vreq.end();
+
+  console.log("verifying assertion!");
+});
+
+
+

via Lloyd Hilaiel

+

PHP

+
$url = 'https://verifier.login.persona.org/verify';
+$assert = filter_input(
+    INPUT_POST,
+    'assertion',
+    FILTER_UNSAFE_RAW,
+    FILTER_FLAG_STRIP_LOW|FILTER_FLAG_STRIP_HIGH
+);
+//Use the $_POST superglobal array for PHP < 5.2 and write your own filter
+$params = 'assertion=' . urlencode($assert) . '&audience=' .
+           urlencode('http://example.com:80');
+$ch = curl_init();
+$options = array(
+    CURLOPT_URL => $url,
+    CURLOPT_RETURNTRANSFER => TRUE,
+    CURLOPT_POST => 2,
+    //CURLOPT_SSL_VERIFYPEER => true,   //This currently blocks connection to 'https://verifier.login.persona.org/verify'
+    CURLOPT_SSL_VERIFYPEER => 0,
+
+    CURLOPT_SSL_VERIFYHOST => 2,
+    CURLOPT_POSTFIELDS => $params
+);
+curl_setopt_array($ch, $options);
+$result = curl_exec($ch);
+curl_close($ch);
+echo $result;
+

Via Christian Heilmann

+

Java

+
@Override
+protected void doPost(final HttpServletRequest req,
+   final HttpServletResponse resp) throws ServletException,
+   IOException {
+
+   final String audience = req.getServerName();
+   final String assertion = req.getParameter("assertion");
+   final Verifier verifier = new Verifier();
+   final BrowserIDResponse personaResponse = verifier.verify(assertion,audience);
+   final Status status = personaResponse.getStatus();
+
+   if (status == Status.OK) {
+     /* Authentication with Persona was successful */
+     String email = personaResponse.getEmail();
+     log.info("{} has sucessfully signed in", email);
+     HttpSession session = req.getSession(true);
+     session.setAttribute("email", email);
+
+   } else {
+     /* Authentication with Persona failed */
+     log.info("Sign in failed...");
+
+   }
+}
+
+

Via Javier

+

 

+

Note: If you send the assertion and audience parameters as a JSON-object, they must not be URL-encoded. If they are sent as regular HTTP POST parameters, as in the example above, they must be URL-encoded.

diff --git a/files/it/archive/mozilla/persona/security_considerations/index.html b/files/it/archive/mozilla/persona/security_considerations/index.html new file mode 100644 index 0000000000..7d13904b45 --- /dev/null +++ b/files/it/archive/mozilla/persona/security_considerations/index.html @@ -0,0 +1,55 @@ +--- +title: Considerazioni sulla sicurezza +slug: Archive/Mozilla/Persona/Security_Considerations +translation_of: Archive/Mozilla/Persona/Security_Considerations +--- +

When you add Persona support to your website, Persona takes on as much of the security burden as it can. However, some aspects of security can only be handled by your website. They're listed below.

+

Essential practices

+

Verify assertions on your server

+

When using Persona, identity assertions are passed into the onlogin function passed to {{ domxref("navigator.id.watch()") }}. You should always pass the assertion to your server for verification, and only your server should decide to grant the user additional permissions based on the verification result:

+
// Inside navigator.id.watch({ ...
+onlogin: function(assertion) {
+  // A user wants to log in! Here you need to:
+  // 1. Send the assertion to your backend for verification and to create a session.
+  // 2. Update your UI.
+},
+
+

If you try to verify the assertion using the JavaScript executing in the user's browser, then a malicious user will be able to impersonate a legitimate user of your site by locally injecting code and subverting your JavaScript. This is possible because you're not fully in control of the user's browser, where the code executes.

+

Again, you should always pass the assertion to your server for verification. Even if you're using the remote verification API.

+

Explicitly specify the audience parameter

+

To verify an assertion, you may issue a POST request to https://verifier.login.persona.org/verify. The request includes a parameter called audience:

+
assertion=<ASSERTION>&audience=https://mysite.com:443"
+

The audience parameter is required. You should always specify the audience explicitly in your code, or in your code's configuration. Specifically:

+ +

If you trust the user's browser to tell you the audience, then it becomes possible for a malicious web site to reuse assertions for its web site to log into your web site.

+

Verify SSL certificates

+

To verify an assertion, you may issue a POST request to https://verifier.login.persona.org/verify. You must ensure that your HTTPS request verifies the certificate sent from the server against a trusted root certificate. If you don't, then an attacker could pose as verifier.login.persona.org and issue false verifications.

+

Check that the library you are using to make the request verifies certificates correctly, and that you are initializing it with the appropriate root certificate(s).

+

For example, Python 2.7's standard urllib2 module does not validate server certificates. Instead, we recommend using the "requests" or "urllib3" modules in Python 2.x, or the standard http.client.HTTPSConnection class in Python 3.x. For Perl, ensure that you are using at least version 6.0 of libwww-perl. Depending on the language, library, and operating system that you're using, you may need to supply either a list of trusted CA roots or the single CA used by verifier.login.persona.org.

+

Implement CSRF protection

+

In a CSRF (Cross-Site Request Forgery) login attack, an attacker uses a cross-site request forgery to log the user into a web site using the attacker's credentials.

+

For example: a user visits a malicious web site containing a form element. The form's action attribute is set to an HTTP POST request to http://www.google.com/login, supplying the attacker's username and password. When the user submits the form, the request is sent to Google, the login succeeds and the Google server sets a cookie in the user's browser. Now the user's unknowingly logged into the attacker's Google account.

+

The attack can be used to gather sensitive information about the user. For example, Google's Web History feature logs all the user's Google search terms. If a user is logged into the attacker's Google account and the attacker has Web History enabled, then the user is giving the attacker all this information.

+

CSRF login attacks, and potential defenses against them, are documented more fully in Robust Defenses for Cross-Site Request Forgery (PDF). They're not specific to Persona: most login mechanisms are potentially vulnerable to them.

+

There are a variety of techniques which can be used to protect a site from CSRF login attacks, which are documented more fully in the study above.

+

One approach is to create a secret identifier in the server, shared with the browser, and require the browser to supply it when making login requests. For example:

+
    +
  1. As soon as the user lands on your site, before they try to log in, create a session for them on the server. Store the session ID in a browser cookie.
    2. +
  2. On the server, generate a random string of at least 10 alphanumeric characters. A randomly generated UUID is a good option. This is the CSRF token. Store it in the session.
    3. +
  3. Deliver the CSRF token to the browser by either embedding it in JavaScript or HTML as a hidden form variable.
    4. +
  4. Ensure that the AJAX submission or form POST includes the CSRF token.
    5. +
  5. On the server side, before accepting an assertion, check that the submitted CSRF token matches the session-stored CSRF token.
    6. +
+

Enhancements

+

Content Security Policy (CSP)

+

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware.

+

If you use CSP on your site, you may need to tweak your policy to enable Persona. Depending on your policy, you may need to:

+ +

An example Apache configuration might include:

+
Header set X-Content-Security-Policy: "default-src 'self'; frame-src 'self' https://login.persona.org ; script-src 'self' https://login.persona.org"
diff --git a/files/it/archive/mozilla/persona/the_implementor_s_guide/index.html b/files/it/archive/mozilla/persona/the_implementor_s_guide/index.html new file mode 100644 index 0000000000..2bd12dcc0b --- /dev/null +++ b/files/it/archive/mozilla/persona/the_implementor_s_guide/index.html @@ -0,0 +1,57 @@ +--- +title: The implementor's guide +slug: Archive/Mozilla/Persona/The_implementor_s_guide +tags: + - NeedsTranslation + - Persona + - TopicStub +translation_of: Archive/Mozilla/Persona/The_implementor_s_guide +--- +

The Quick setup guide should be enough to get you started, but when building a full production site you'll probably need features that aren't covered in that guide. In this page we've collected features that are commonly needed by sign-in systems, and explained the best-practice way to implement them with Persona.

+
+
+
+ Call logout() after a failed login
+
+ Always call logout() if you reject an assertion, to avoid a mismatch between your idea of the current user and Persona's idea, which can lead to an endless loop of failed logins.
+
+
+
+ Adding extra email addresses with Persona
+
+ How to let your users add secondary email addresses using Persona.
+
+
+
+ Enabling users to change their email address
+
+ How to let your users change their email address using Persona.
+
+
+
+ Problems integrating with CSRF protection
+
+ A problem caused by the interaction between a common mechanism for CSRF (Cross Site Request Forgery) protection and Persona's Observer API.
+
+
+
+ Supporting users who don't have JavaScript
+
+ Persona requires JavaScript. This page has some tips for supporting users who have JavaScript disabled.
+
+
+
+
+
+ Call request() or get() only from a key handler or in response to a keypress
+
+ Because Persona uses popup windows, you must call request() or get() only in response to a click or a key press, not some other event.
+
+
+
+ Testing your system
+
+ Some pointers for simulating users logging in and out of your website.
+
+
+

 

diff --git a/files/it/archive/mozilla/persona/the_implementor_s_guide/testing/index.html b/files/it/archive/mozilla/persona/the_implementor_s_guide/testing/index.html new file mode 100644 index 0000000000..4ace111864 --- /dev/null +++ b/files/it/archive/mozilla/persona/the_implementor_s_guide/testing/index.html @@ -0,0 +1,8 @@ +--- +title: Testing +slug: Archive/Mozilla/Persona/The_implementor_s_guide/Testing +translation_of: Archive/Mozilla/Persona/The_implementor_s_guide/Testing +--- +

If you're making a production system you will need to write integration tests that simulate logging a user in and out of your site using Persona.

+

If you're using Selenium for testing, consider using the bidpom library. The sites mockmyid.com and personatestuser.org may also be helpful.

+

You may also want to consider stubbyid.

diff --git a/files/it/archive/mozilla/persona/the_navigator.id_api/index.html b/files/it/archive/mozilla/persona/the_navigator.id_api/index.html new file mode 100644 index 0000000000..7ab75d0f93 --- /dev/null +++ b/files/it/archive/mozilla/persona/the_navigator.id_api/index.html @@ -0,0 +1,148 @@ +--- +title: La API navigator.id +slug: Archive/Mozilla/Persona/The_navigator.id_API +translation_of: Archive/Mozilla/Persona/The_navigator.id_API +--- +
For full details about the navigator.id API, refer to its reference pages.
+ +

With Persona, a website asks the user to provide an "assertion", which is a digitally signed email address. By verifying the signature, the site can be assured that the user really does control the address in question. The site can then use this email address as an identifier for that user.

+ +

To ask for an assertion, the website uses a JavaScript API defined by the id object, which is a member of the global navigator object.

+ +

In future we expect the id object to be built into the browser, but at the moment it isn't, so sites using Persona need to include the polyfill library hosted at https://login.persona.org/include.js in their pages. After that, they can work as if id is just a built-in member of navigator.

+ +

There are two current versions of the API: the "Callback API", and the newer "Observer API".

+ +

The Callback API

+ +

The Callback API consists of a single function, get(). It takes two arguments:

+ + + +

You call get(), and in the callback you send the assertion to the server to verify the assertion. If verification succeeds, you can log the user in:

+ +
var signin = document.getElementById('sign-in');
+signin.addEventListener("click", getAssertion, false);
+
+// get an assertion
+function getAssertion() {
+  navigator.id.get(verifyAssertion, {
+                     backgroundColor: "#606B72",
+                     siteName: "My Example Site"
+                   });
+}
+
+// send the assertion to the server for verification
+function verifyAssertion(assertion) {
+  var xhr = new XMLHttpRequest();
+  xhr.open("POST", "/verify", true);
+  var param = "assertion="+assertion;
+  xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
+  xhr.setRequestHeader("Content-length", param.length);
+  xhr.setRequestHeader("Connection", "close");
+  xhr.send(param);
+  xhr.onload = handleVerificationResponse(xhr);
+}
+ +

The Observer API

+ +

The Observer API consists of three functions: request(), watch(), and logout().

+ +

You call request() to ask for a signed assertion, as you do using get() in the old API. But request() doesn't take a callback parameter: instead, you call another function watch(), with which you register callbacks for onlogin and onlogout events. Persona calls these callbacks when a user logs in or out respectively. Like the callback to get(), the onlogin callback gets a signed assertion for you to verify.

+ +

You call logout() when a user logs out of your site, so Persona can update its state.

+ +

The main difference between this API and the Callback API is that the Callback API doesn't maintain any state: it doesn't have any idea which user is currently logged into Persona in general or any site in particular. Each website is responsible for its own session management.

+ +

By contrast the Observer API implements session management: the browser keeps track of which user it thinks is logged into a particular site and can trigger the onlogin and onlogout callbacks when its idea of the state changes. Because of this, you need to ensure that your website's state and Persona's state are kept in synch, and this tends to make the Observer API more complex to use.

+ +

Here's an example showing the Observer API:

+ +
var signin = document.getElementById('sign-in');
+var signout = document.getElementById('sign-out');
+
+signin.addEventListener("click", function() {
+  navigator.id.request();
+}, false);
+
+signout.addEventListener("click", function() {
+  navigator.id.logout();
+}, false);
+
+function handleUserResponse(xhr) {
+  return function() {
+    if (xhr.status == 200) {
+        if (xhr.responseText == "no user") {
+            logoutUser();
+        }
+        else {
+            loginUser(xhr.responseText);
+        }
+      navigator.id.watch({
+        loggedInUser: currentUser,
+        onlogin: function(assertion) {
+          verifyAssertion(assertion);
+        },
+        onlogout: function() {
+          logoutUser();
+        }
+      });
+    }
+    else {
+        navigator.id.logout();
+        alert("XMLHttpRequest error: " + xhr.status);
+    }
+  }
+}
+
+function checkCurrentUser() {
+  var xhr = new XMLHttpRequest();
+  xhr.open("GET", "/currentuser", true);
+  xhr.send();
+  xhr.onload = handleUserResponse(xhr);
+}
+
+checkCurrentUser();
+
+function loginUser(loggedInUser) {
+  // update your UI to show that the user is logged in
+}
+
+function logoutUser() {
+  // update your UI to show that the user is logged out
+}
+
+function handleVerificationResponse(xhr) {
+  // if successfully verified, log the user in
+}
+
+function verifyAssertion(assertion) {
+  var xhr = new XMLHttpRequest();
+  xhr.open("POST", "/verify", true);
+  var param = "assertion="+assertion;
+  xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
+  xhr.setRequestHeader("Content-length", param.length);
+  xhr.setRequestHeader("Connection", "close");
+  xhr.send(param);
+  xhr.onload = handleVerificationResponse(xhr);
+}
+
+ +

This code adds listeners which call request() and logout() when the user clicks "Sign in" and "Sign out" respectively. It then checks whether the server thinks someone is logged in already, and updates its UI if it thinks someone is. The code then calls watch() to start listening for login and logout events. When Persona triggers onlogout the code updates its state to log the user out, and when Persona triggers onlogin the code sends the assertion to the server for verification.

+ +

Although the Observer API is more complex to use, it provides two extra features: seamless first-time sign-in, and global logout.

+ +

Seamless first-time sign-in

+ +

The first time a user signs in using Persona, they may need to create a Persona account. This will happen if they haven't used Persona before and if their email provider does not support Persona. In this case they will be invited to create an account using the fallback provider operated by Mozilla, which will ask them to prove ownership of their email address. After creating an account, if the original website uses the Callback API, the user will not be automatically redirected to the website and signed in: they will have to navigate back to it.

+ +

If the website uses the Observer API, then once the user finishes creating their account with the fallback provider, they will be immediately redirected to the site, the watch() API will call the onlogin listener, and the user will be signed in.

+ +

Global logout

+ +

With the Observer API, the website listens to the onlogout event. If the user signs out of Persona by visiting https://login.persona.org/ and signing out there, then the Observer API triggers this event for all websites that are listening. In response, the site should log the user out.

+ +

This means that if the user doesn't always trust the other people that may access their computer, they can sign out in one place, and this will be propagated to all sites that use the Observer API. 

diff --git a/files/it/archive/mozilla/persona/why_persona/index.html b/files/it/archive/mozilla/persona/why_persona/index.html new file mode 100644 index 0000000000..b2f606d85b --- /dev/null +++ b/files/it/archive/mozilla/persona/why_persona/index.html @@ -0,0 +1,59 @@ +--- +title: Perché Persona per Mozilla? +slug: Archive/Mozilla/Persona/Why_Persona +translation_of: Archive/Mozilla/Persona/Why_Persona +--- +
+ Persona is an openly distributed, cross-browser identity system providing a solution to the traditional password model. It addresses the usability deficiencies that plague other privacy-related systems such as OpenID, without resorting to a centralized infrastructure such as Facebook Connect.
+
+  
+
+ The current approach for establishing and managing user names and passwords is tedious, inefficient, and unsecure. Users must create and remember complex passwords for each site and service. Sites then must securely encrypt and store passwords to prevent the leaking of sensitive information. The prevention and negation of security leaks is the primary reason for the use of Persona, but the flexibility of its systems outclasses most standard identity security systems.
+
+  
+
+
+ Note: For more detailed information about Persona and its functions see What is Persona and how does it work?
+
+

Persona eliminates the need for per-site passwords

+

Persona utilizes a safe, two-click system built on top of public-key cryptography for logging in to websites. The user's browser generates a cryptographic affirmation of identity that expires after a few minutes and is only valid on one site. By avoiding passwords, users do not need to worry about remembering several distinct passwords and need no longer be concerned with unsecure access to their password. This quick and easy sign-in process eliminates the current inefficiencies of traditional account registration and allows users to quickly establish accounts on websites.

+

Persona uses email addresses as identities

+
+
+
+
+ Persona's system relies on email addresses as their key component because of email's inherent versatile and private nature. The pre-existing infrastructure works very well from not only a design perspective but an ideal perspective of openly maintained and safe transfer of identity across the Internet.
+
+
+
+

 

+

Benefits for the user

+ +
+

Advantages for developers

+
+ +
+

How Persona is different from other providers of single sign-on

+
+

Persona protects privacy, provides the user with control, and embellishes choice in a way that other security providers can't. Many social networks like Facebook and Google+ require users to use their real names, accept their policies, and limit users to only one account. Persona allows users to keep their work, school, and social identities separate by using email addresses as a unique identifier rather than real names. Because of this anonymity you are guaranteed an extra layer of identity and network protection that most social networks do not have.

+

Persona also takes a new approach to protecting user privacy by placing the user's browser in the center of the authentication process. The browser obtains credentials provided by the user's email, then presents these credentials to a website. The email provider cannot track the user, but sites can still have confidence in the identity of the user by cryptographically verifying the credentials. Most other systems, even distributed systems like OpenID, require sites to connect to central networks before allowing a user to log in.

+

The efficiency of Persona allows an advanced relationship between developers and users. Mozilla is leading the way in open and free web development, and Persona supports Mozilla's design philosophy through its easy-to-use interface and user protection features.

-- cgit v1.2.3-54-g00ecf