Passa al contenuto principale

Login utente

Bobuild ti permette di proteggere la tua app, o parti di essa, con login utente. Il meccanismo è molto flessibile e può adattarsi a qualsiasi esigenza. Per capire come il login si integra con l'accesso al Builder, i portali e l'API, consulta la Panoramica sulla sicurezza.

L'idea di base è che gli utenti sono semplicemente record normali di un oggetto che decidi di usare per l'autenticazione.

Sono disponibili diversi metodi di autenticazione:

  • E-mail + password
  • E-mail + magic link inviato via e-mail
  • Login con Google
  • Login con Microsoft/Office365
  • Login con SPID
  • Login con CIE (Carta d'Identità Elettronica)

Il login può essere abilitato per ogni pagina di primo livello (le chiamiamo anche portali), il che significa che puoi avere metodi di autenticazione diversi per parti diverse della tua app.

Esempio

In questo esempio, l'app contiene tre portali:

  • un portale backoffice, protetto da un login basato sull'oggetto operator
  • un portale cliente, protetto da un login basato sull'oggetto customer e che consente anche la registrazione self-service
  • una sezione pubblica, non protetta da alcun login

Come configurare il login​

Apri la pagina di primo livello che vuoi proteggere. Noterai un badge "Public" nella barra superiore, che indica che la pagina e le sue sotto-pagine non sono attualmente protette da alcun login:

Cliccandoci sopra accederai alle impostazioni di login:

Qui puoi scegliere qualsiasi oggetto da usare per l'autenticazione utente. Se quell'oggetto ha un campo e-mail univoco e un campo password, il login e-mail + password viene abilitato automaticamente; altrimenti configura un altro metodo (magic link o SSO) nel widget di login.

Impostare ruoli e autorizzazioni​

Il meccanismo di login è molto flessibile e ti permette di limitare quali utenti possono accedere a quali pagine. Ad esempio, potresti consentire l'accesso al portale solo ai clienti contrassegnati come "active", oppure permettere a determinati dipendenti di accedere a una specifica area del backoffice.

Per farlo, puoi impostare regole come queste:

Un altro modo per usare le regole è creare un campo "roles" nel tuo oggetto utente, di tipo "Multiple Choice". In questo modo puoi associare a ogni utente più tag che rappresentano le sue autorizzazioni e usarli nelle login rule come in questo esempio:

Queste regole vengono verificate al login e durante la navigazione nel portale: se l'utente non corrisponde al filtro sulla pagina radice (protetta da login), l'autenticazione fallisce e non viene creata alcuna sessione — può essere mostrato lo stesso messaggio di accesso negato.

Timeout di sessione​

Nelle opzioni del widget di login, apri Session timeout e imposta Idle timeout:

  • 15 minutes, 30 minutes, 1 hour, 8 hours, 24 hours (predefinito) o 7 days
  • Forever — la sessione non scade per inattività

Il timer si azzera quando l'utente è attivo nell'app. Dopo il periodo di inattività, la sessione viene chiusa e deve effettuare di nuovo l'accesso.

Registrazione self-service e reset password​

Se vuoi permettere agli utenti di creare il proprio account, puoi abilitare la registrazione self-service. Verrà aggiunto un pulsante "Register" alla pagina di login, collegato a una sotto-pagina specifica che puoi personalizzare liberamente aggiungendo un form widget che raccoglie i dati dell'utente e crea un nuovo record nell'oggetto utente.

Ecco alcune buone idee da considerare quando abiliti la registrazione self-service:

  • Valuta l'invio di una conferma via e-mail all'utente dopo la registrazione. Si fa facilmente configurando una Task "Send e-mail" nel form di registrazione.
  • Valuta l'abilitazione del reset password con la funzionalità integrata, così gli utenti possono recuperare la password se la dimenticano.
  • Se vuoi revisionare e approvare i nuovi utenti prima che possano accedere all'app, crea un campo booleano denominato "Active" nel tuo oggetto utente (oppure, se preferisci gestire più stati, un campo choice denominato "User Status") e lascialo al valore predefinito quando gli utenti si registrano. Poi, nel portale backoffice, crea un grid widget per elencare tutti gli utenti in attesa di approvazione. Infine, configura le login rule per consentire l'accesso solo agli utenti con "Active" impostato su true, come descritto sopra.
Esempio

Reindirizzare gli utenti dopo il login​

Nella sezione "Follow-up" della configurazione del widget di login puoi definire regole per reindirizzare gli utenti a un'altra pagina dopo il login. Ad esempio, potresti verificare se l'utente ha accettato i Termini di servizio o aggiornato i propri dati e indirizzarlo alle pagine pertinenti invece di mandarlo alla pagina principale.

Se un utente già autenticato apre la pagina di login, Bobuild salta il form e applica lo stesso reindirizzamento follow-up (oppure lo manda alla pagina del portale padre).

Access denied message​

Nelle opzioni del widget di login, imposta Access denied message per personalizzare il testo mostrato quando l'autenticazione fallisce — e-mail o password errate, utente sconosciuto con SSO e casi simili. Lascialo vuoto per non mostrare alcun messaggio.

Metodi di login​

E-mail + password​

È il metodo di autenticazione più classico. Per abilitarlo, assicurati che il tuo oggetto utente abbia un campo e-mail e un campo password. Verifica che il campo e-mail sia contrassegnato come unique alone.

Con questo metodo di autenticazione, agli utenti viene mostrato un unico campo in cui inserire l'indirizzo e-mail. Se l'indirizzo fornito è presente nell'oggetto scelto come oggetto utente, viene inviato un messaggio via e-mail all'indirizzo inserito contenente un link a breve durata. Cliccando su quel link, l'utente viene automaticamente autenticato nell'area riservata.

Questo metodo è comodo in molte situazioni e non è meno sicuro di una combinazione e-mail/password: si basa infatti sul fatto che solo l'utente legittimo può accedere alla propria casella di posta.

Sul widget di login, nelle opzioni magic link puoi configurare:

  • From — quale indirizzo mittente consentito usa il messaggio (da Outgoing E-mail); di default è il From predefinito dell'app
  • Link validity — per quanto tempo il link nell'e-mail resta utilizzabile (da 10 minuti a 1 settimana)
  • Message subject e body — personalizza il testo dell'e-mail (placeholder supportati dove disponibili)

Google​

Un modo molto comodo per autenticare i tuoi utenti è usare il pulsante Login with Google. Permette agli utenti di accedere alla tua app con il proprio account Google, senza dover ricordare un'altra password. Non è comodo solo per gli utenti esterni, ma anche per quelli interni, perché ti affidi alla sicurezza delle credenziali Google, inclusa l'autenticazione a due fattori.

Per configurare il login Google, devi indicare a Bobuild come i dati utente di Google si collegano ai campi del tuo oggetto utente. Serve per più motivi:

  • trovare l'utente nella tua app se già presente (Google user ID e/o indirizzo e-mail verranno usati come criteri di ricerca)
  • creare un nuovo utente se non ancora presente (Google user ID, indirizzo e-mail e nome verranno usati per popolare il nuovo record)

Di solito basta mappare il campo e-mail, che identifica l'utente in modo univoco. Google user ID e nome sono opzionali; se non li mappi, verranno ignorati.

Esempio

Microsoft/Office365​

Analogamente a Google, gli utenti possono accedere con il proprio account Microsoft / Office 365. Mappa almeno il campo e-mail così Bobuild può associare l'identità Microsoft a un record nel tuo oggetto utente.

Le impostazioni SSO a livello di app si trovano in Settings → Single Sign-On → Microsoft:

  • Use default Bobuild integration — configurazione più rapida quando la registrazione app predefinita è sufficiente
  • Use custom credentials — fornisci Tenant ID, Client ID e Client secret dalla tua registrazione app Azure

Usa un Tenant ID specifico quando devono accedere solo account della tua organizzazione (single-tenant). Configurazioni più ampie / multi-tenant usano la configurazione tenant appropriata per la tua app Azure (ad esempio l'endpoint comune). Limitare il tenant è un modo semplice per rafforzare un portale interno senza mantenere una directory password separata.

Puoi anche sovrascrivere le credenziali su una specifica pagina di login quando necessario.

SPID/CIE​

Bobuild supporta le identità digitali pubbliche italiane (SPID e CIE). Configura la federazione una volta in Settings → Single Sign-On → SPID/CIE, poi abilita i metodi nelle opzioni di login di ogni portale.

Scenari tipici:

  • un portale del settore pubblico che deve accettare SPID per i cittadini;
  • login CIE per gli utenti che preferiscono la Carta d'Identità Elettronica;
  • innalzare il livello SPID richiesto per operazioni sensibili.

Impostazioni app (SPID/CIE)​

  • Enable SPID/CIE (funzionalità del piano)
  • Entity ID (obbligatorio)
  • Private key e Certificate (incolla il tuo materiale; lascia vuota la chiave in modifica per mantenere il segreto esistente — non verrà mai mostrato di nuovo)
  • Attribute consuming service index
  • Enable validator per testare contro il validatore demo SPID
  • Scarica i metadati SP dall'URL mostrato nel Builder e registrali con il tuo aggregatore di identità come richiesto

Opzioni pagina di login​

Nella configurazione login del portale, abilita Log-in with SPID e/o Log-in with CIE, mappa gli attributi di identità ai campi del tuo oggetto utente (ad esempio fiscalNumber) e scegli se gli utenti sconosciuti vengono creati o rifiutati. Puoi anche aggiornare i campi mappati a ogni login.

SPID level (1 / 2 / 3) imposta la robustezza di autenticazione richiesta — scegli il livello richiesto dalla tua procedura, così i login a bassa garanzia non possono raggiungere aree ad alta sensibilità.

suggerimento

La configurazione SPID/CIE coinvolge certificati e scambio di metadati. Se hai bisogno di aiuto per abilitare la funzionalità del piano o validare i metadati, contattaci.

Altri meccanismi di login​

Se hai altre esigenze, contattaci: abbiamo una roadmap di sviluppo che potrebbe adattarsi alle tue necessità.