Atlassian SSO : creare un inventario di Identity Assets

Questa è la seconda tappa di un viaggio all’esplorazione dell’implementazione di una soluzione SSO nell’ecosistema Atlassian scritto da RE:SOLUTION, partner Atlassian Platinum Marketplace e produttore delle principali app SSO per lo stack Atlassian.

In questo articolo ti mostreremo i passaggi per inventariare le tue risorse di identity esistenti. Una volta completato l’inventario, delineare il progetto di implementazione e scegliere i fornitori di SSO dovrebbe essere semplice.

Allora, cosa hai intenzione di fare al riguardo?

Nell’ultimo articolo, abbiamo offerto una panoramica dei punti deboli più comuni che possono toccare un’azienda quando non è stata implementata alcuna soluzione Single Sign-On, o se non viene estesa a importanti software aziendali come gli strumenti Atlassian.

Ora capisci che senza SSO gli utenti finali manterranno cattive abitudini relative alle password.

Il tuo Help Center sarà invaso da richieste di recupero della password.

E, con disperazione dei tuoi esperti di sicurezza, i tuoi admin continueranno a dimenticarsi di disattivare gli ex dipendenti dalla directory interna di Jira.

Passaggio 1. Inventario delle applicazioni web

Quale software usano i tuoi dipendenti? Completare un inventario di tutte le app B2B utilizzate nella tua organizzazione è più facile a dirsi che a farsi.

Da alcune stime, i dipendenti hanno utilizzato una media di 191 account nel 2017; ma circa la metà della forza lavoro utilizza software che non sono stati distribuiti dal proprio reparto IT.

Intervista i colleghi di diversi reparti e spiega loro i vantaggi di portare ogni possibile applicazione sotto il tetto di un unico accesso centralizzato.

Una percentuale di queste applicazioni sarà costituita da piccoli fornitori SaaS che il responsabile di dipartimento ha acquistato con una carta di credito aziendale senza richiedere l’approvazione del budget. Questo tipo di prodotti hanno tutte le possibilità di diventare Shadow IT: non contabilizzati e sconosciuti al reparto IT finché non si verifica un problema.

Tuttavia, ai fini del Single Sign-On dovresti preoccuparti solo delle app pertinenti:

Sono usati tutti i giorni da alcuni ruoli
Sono essenziali per completare la descrizione del lavoro del dipendente
Hanno account utente individuali
Contengono dati sensibili sull’azienda che non dovresti divulgare

Strumenti Atlassian come Jira, Confluence o Bitbucket soddisfano tutti i punti dell’elenco.

In caso di dubbio, una rapida scansione della sensibilità dei dati dovrebbe essere sufficiente per convincerti: Bitbucket è il repository per il software dell’azienda; Jira Software ha tutti i piani sulle funzionalità future del prodotto, mentre Jira Service Desk contiene centinaia di conversazioni con i clienti; infine, Confluence viene utilizzato per organizzare e diffondere documentazione, piani aziendali strategici e collegamenti a risorse riservate.

Passaggio 2. Verificare quali applicazioni supportano SSO

Una volta che sai quali applicazioni web devi connettere alla tua soluzione SSO, dovresti eseguire un rapido controllo:

L’applicazione supporta SSO in modo nativo?
Se sì, quali protocolli possono essere utilizzati per collegarlo? SAML, OAuth / OIDC, SSH o protocolli più vecchi?
In caso negativo, sono disponibili connettori commerciali su cui fare affidamento raggiungere il risultato?

Le applicazioni Atlassian on-premise, ad esempio, non supportano SSO in modo nativo. Tuttavia, ci sono molte alternative nel Marketplace Atlassian che consentono loro di connettersi agli IdP, principalmente tramite SAML. Il SAML SSO di Resolution è l’esempio più importante.

Nel caso del Data Center è disponibile anche un’app SAML SSO gratuita di Atlassian che copre una parte delle specifiche SSO, inclusa l’autenticazione e alcuni altri aspetti della gestione utenti. Entreremo più in dettaglio nel seguente articolo di questa serie.

Passaggio 3. Controllo della directory utente

Per ciascuna delle applicazioni nel tuo inventario, dovrai chiederti: dove sono gli utenti dell’applicazione? Sono archiviati internamente nell’applicazione o provengono da una directory utente aziendale?

Nel caso degli utenti Atlassian, ci sono tre principali opzioni non-SSO:

Opzione 1. Gli utenti vengono archiviati nell’Active Directory di Microsoft

Active Directory ha iniziato a essere una tecnologia legacy dall’avvento Windows 2000, ma è ancora il punto di partenza più comune per molte aziende che utilizzano Windows Server.

Quando i tuoi utenti sono archiviati in AD, possono essere sincronizzati con le applicazioni Atlassian utilizzando LDAP, quindi potranno utilizzare le loro credenziali AD per l’accesso Atlassian.

Pro: è un’opzione ben collaudata, supportata nativamente dalle applicazioni Atlassian. Inoltre, molti clienti stanno già utilizzando AD FS per l’integrazione con servizi Cloud come Office 365 o Salesforce tramite SAML. E se non l’hanno ancora fatto, possono farlo gratuitamente.

Contro: LDAP è una scelta molto limitata negli approcci remoti: di solito richiede firewall e VPN, ha una scalabilità scarsa in termini di prestazioni e non è supportato da molti provider di identità cloud.

Opzione 2. Gli utenti vengono archiviati nella directory interna di Jira

La directory interna di Jira può anche essere collegata ad altri prodotti Atlassian come Confluence per essere utilizzata come fonte di utenti.

Pro: gli utenti non devono essere gestiti in altre applicazioni Atlassian: possono essere gestiti centralmente dalla directory interna di Jira.

Contro: lo svantaggio più importante è che le applicazioni Atlassian resterebbero isolate rispetto al resto dei tuoi strumenti. Ogni volta che modifichi l’accesso e le autorizzazioni per un dipendente, dovrai almeno farlo due volte: una per le app Atlassian, un’altra per le altre tue directory.
Inoltre, quando Jira è inattivo, l’intero stack Atlassian non sarà disponibile.

Opzione 3. Gli utenti vengono sistemati in più directory, ma centralizzati con Crowd

Molte aziende hanno più istanze storiche on-premise, ognuna con le proprie peculiarità e le proprie impostazioni. Spesso alcuni sono Data Center, altri sono Server. Piuttosto che unire tutto, standardizzare e consolidare in una mega istanza, è più semplice accettare la complessità e aggiungere Crowd al mix per centralizzare la gestione degli utenti.

Pro: la federazione di più istanze Atlassian con Crowd è abbastanza semplice e si possono gestire gli utenti e le loro autorizzazioni su directory diverse.

Contro: Crowd è venduto come soluzione SSO, ma questo è vero solo per i prodotti Atlassian. Se un utente connesso a Crowd cerca di accedere a uno strumento non Atlassian in cui non ha una sessione aperta, gli verrà chiesto di accedere. Inoltre, Crowd non può gestire le risposte SAML da un IdP.

Passaggio 4. Analizza le opportunità IdP

Avrai bisogno di un Identity Provider che possa servire come unica fonte di verità per le identità degli utenti in tutte le tue applicazioni.

Un nuovo IdP può rappresentare un impegno finanziario significativo. Tuttavia, a volte puoi ottenere gratuitamente uno dei migliori fornitori di IdP se stai già utilizzando la loro tecnologia per altri scopi. Diamo una rapida occhiata agli scenari più comuni.

Per maggiori dettagli, dai un’occhiata alla valutazione indipendente che Resolution ha fatto degli IdP più importanti.

Scenario 1: Microsoft Active Directory

È la seconda volta che incontriamo l’AD in questo articolo e non è una coincidenza.

Se i tuoi amministratori stanno già utilizzando Active Directory per gestire l’accesso dei dipendenti e le autorizzazioni per le risorse della tua rete, puoi usufruire gratuitamente dell’SSO basato su SAML. Utilizza semplicemente il ruolo AD Federation Services e inizia a usare ADFS come provider di identità.

Scenario 2: Office 365

Uno scenario simile a quello sopra, ma con degli extra Cloud dell’ambiente Microsoft. Se la tua azienda utilizza Office 365, puoi ottenere Azure Active Directory senza costi aggiuntivi.

In tal caso, tieni presente che la versione gratuita di AD FS presenta alcune importanti limitazioni. Puoi vedere tutti i dettagli qui, ma il nostro riepilogo potrebbe già darti un’idea:

Puoi usare solo le applicazioni nel catalogo delle app di Azure (non preoccuparti troppo, anche Resolution è nel catalogo)
Alcune funzionalità avanzate come le assegnazioni degli utenti saranno disponibili solo per utenti specifici
I criteri di accesso condizionale, incluso l’AMF, non sono disponibili.

Scenario 3: GSuite

Tutti hanno un account Gmail e migliaia di aziende, in particolare negli Stati Uniti, hanno adottato GSuite per le loro applicazioni per ufficio. Se questo è il tuo caso, scegliere Cloud Identity di Google è un’opzione naturale.

Cloud Identity Premium è incluso nel livello premium di GSuite con un costo di $ 25 per utente al mese.

Conclusione

In questo articolo abbiamo visto come creare un inventario completo delle tue risorse di identità che includa applicazioni B2B sensibili, directory utente per i tuoi utenti Atlassian e opzioni comuni per aggiungere un fornitore IdP dal tuo stack esistente. Nel prossimo articolo della serie esamineremo le domande essenziali a cui devi rispondere per definire l’ambito della tua implementazione SSO prima di intraprenderla.

Sarà sufficiente una semplice configurazione? Collegherai più istanze di diversi prodotti Atlassian (2 Confluences, 5 Jiras) in diversi deployment? E automatizzerai la creazione e la disattivazione degli utenti? Queste sono alcune delle domande che influenzeranno il tuo progetto.

Resta sintonizzato per continuare nel viaggio verso un Single Sign-On di successo per i tuoi strumenti Atlassian.

Vuoi sapere di più sui vantaggi di una soluzione Single Sign-On? E come utilizzarla con i tuoi tool Atlassian per aumentare sicurezza e semplicità di utilizzo, non solo all’interno dell’azienda?

CONTATTACI