SAML Single Sign-On (SSO)
Il Security Assertion Markup Language (SAML) Single Sign-On (SSO) consente agli utenti di accedere in modo sicuro a più applicazioni utilizzando un unico set di credenziali, in genere l’email e la password aziendali. Invece di creare login separati per ogni servizio, gli utenti si autenticano una sola volta attraverso un Identity Provider (IdP) gestito dall’azienda come Okta, OneLogin, Microsoft Entra o Google Workspace.
L’IdP verifica l’identità dell’utente e garantisce l’accesso a tutte le applicazioni connesse senza richiedere ulteriori verifiche. L’organizzazione gestisce centralmente il controllo degli accessi, i criteri di autenticazione e le autorizzazioni, garantendo maggiore sicurezza, conformità ed efficienza amministrativa.
Con SAML SSO, i proprietari dell’azienda o gli amministratori IT possono collegare il dominio email aziendale (ad esempio, @mycompany.com) all’IdP dell’organizzazione. In questo modo, chiunque abbia un indirizzo email aziendale viene automaticamente riconosciuto e autenticato in modo sicuro quando accede a strumenti e servizi approvati.
In Kinsta, SAML SSO permette di collegare l’IdP dell’azienda direttamente a MyKinsta. Creando un’applicazione SAML nel proprio IdP e aggiungendo i dati della connessione a MyKinsta, il team può accedere utilizzando le credenziali aziendali esistenti, eliminando la necessità di creare o gestire password di MyKinsta separate. Inoltre, i proprietari dell’azienda possono controllare in modo centralizzato chi può accedere a MyKinsta, direttamente attraverso l’IdP.
Kinsta supporta tutti gli identity provider (IdP) che utilizzano lo standard SAML, tra cui Microsoft Entra ID, Okta, OneLogin, Google Workspace, Auth0, Duo, JumpCloud e altri ancora.
Configurare SAML SSO
Per una guida dettagliata passaggio per passaggio sugli IdP più diffusi, puoi fare riferimento a una delle seguenti pagine:
Abilitare l’SSO in MyKinsta
Mentre configuri SAML SSO, puoi cliccare su Salva e esci dalla configurazione in qualsiasi momento per memorizzare i progressi e tornare in un secondo momento.
In MyKinsta, vai su nomeutente > Impostazioni azienda > Single sign-on e clicca su Abilita.

L’introduzione spiega come verrà impostato l’SSO, quindi clicca su Continua.

Impostare l’integrazione dell’app nell’IdP
Per configurare un’app SAML all’interno del proprio identity provider, bisogna utilizzare le informazioni fornite in Crea app SAML, quindi cliccare su Continua.
- App name: copia e incolla questo campo nel campo Application Name dell’IdP.
- App description: copia e incolla questo campo nel campo Application Description del proprio IdP. Questo campo è solitamente facoltativo.
- App icon: clicca su Download per ottenere l’icona di Kinsta, quindi caricala nell’applicazione dell’IdP.
- SSO/ACS URL: è l’endpoint di Kinsta a cui l’IdP reindirizza dopo l’autenticazione. Elabora la risposta SAML, la verifica e stabilisce la sessione dell’utente in MyKinsta. Copia e incolla questo dato nel campo SSO/ACS/Recipient/Single sign-on URL dell’IdP.
- Entity ID: è l’identificativo univoco di Kinsta all’interno del tuo IdP, utilizzato per riconoscere Kinsta come provider di servizi. Copia e incolla questo dato nel campo Entity ID/Audience URI/Audience dell’IdP.
- Start URL: è l’indirizzo web del portale di accesso SSO di Kinsta. È il punto di ingresso che gli utenti visitano per accedere con l’SSO, attivando la richiesta di autenticazione SAML all’IdP. Copia e incolla questo indirizzo nel campo Start URL/Login URL dell’IdP.
- Signed Response: una risposta firmata fornisce una verifica digitale sicura, consentendo a Kinsta di confermare l’identità di un utente e di concedere l’accesso senza richiedere un ulteriore login.
- Name ID format: definisce il modo in cui Kinsta identifica gli utenti. Questo deve essere impostato su un formato di indirizzo email nell’IdP.
- Required attributes: gli attributi che Kinsta richiede all’IdP per completare il processo di login.

Configurazione di Kinsta
Dominio email
In Nome dominio, inserisci il dominio email che gli utenti utilizzeranno per accedere tramite SAML SSO e clicca su Aggiungi dominio.
Solo gli account MyKinsta con un indirizzo email corrispondente al dominio verificato possono autenticarsi tramite SAML. Ad esempio, se SAML è abilitato per example.com, solo gli utenti con un indirizzo email @example.com potranno accedere per quell’azienda.
Se il dominio è già stato verificato in MyKinsta attraverso la gestione dei DNS o come dominio di un sito, verrà verificato automaticamente. In caso contrario, verrà richiesto di aggiungere un record TXT al proprio servizio di gestione DNS per confermare la proprietà del dominio.

Dato che le modifiche al DNS possono richiedere del tempo per propagarsi, potrai fare clic su Salva e esci dalla configurazione per memorizzare i progressi e tornare in un secondo momento.
Configurare Kinsta SAML
Una volta verificato il dominio, utilizza le informazioni fornite dall’IdP per completare l’URL SSO, l’Entity ID e il Certificato pubblico, quindi clicca su Continua.

Provare l’autenticazione in MyKinsta
Per verificare che tutto sia configurato correttamente, clicca su Verifica autenticazione.
Una notifica comunicherà se il test ha avuto successo o se è fallito.
Se il test fallisce, clicca su Indietro e controlla le impostazioni SAML del tuo IdP e di MyKinsta.
Se il test ha avuto successo e vuoi abilitare SAML, clicca su Salva e attiva le modifiche.

Gli utenti dell’azienda MyKinsta potranno ora accedere con SAML SSO o inserendo nome utente e password. Se vuoi obbligare gli utenti ad accedere tramite SAML, puoi attivare l’SSO obbligatorio. Gli utenti che accedono tramite un IdP non devono completare la 2FA di Kinsta, perché l’autenticazione viene gestita direttamente dall’IdP.

Single sign-on obbligatorio
Per richiedere a tutti gli utenti di accedere con l’SSO, attiva l’SSO obbligatorio. Con questa impostazione, viene richiesto a tutti gli utenti di accedere tramite il provider di identità (IdP) anziché con le proprie credenziali MyKinsta. Se un utente si è già autenticato con SAML altrove, verrà automaticamente registrato. Se un utente passa a un’azienda che non ha abilitato l’SSO, deve inserire le proprie credenziali MyKinsta.
Si possono anche aggiungere delle Eccezioni per consentire a determinati utenti di accedere con una password anche quando l’SSO obbligatorio è abilitato. Questo è utile per le terze parti che devono accedere all’azienda ma non hanno un indirizzo email nel proprio dominio, come ad esempio gli sviluppatori.
Se l’SSO obbligatorio è abilitato ma SAML non è abilitato, gli utenti dovranno accedere con le loro credenziali MyKinsta.

Eccezioni
Se è impostato l’SSO obbligatorio, è possibile aggiungere utenti specifici a un elenco di eccezioni, consentendo loro di accedere con le proprie credenziali MyKinsta invece che con l’SSO. Questo è utile per le terze parti che devono accedere all’azienda ma non hanno un indirizzo email nel proprio dominio, come ad esempio gli sviluppatori.

Aggiungere un utente alle eccezioni
Quando inviti un utente che non dispone di un account MyKinsta esistente, devi prima invitarlo nella tua azienda. L’utente deve accettare l’invito e creare il proprio account. Al primo accesso, non avrà ancora accesso all’azienda. Una volta creato l’account, potrai aggiungere l’utente all’elenco delle eccezioni per consentirgli l’accesso senza SSO.
Per aggiungere un utente all’elenco delle eccezioni, clicca su Aggiungi eccezioni. Seleziona l’utente dall’elenco e clicca su Aggiungi eccezione.

Rimuovere un utente dalle eccezioni
Per rimuovere un utente dall’elenco delle eccezioni, clicca sull’icona del cestino dell’utente e poi su Rimuovi eccezione.

Rimuovendo l’ultimo utente dall’elenco delle eccezioni, appare un messaggio di avviso. Se tutti gli utenti vengono rimossi e si verifica un problema con l’IdP, si potrebbe perdere l’accesso all’azienda MyKinsta.

Provisioning just-in-time
Il provisioning just-in-time (JIT) consente agli utenti autorizzati dal proprio IdP di accedere all’azienda MyKinsta senza richiedere un invito. Nella maggior parte dei casi, vuol dire chiunque abbia un indirizzo email sul proprio dominio. Quando un utente accede a MyKinsta, viene indirizzato attraverso l’IdP SSO e non deve creare un account MyKinsta separato. Di default, agli utenti forniti tramite JIT viene assegnato l’account di Sviluppatore azienda. È possibile modificare il livello di accesso di ciascun utente dopo la sua iscrizione, oppure aggiornare il ruolo predefinito per definire il livello di accesso che i nuovi utenti forniti tramite JIT ricevono al momento dell’iscrizione.
Cambiare il ruolo predefinito
Quando il provisioning JIT è abilitato, agli utenti viene assegnato di default il ruolo di Sviluppatore azienda. Per modificare il livello di accesso predefinito, clicca su Cambia ruolo predefinito.

Puoi quindi scegliere il livello di accesso che si desidera assegnare agli utenti che si uniscono tramite il provisioning JIT e cliccare su Cambia ruolo predefinito.

Abilitare il provisioning JIT
Una volta impostato il ruolo predefinito, per abilitare il provisioning JIT, fai clic su Abilita e poi su Abilita il provisioning JIT.

Disattivare il provisioning JIT
Per disabilitare il provisioning JIT, clicca su Disabilita e poi su Disabilita provisioning JIT. Disattivando il provisioning JIT e l’SSO, agli utenti creati tramite JIT verrà richiesto di impostare una password al successivo accesso a MyKinsta.

Rimozione degli utenti
Per revocare completamente l’accesso, gli utenti devono essere rimossi sia da MyKinsta che dal proprio provider di identità (IdP).
- Se l’SSO e il provisioning JIT sono abilitati, la sola rimozione di un utente da MyKinsta non bloccherà l’accesso. L’utente può ancora accedere attraverso il proprio IdP.
- Se si rimuove un utente solo dal proprio IdP e l’SSO obbligatorio non è abilitato, l’utente può ancora accedere con le sue credenziali MyKinsta.
Modificare la durata della sessione
Il proprio identity provider (IdP) controlla la durata e la scadenza della sessione SSO. Per informazioni su come modificarla, consulta la documentazione di supporto del tuo IdP.
Disattivare l’SSO
Disattivando l’SSO, gli utenti non potranno più accedere utilizzando SAML SSO e dovranno invece accedere con il loro indirizzo email e la loro password.
Se il provisioning JIT è stato precedentemente abilitato, alcuni utenti potrebbero non avere una password MyKinsta. In questo caso, possono crearne una selezionando Password dimenticata nella pagina di accesso a MyKinsta.
Una volta disattivato l’SSO, tutti gli utenti dovranno utilizzare l’autenticazione a due fattori (2FA) di Kinsta.
Per sicurezza, più tentativi di accesso falliti possono bloccare l’account. In tal caso, Kinsta invierà un’email contenente un link di accesso temporaneo per consentire all’utente di accedere nuovamente a MyKinsta.
Per disattivare l’SSO, clicca su Disattiva all’interno di Single sign-on.

Per confermare l’intenzione di disabilitare l’SSO, clicca su Disabilita SSO.

Qual è la differenza tra SAML SSO e OAuth SSO?
SAML SSO e OAuth SSO consentono entrambi l’accesso singolo, ma sono stati creati per impieghi, tecnologie e tipi di identità diversi.
SAML SSO è utilizzato da aziende e imprese per fornire ai dipendenti un accesso agli strumenti interni sicuro e gestito dall’azienda. Con SAML, si accede una sola volta utilizzando la propria email e la propria password di lavoro e si sarà automaticamente connessi a tutte le app approvate, come MyKinsta, Slack o Salesforce, senza dover ricordare password separate. Di solito, il team IT dell’azienda gestisce l’accesso in modo centralizzato attraverso l’Identity Provider (IdP), decidendo chi può accedere e a quali strumenti può accedere. Questo garantisce maggiore sicurezza, conformità e una gestione più semplice per i team più grandi.
OAuth SSO, invece, è più comune per l’uso personale. Permette di accedere alle app o ai siti web utilizzando un account personale, come quello di Google, Apple o Facebook, invece di crearne uno nuovo. L’account è legato alla propria identità personale e non a quella della propria organizzazione e l’azienda non può controllare chi accede a quali applicazioni. Ciò significa che OAuth SSO è meno adatto per la gestione degli accessi a livello aziendale.