Informazioni sul linguaggio di Identity

Obiettivi di apprendimento

Al completamento di questo modulo, sarai in grado di:

Identificare gli standard di settore utilizzati per la gestione delle identità e dell'accesso.
Comprendere in che modo SAML è correlato a XML.
Comprendere la differenza tra un provider di identità e un provider di servizi.

Standard e protocolli di identità

È difficile credere che sia possibile tenere al sicuro le identità degli utenti quando questi non devono eseguire l'accesso a siti web o app? Come fanno i prodotti di così tante aziende, anche concorrenti, a funzionare insieme?

La risposta sono gli standard e i protocolli di settore per la gestione delle identità e dell'accesso. Può sembrare complicato, ma in realtà non lo è. Uno standard è solo un insieme di procedure concordate adottato dai membri di un determinato settore, che può includere un protocollo in cui è specificato il modo in cui i sistemi si scambiano le informazioni.

I seguenti sono i tre protocolli utilizzati da Salesforce e altri fornitori per implementare soluzioni di gestione delle identità.

SAML
OAuth 2.0
OpenID Connect

Protocollo SAML

Se vuoi che gli utenti passino in modo fluido dalle organizzazioni alle applicazioni Salesforce e viceversa senza dover eseguire ogni volta l'accesso, puoi impostare l'accesso Single Sign-On (SSO). SAML (Security Assertion Markup Language) è il protocollo che rende possibile tutto questo.

Di seguito sono riportati due esempi di SAML in azione.

Quando esegui l'accesso a Salesforce e poi fai clic sul Programma di avvio app per accedere direttamente alla tua casella Posta in arrivo in Gmail, SAML è in azione.
SAML è in azione anche quando gli utenti che hanno già eseguito l'accesso a un'altra app possono accedere alla propria organizzazione Salesforce senza dover ripetere la procedura di accesso.

Asserzione SAML

Ecco come funziona SAML. Un utente tenta di accedere a un servizio. Il provider di servizi invia una richiesta al provider di identità con una domanda riassumibile come: "Va bene se questo utente accede al mio servizio?" Il provider di identità si assicura che gli utenti siano chi dicono di essere controllando il proprio database, quindi fornisce una risposta, ossia un'asserzione, dicendo "Sì, questo utente è autorizzato, ecco alcune informazioni sull'utente".

Aspetta un attimo. Qual è la differenza tra un provider di identità e un provider di servizi? In sostanza, il provider di identità è il soggetto che autentica l'utente. Il provider di servizi è il soggetto che chiede che l'identità venga autenticata. Parleremo ancora dei provider di identità e di servizi più avanti in questa unità.

L'asserzione è costituita dalle informazioni che vengono inviate. Un'asserzione può contenere informazioni dettagliate su un utente e può contenere attributi che lo riguardano, come nome e cognome, le informazioni di contatto, magari anche la qualifica.

SAML lavora in background senza che gli utenti se ne accorgano. È sufficiente fare clic su un'icona o un link per aprire un'altra app senza dover fornire ulteriori informazioni o eseguire di nuovo l'accesso. A volte, al momento dell'accesso, nella destinazione sono già presenti delle informazioni sugli utenti (gli attributi utente).

SAML e XML

SAML e un protocollo basato su XML, ovvero i pacchetti di informazioni scambiati sono scritti nel linguaggio XML. Si suppone che XML sia (quasi) leggibile in chiaro in modo che sia possibile capire cosa sta succedendo e questo è utile quando si tenta di capire se le cose stanno funzionando correttamente.

Il diagramma seguente illustra una porzione di un'asserzione SAML. Ti sembra incomprensibile? Guardalo di nuovo e ti accorgerai che non è così male. Contiene informazioni su nome utente, numero di telefono e nome proprio dell'utente.

In questo esempio, l'organizzazione Salesforce passa le informazioni dell'utente a un'altra applicazione. L'applicazione può utilizzare quelle informazioni per autorizzare l'utente e personalizzare la sua esperienza. Ma la cosa più importante è che l'utente non deve ripetere la procedura di accesso per accedere all'applicazione.

Protocollo OAuth 2.0

OAuth (Open Authorization) 2.0 è un protocollo aperto utilizzato per proteggere la condivisione dei dati tra applicazioni. L'utente lavora in un'app ma vede i dati di un'altra. Ad esempio, hai eseguito l'accesso alla tua app mobile Salesforce e vedi i dati dell'organizzazione Salesforce.

Dietro le quinte, avviene una sorta di "stretta di mano" tra le app, che poi chiedono all'utente di autorizzare questa condivisione di dati. Quando gli sviluppatori vogliono integrare la propria app con Salesforce, utilizzano le API OAuth.

Ecco un paio di esempi.

Un'app per dispositivi mobili che estrae i referenti da un'organizzazione Salesforce utilizza OAuth.
Anche un'organizzazione Salesforce che recupera i referenti da un altro servizio utilizza OAuth.

Nell'esempio che segue, un'app chiede all'utente l'autorizzazione per accedere alle informazioni utilizzando OAuth 2.0.

Esempio di accesso OAuth

Protocollo OpenID Connect

Il protocollo OpenID Connect aggiunge un livello di autenticazione a OAuth 2.0 per abilitare lo scambio sicuro di informazioni utente. Analogamente a SAML, OpenID Connect invia le informazioni sull'identità da un servizio a un altro. A differenza di SAML, OpenID Connect è stato creato per l'odierno mondo dei social network. Ti è mai capitato di installare una nuova app e visualizzare un prompt del tipo "Accedere con l'account Google?" Se sì, quell'app utilizza il protocollo OpenID Connect. Quando accedi con Google, non stai creando un account e un'altra password. Solo Google conserva quelle informazioni.

Lo sviluppatore dell'app ha utilizzato il protocollo OpenID Connect per abilitare l'accesso social.

Ad esempio, quando Google verifica l'identità di un utente per conto di un altro servizio, sta di fatto autenticando quell'utente. In questo senso, Google è un provider di identità.

Salesforce include il supporto per alcuni dei principali provider di identità social, tra cui Google, Facebook e LinkedIn. Se un provider non è direttamente supportato, puoi comunque utilizzarlo se implementa il protocollo OpenID Connect, come fanno Amazon e PayPal, ad esempio.

Il vantaggio del protocollo OpenID Connect per gli utenti è che possono ridurre il numero di account, nomi utente e password separati. Dall'altro lato, gli sviluppatori possono autenticare i propri utenti in tutti i siti web e tutte le app senza avere la responsabilità della gestione dei file delle password. Questo processo rende molto più difficile per gli hacker compromettere gli account degli utenti.

Provider di servizi e provider di identità

Nel processo di autenticazione degli utenti, SAML scambia le informazioni relative alle identità tra il responsabile della gestione delle informazioni, detto provider di identità (IdP, Identity Provider), e il servizio desiderato, detto provider di servizi.

Nel caso in cui un utente acceda prima a Salesforce e poi a Gmail, Salesforce è il provider di identità e Google il provider di servizi. Salesforce può essere sia provider di servizi che provider di identità.

Salesforce come provider di servizi

Gli utenti autenticati possono passare da un provider di identità esterno a Salesforce. In questo caso, Salesforce è un provider di servizi: gli utenti vogliono accedere al servizio e il loro provider di identità lo consente. Questa configurazione di Salesforce è comune, perché spesso l'azienda utilizza già un provider di identità. Il provider di identità può essere uno dei tanti presenti sul mercato, ad esempio Active Directory Federation Services (ADFS) di Microsoft, PingFederate di Ping Identity, il sistema open-source Shibboleth oppure OpenAM di ForgeRock.

Gli utenti accedono da un provider di identità e vengono reindirizzati a Salesforce (il provider di servizi). In un altro modulo, vedremo come configurare SSO con Salesforce come provider di servizi e un'applicazione di terze parti come provider di identità esterno.

Salesforce come provider di identità

Gli utenti autenticati possono anche passare da Salesforce ad altri cloud e altre applicazioni. In questo caso, Salesforce funge da provider di identità e consente l'accesso tramite SSO in modo che gli utenti possano accedere a provider di servizi diversi.

Flusso SAML per SSO

Se vuoi saperne di più, il diagramma che segue illustra il flusso delle comunicazioni SAML durante il processo SSO. Questo è ciò che succede dietro le quinte. Non preoccuparti se non hai voglia di sbirciare. Non fa parte del test.

Il processo SSO avviene alla velocità della luce, ma prevede alcuni passaggi.

L'utente tenta di accedere a Salesforce.
Salesforce riconosce la richiesta SSO e genera una richiesta SAML.
Salesforce reindirizza la richiesta SAML di nuovo al browser.
Il browser reindirizza la richiesta SAML al provider di identità esterno.
Il provider di identità verifica l'identità dell'utente e crea il pacchetto dell'asserzione SAML che contiene l'autenticazione dell'utente.
Il provider di identità invia l'asserzione SAML al browser.
Il browser reindirizza l'asserzione a Salesforce.
Salesforce verifica l'asserzione.
Il tentativo di accesso è riuscito e l'utente può utilizzare Salesforce.

Breve riassunto dei termini relativi all'identità

Che ne dici di questo corso accelerato sull'argomento dei protocolli di identità? Quando le parole si assomigliano e le differenze non sono chiare, può essere difficile capirle bene. Ecco un breve riassunto. Speriamo che sia utile!

Un termine	Si confonde facilmente con questo termine
Autenticazione significa chi è una persona. Oggi, autenticazione si usa spesso per indicare autorizzazione e autenticazione con una sola parola.	Autorizzazione significa quello che una persona può fare.
Protocollo specifica l'insieme di regole che consentono ai sistemi di scambiarsi informazioni. Spesso i termini protocollo e standard sono usati in modo intercambiabile.	Standard è una specifica, un insieme di prassi adottate da un settore che i fornitori accettano di supportare. Spesso, in uno standard viene incluso un protocollo per specificare il modo in cui le aziende devono implementare lo standard.
Nome utente e password sono dati che l'utente fornisce per accedere a un sistema.	Le credenziali sono praticamente la stessa cosa.
Il Single Sign-On (SSO) consente a una persona di accedere una volta e poi accedere ad altri servizi e app senza ripetere la procedura di accesso.	L'accesso social consente a una persona di accedere a un'app utilizzando le credenziali stabilite con un account social, ad esempio Google. L'app accetta le credenziali Google e l'utente non deve creare un altro account e un'altra password.
Il provider di identità è un servizio affidabile che consente agli utenti di accedere ad altri siti web e servizi senza eseguire di nuovo l'accesso.	Il provider di servizi è un sito web o servizio che ospita le app e accetta l'identità fornita da un provider di identità.

Qual è il prossimo argomento?

Hai fatto un veloce tour degli standard di settore per l'accesso e la gestione delle identità. Non preoccuparti se non è tutto chiaro. Per il momento, ricorda che Salesforce Identity utilizza i protocolli per implementare le proprie funzionalità.

Ora inizieremo a divertirci. Nei hai abbastanza di concetti e definizioni? Mettiamo in pratica alcune delle cose che hai imparato. Più avanti in questo itinerario, imposterai le funzioni di sicurezza nella tua organizzazione di sviluppo Salesforce.