Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Blog · 30 settembre 2023 · Steve Simpson · Identità

Capire sicurezza e identità in Salesforce: quando usare il single sign-on e OAuth Introduzione

In questo blog vogliamo fare chiarezza su sicurezza e identità in Salesforce, concentrandoci su quando usare il single sign-on (SSO) e OAuth. Questa conoscenza è fondamentale per orientarsi nei diversi scenari di accesso a Salesforce, che sia tramite accesso diretto, SSO o OAuth.

Quando usare l’accesso standard, il single sign-on o OAuth

Accesso diretto:

Scenario: un utente vuole accedere a Salesforce tramite browser per vederne le pagine.

Metodo di accesso: accesso diretto a Salesforce oppure single sign-on tramite un provider di identità di terze parti, per un accesso fluido senza nuova autenticazione.

Riepilogo SSO e OAuth per le persone: una persona con un browser (accesso diretto o single sign-on), una persona con un'app client (flusso OAuth web server con PKCE) e una persona che passa da un web server di terze parti (flusso web server con PKCE)

OAuth con le app mobili:

Scenario: un utente usa un’app mobile per accedere ai dati Salesforce tramite API, non visualizzando le pagine native di Salesforce.

Metodo di accesso: qui si usa OAuth, soprattutto quando l’interazione avviene tramite dispositivi mobili, come telefoni o tablet che usano la tecnologia del browser. Questo approccio permette alle app mobili di interagire in modo sicuro con le API di Salesforce.

Riepilogo SSO e OAuth per i processi client: un utente di integrazione (credenziali client), un utente persona designato (asserzione bearer JWT o SAML), un dispositivo con una persona che approva in parallelo (flusso dispositivo) e dispositivi-asset (flusso asset)

OAuth con server di terze parti:

Scenario: un utente usa un browser per comunicare con un server di terze parti che deve accedere ai dati Salesforce per suo conto. Ad esempio plug-in di posta elettronica o altri sistemi integrati con Salesforce.

Metodo di accesso: OAuth, con un protocollo specifico chiamato “Web Server with PKCE” (Proof Key for Code Exchange), per un accesso sicuro.

I flussi OAuth per i diversi scenari

Flusso credenziali client: pensato per un processo client (come server esterni che eseguono caricamenti o esportazioni in batch) che accede a Salesforce con un account utente di integrazione designato.

Flussi JWT, asserzione bearer SAML e asserzione SAML: servono negli scenari in cui un processo client deve agire per conto di un utente specifico, senza che l’utente sia coinvolto direttamente. Il processo impersona un utente designato, mantenendo il contesto di sicurezza dei file di quell’utente.

Flusso dispositivo: viene avviato da un dispositivo che richiede un intervento umano per l’approvazione. Ad esempio, un’app per smart TV chiede all’utente di inserire un codice per approvare l’accesso.

Flusso asset: utile per i dispositivi dell’Internet delle cose (IoT) che devono collegarsi a Salesforce per leggere o scrivere dati.

Riepilogo e conclusione

In sostanza, il metodo di accesso dipende soprattutto dallo scenario:

Per l’accesso diretto a Salesforce tramite browser, usa l’accesso diretto o il single sign-on, se hai un servizio di identità.

Per l’accesso indiretto tramite dispositivi mobili, server di terze parti o processi automatizzati, OAuth è il metodo preferito. Qui devi decidere se OAuth agirà per conto di un utente umano o di un account utente di integrazione.

Nei prossimi articoli approfondiremo ogni scenario e caso d’uso per darne una comprensione completa.

Resta sintonizzato

Inizia con fiducia il tuo percorso in Salesforce Identity! Per altri spunti e consigli, resta sintonizzato qui su www.SteveTechArc.com e sul canale YouTube @SteveTechArc (opens in a new tab). Iscriviti e approfondisci la tua comprensione di Salesforce Identity.

Contribuire a cambiare il mondo condividendo conoscenze sull’integrazione con altri architetti e con chi è in cammino per diventarlo!

Trascrizione realizzata con l’aiuto dell’IA

STA 3.9