Autorizzazione SAML e controllo degli accessi

Istruzioni e metodologia per definire la politica di accesso e gestire SAML per la propria organizzazione.

Il protocollo SAML consente alle organizzazioni di gestire l’autenticazione e i diritti di accesso degli utenti Tulip utilizzando il proprio provider di identità (IdP) esistente. Questa guida illustrerà in dettaglio le opzioni disponibili per l’implementazione dell’integrazione con un IdP di livello aziendale tramite il protocollo SAML.

Prerequisiti

• Comprendere i ruoli degli utenti di Tulip
• Classificare gli utenti Tulip previsti in base al ruolo, in modo da essere pronti ad aggiornare un attributo SAML con il loro ruolo in Tulip
• Identificare chi, all’interno della propria organizzazione, si occuperà di configurare l’IdP e l’account Tulip

Configurazione dell’IdP

Quando la vostra istanza di Tulip è configurata per utilizzare SAML per l’accesso, Tulip mantiene un collegamento tra gli utenti in Tulip e quelli nel vostro Identity Provider (IdP) aziendale. Un determinato utente che possiede un account nell’IdP dovrebbe avere al massimo un account in una determinata istanza di Tulip. Tulip mantiene questo collegamento utilizzando un concetto specifico di SAML chiamato "NameID". Un NameID è un tipo di identificatore opaco fornito dall’autenticazione SAML e definito dall’IdP.

Poiché il NameID viene utilizzato per mantenere questo collegamento, Tulip si aspetta che i NameID siano stabili, il che significa che il NameID che Tulip riceve per un determinato utente dell’IdP non dovrebbe cambiare per tutta la durata dell’account dell’utente. Se il NameID di un utente dovesse cambiare, il collegamento verrebbe interrotto e potresti riscontrare errori durante l’accesso.

Tulip raccomanda vivamente di configurare l’IdP in modo che fornisca un NameID che non cambi nel tempo. Per questo motivo, Tulip sconsiglia l’uso di nomi o indirizzi e-mail come NameID, poiché questi valori possono cambiare nel tempo. Si consiglia di configurare l’IdP in modo che utilizzi ID oggetto interni o nomi di account che siano garantiti come immutabili.

Si noti che i NameID non devono necessariamente essere leggibili o riconoscibili dall’utente (anzi, in genere è preferibile per motivi di sicurezza utilizzare valori non riconoscibili come NameID).

Durante la configurazione del proprio IdP, si consiglia di impostare il formato del NameID su “Persistente”, il che indica a Tulip che il valore deve rimanere costante per tutta la durata dell’account di un utente.

Quando si mappa il valore di origine dell’attributo NameID, mapparlo a un valore che si sa essere immutabile, come “ID oggetto” o “nome principale utente”.

Microsoft Entra

Per i clienti che utilizzano Microsoft Entra come IdP, seguire queste istruzioni specifiche per configurare l’applicazione Tulip in modo che utilizzi NameID persistenti:

1. In Entra, partire dall’applicazione aziendale associata alla propria istanza di Tulip.
2. Nel menu di navigazione a sinistra, fare clic su “Single sign-on” nel gruppo “Manage”.
3. Modifica la sezione “Attributi e claim”.
4. Nella sezione “Required Claims”, clicca sulla riga relativa al claim denominato “Unique User Identifier (Name ID)”.
5. Assicurarsi che il “Formato identificatore nome” sia impostato su “Persistente”. Impostare la “Fonte” su “Attributo” e selezionare un attributo che rimanga stabile per l’intero ciclo di vita dell’utente. user.userprincipalname e user.objectid sono ottime scelte.

Opzioni di configurazione SAML e Tulip

Modalità di controllo

La modalità di controllo di Tulip indica che il ruolo e l’area di lavoro di un utente in Tulip vengono ricavati dalla mappatura degli attributi SAML solo al primo accesso a Tulip.

Agli utenti disattivati in Tulip viene impedito di effettuare l’accesso.

La modalità di controllo IdP implica che il ruolo e l’area di lavoro di un utente in Tulip verranno aggiornati dall’IdP ogni volta che effettua l’accesso.

Mappatura predefinita dei ruoli (solo in modalità di controllo Tulip)

Al primo accesso, a tutti gli utenti viene assegnato un livello di accesso predefinito (Visualizzatore con accesso al Player). Il Titolare dell’account dovrà quindi adeguare manualmente il ruolo al livello appropriato all’interno di Tulip.

Ambienti di lavoro

Scopri di più sugli spazi di lavoro

Come per l’attributo del ruolo, ora è possibile mappare automaticamente gli utenti a uno spazio di lavoro specifico al momento della creazione iniziale dell’utente. Dopo la creazione dell’utente, i titolari dell’account possono spostare in modo flessibile gli utenti da uno spazio di lavoro all’altro.

Mappatura personalizzata degli spazi di lavoro SAML

Al primo accesso, a un utente viene assegnato l’accesso all’area di lavoro in base al gruppo indicato nel suo attributo “area di lavoro”. Da quel momento in poi, Tulip non leggerà più l’attributo “area di lavoro” di quell’utente e qualsiasi modifica relativa all’area di lavoro dovrà essere effettuata nella piattaforma da un titolare dell’account.

Mappatura predefinita degli spazi di lavoro

Al primo accesso, a tutti gli utenti viene concesso l’accesso a uno spazio di lavoro predefinito di vostra scelta. Il titolare dell’account può quindi modificare l’accesso allo spazio di lavoro.

Gruppi di utenti

È possibile mappare gli utenti nella funzionalità Gruppi di utenti{target=_blank} di Tulip in tutte le configurazioni SAML.

I gruppi di utenti esistono a livello di account. Una volta che un utente è stato mappato a un gruppo di utenti, ne diventerà membro in tutti gli spazi di lavoro.

Una volta attivata l’opzione “Gruppi di utenti”, sarà possibile mappare gli utenti dal proprio IdP ai gruppi di utenti in Tulip in base al valore di un attributo in SAML.

Successivamente, potrai specificare fino a 100 attributi SAML e associare i valori di ciascuno di essi a un gruppo di utenti. Un utente potrà quindi essere associato a più gruppi di utenti.

Mappatura dei gruppi di utenti e comportamento della modalità di controllo

Il comportamento dell’appartenenza ai gruppi utente dipende dall’impostazione della modalità di controllo.

• Modalità di controllo Tulip: i gruppi mappati tramite SAML di un utente vengono applicati solo al primo accesso. Successivamente, l’appartenenza ai gruppi può essere gestita all’interno di Tulip e qualsiasi modifica manuale viene mantenuta agli accessi successivi.
• Modalità di controllo IdP: l’appartenenza completa a un gruppo di un utente viene ricalcolata in base ai suoi attuali attributi SAML ad ogni accesso. Tulip assegna i gruppi calcolati dalla mappatura e rimuove l’utente da qualsiasi gruppo non coperto dalla mappatura, compresi i gruppi assegnati manualmente all’interno di Tulip.

Opzioni di autenticazione

Se si desidera utilizzare le chiavi FIDO per l’autenticazione degli utenti, è necessario “Disabilitare la corrispondenza dei metodi di autenticazione”.

Classe di contesto di autenticazione

La classe di contesto di autenticazione è il metodo specificato mediante il quale gli utenti effettuano l’autenticazione.

Quando è abilitata, gli utenti potranno autenticarsi solo utilizzando il metodo specificato.

Se disabilitata, la selezione del metodo di autenticazione sarà interamente delegata al fornitore di identità.

Forza l'autenticazione

Tulip utilizza il parametro SAML forceAuthn per determinare se gli utenti debbano effettuare una nuova autenticazione con il proprio IdP ad ogni accesso, oppure se sia possibile riutilizzare una sessione SAML esistente a livello di sistema operativo. Tulip non utilizza il parametro isPassive. In questo caso, la sessione esistente è la sessione SAML a livello di sistema operativo (ad esempio, una sessione Windows collegata al proprio Identity Provider), non una sessione specifica di Tulip.

Autenticazione forzata ON (impostazione predefinita): Tulip invia forceAuthn=true, richiedendo all’utente di autenticarsi attivamente con il proprio IdP ad ogni accesso, indipendentemente dall’esistenza di una sessione SAML a livello di sistema operativo. Questa impostazione garantisce che gli utenti non possano bypassare la riautenticazione.

Autenticazione forzata DISATTIVATA: Tulip invia forceAuthn=false. Se l’utente dispone già di una sessione SAML a livello di sistema operativo attiva e riconosciuta dall’IdP, verrà connesso automaticamente a Tulip senza dover reinserire le credenziali.

Personalizzazione

Personalizzazione opzionale per l’accesso degli utenti.

Etichetta del pulsante di accesso - Personalizza il testo sul pulsante di accesso SAML nelle pagine di accesso a Tulip.

Email di supporto personalizzata - Imposta un indirizzo email personalizzato che verrà mostrato agli utenti quando si verificano errori di accesso SAML. Questo può indirizzare gli utenti al tuo supporto IT interno. Se lasciato vuoto, verrà utilizzato l’indirizzo email di supporto predefinito "support@tulip.co".

Lettore desktop: browser predefinito del sistema operativo per l’autenticazione

Se l’accesso SSO o l’autorizzazione tramite connettore OAuth richiedono un’integrazione disponibile solo tramite il browser predefinito del sistema operativo, è possibile configurare Tulip Player in modo che apra i flussi di autenticazione nel browser predefinito del sistema operativo anziché in una finestra incorporata.

Requisiti di versione

Per l’autenticazione tramite il browser predefinito del sistema operativo, è necessario soddisfare i seguenti requisiti di versione di Tulip:* Lettore desktop 2.8 o superiore* Versione di fabbrica 318 o superiore

Comportamento della funzionalità

Questo comportamento si applica sia all'accesso al Desktop Player tramite SSO sia all'autorizzazione dei connettori OAuth all'interno delle app Tulip. In entrambi i casi, quando un utente avvia l'autenticazione, si apre il browser predefinito del sistema per gestire il seguente flusso:

1. Il browser di sistema si avvia e si collega alla pagina di accesso del provider di identità (IdP) della propria organizzazione.
2. L’utente completa l’accesso (inserendo le credenziali, completando l’autenticazione a più fattori (MFA), ecc.) nel browser esattamente come farebbe sul web.
3. Una volta completata l’autenticazione, la pagina del browser visualizza il seguente messaggio:"Fatto! Puoi chiudere questa finestra."
4. La finestra del browser rimane aperta. Non viene chiusa automaticamente. L’utente deve chiuderla manualmente.
5. Tulip Desktop Player rileva che l’accesso è stato completato e procede normalmente.

Richieste di autorizzazione previste

A seconda del sistema operativo e della configurazione del browser, gli utenti potrebbero visualizzare una o due richieste di autorizzazione:

1. Autorizzazione relativa al firewall / al server locale di Desktop Player (a livello di sistema operativo)

Quando viene avviata l'autenticazione, il Desktop Player crea un server locale temporaneo per ricevere la risposta di autenticazione. A seconda del sistema operativo e delle impostazioni di sicurezza, potrebbe apparire una richiesta del firewall di sistema o di accesso alla rete che chiede se il Desktop Player è autorizzato ad accettare connessioni in entrata.

• Azione richiesta: consentire la connessione. Si tratta di un comportamento previsto ed è necessario per il completamento dell’accesso.
• A seconda delle impostazioni del sistema operativo, questa richiesta potrebbe apparire solo la prima volta o ogni volta.

2. Autorizzazione all’accesso alla rete locale da parte del browser (a livello di browser)

Dopo che l’utente ha completato l’accesso tramite il proprio provider di identità, la pagina di completamento dell’autenticazione del browser invia il risultato al Desktop Player effettuando una richiesta al server locale descritto sopra. Alcuni browser visualizzano una richiesta di autorizzazione in cui si chiede se la pagina è autorizzata ad accedere ai dispositivi sulla rete locale.

• Azione richiesta: Consentire l’accesso. Si tratta di un passaggio sicuro e previsto nel flusso di autenticazione.
• La richiesta viene inviata esclusivamente a localhost e contiene solo la risposta di autenticazione crittografata. A questo punto non vengono trasmesse credenziali sensibili.

Riepilogo delle differenze visibili all’utente

La tabella seguente mette a confronto i comportamenti dell’autenticazione predefinita e dell’autenticazione abilitata dal browser del sistema operativo:

Esempio: Creazione di gruppi di accesso all’interno del proprio IdP

L'esempio seguente ti aiuterà a capire come tutte le diverse opzioni nelle impostazioni SAML possano essere utilizzate insieme.

Creazione di ruoli Tulip standardizzati

Ogni utente dovrà avere un attributo di ruolo specificato nel proprio IdP, in modo che Tulip possa determinare i suoi privilegi una volta che si sia autenticato con nome utente e password dell’IdP.

È inoltre possibile utilizzare questo campo "Ruolo" per determinare a quali siti l’utente ha accesso utilizzando una convenzione di denominazione standard. Sebbene un campo "Ruolo" possa essere semplicemente una variabile impostata, si consiglia di assegnare l’utente a gruppi specifici di Tulip all’interno del proprio IdP e di mapparli a un attributo.

Ruolo

A ogni utente verrà assegnato un unico ruolo in un’area di lavoro.

Quando Tulip riceve più ruoli validi per un utente, applica la seguente logica:

Se l’insieme include ruoli predefiniti (Operatore, Costruttore, ecc.), Tulip seleziona il ruolo predefinito con il rango più elevato in base a una gerarchia interna statica. I ruoli personalizzati sono sempre classificati al di sotto di tutti i ruoli predefiniti, quindi non verranno mai selezionati se è presente un ruolo predefinito.

Se l’insieme include solo ruoli personalizzati, Tulip seleziona il primo ruolo personalizzato ricevuto nel payload SAML.

Scopri di più sui ruoli utente di Tulip.

Sito

Supponiamo che la tua organizzazione disponga di due sedi, ciascuna con un Tulip Instance.

Possiamo indicare ciascun sito in base alla sua ubicazione (rispettivamente Texas e Londra).

Combinazione di sede e ruolo

Possiamo combinare queste due proprietà per creare una matrice di gruppi a cui assegnare gli utenti. Consigliamo alle organizzazioni di anteporre o aggiungere il valore "Tulip" al nome, in modo da facilitare il filtraggio.

Convenzione: tulip-siteRole

Se Jane Smith è la responsabile della sede in Texas, dovresti assegnarla al gruppo tulip-texasAccountOwner. Se Jane Smith ha bisogno anche dell'accesso in sola lettura alla sede di Londra, potrebbe essere aggiunta al gruppo tulip-londonViewer.

Rendere visibili questi gruppi come attributo per Tulip

Nel proprio IdP, Jane dovrebbe disporre di un attributo, tulip-role, a cui verranno mappati tutti i gruppi di cui è membro e che contengono il prefisso “tulip-”.

Quando effettua l’accesso a Tulip, l’attributo tulip-role presenta due valori: tulip-texasAccountOwner e tulip-londonViewer. È possibile configurare la mappatura dei ruoli per ogni Tulip instance individualmente, in modo che riceva le autorizzazioni corrette in ciascuna istanza.

Ruoli globali

Potresti anche voler creare ruoli di accesso globali, come ad esempio un ruolo “Viewer”. Questi utenti potranno accedere a ogni Tulip instance con le stesse autorizzazioni. Il formato consigliato è:

tulip-globalViewer

Dovrai configurare questa mappatura dei ruoli su ogni singola istanza nella pagina di configurazione SAML nelle Impostazioni dell’account per consentire a questo utente di accedere a ciascuna istanza.

{{snippet.Hai trovato quello che cercavi?}}