Come stai?
E bentornato.
Ora, nel video di oggi, parleremo del concetto di federazione.
Ora, prima di andare avanti e approfondire la questione, prendiamo un semplice caso d'uso per
comprendere la sfida che molti milioni di persone devono affrontare e la maggior parte delle organizzazioni su larga scala.
Si supponga quindi che ci siano 500 utenti all'interno dell'organizzazione e che questa organizzazione stia utilizzando tre
servizi primari attivamente.
Il primo è l'aiuto, almeno per le infrastrutture.
Il secondo è Jenkins e il terzo è l'applicazione relativa all'età.
E il tuo ruolo è fondamentalmente quello di fornire agli utenti l'accesso a tutti e tre i servizi.
Assumiamo quindi che tutti gli utenti, tutti i 500 utenti all'interno dell'organizzazione debbano avere accesso a
tutti e tre i sistemi.
Ora, una delle sfide che vedremo per prima è che dovrai creare utenti individuali in tutti
e tre questi sistemi.
Quindi, in entrambi gli elenchi, dovrai creare un utente IAM nel sistema di gestione dell'HIV.
Ancora una volta, dovrai creare un utente e così via.
Quindi ora supponiamo che un nuovo utente si sia unito alla tua organizzazione o che un nuovo utente lasci la tua organizzazione.
Quindi essenzialmente dovrai accedere a tutte queste tre applicazioni per aggiungere o rimuovere gli utenti.
Ora, supponiamo che ci siano due nuove applicazioni in arrivo nell'organizzazione.
Quindi, essenzialmente, ancora una volta, dovrai aggiungere tutti i 500 utenti al prossimo nuovo sistema a due che è stato
pianificato.
Quindi questo non è davvero un modo molto efficiente di fare le cose.
Quindi questa è una delle sfide che dovrai davvero affrontare nell'organizzazione su scala medio-grande.
In particolare, quando si parla di organizzazioni su larga scala che hanno migliaia di
utenti in questo caso non è consigliabile gestire gli utenti in ogni singolo sistema così come l'identità.
Quindi, per ovviare a questo, sostanzialmente ciò che viene utilizzato il sistema è memorizzare il centro utenti.
Quindi diciamo che hai un sistema.
Quindi in questa vecchia app hai tutte le identità degli utenti memorizzate.
Quindi tutto il nome utente e tutte le password sono archiviate in questa directory centrale.
E questa singola directory è collegata a tutti i sistemi in modo tale che gli utenti del centro possano
accedere direttamente con nome utente e password a tutti e tre i sistemi.
Quindi questa diventa un'architettura molto più efficiente perché ci sarà un solo set di
nome utente e password che verrà archiviato al livello finale e dalla fine.
Poiché ci sarà una fiducia tra tutti questi sistemi, l'utente può accedere facilmente.
Quindi ogni volta che un nuovo utente si unisce all'organizzazione, tutto ciò che l'amministratore deve fare, deve aggiungere il
suo utente come parte della vecchia app, e questo è tutto.
Sarà in grado di accedere a tutti e tre i sistemi e forse domani è prevista l'aggiunta di un nuovo
sistema nella tua organizzazione.
Tutto quello che devi fare è fidarti tra la tua vecchia app e quel nuovo sistema e tutti
gli utenti esistenti potranno accedere anche ai nuovi sistemi.
Ora, ci sono molte soluzioni che ci consentono di archiviare l'utente centralmente.
Uno dei principali che potresti aver sentito è Microsoft Active Directory.
Si tratta di una soluzione molto apprezzata che permette di archiviare il centro utenti e permette anche di avere
una gestione ordinata.
Il secondo popolare specifico per Linux è Red Hat Identity Management, noto anche come app
gratuita.
Quindi, se guardi nello screenshot, questo è associato ad Active Directory e vedi che
ci sono più utenti che sono stati aggiunti qui e l'edizione dell'ordine dell'utente è molto semplice.
Puoi fare clic su Nuovo e puoi fare clic su utente e un nuovo utente verrà aggiunto alla tua Active Directory.
Quindi ora diciamo che hai Active Directory e hai questi tre sistemi.
Quello che devi fare, devi fidarti tra la tua Active Directory e questi tre sistemi
in modo tale che gli utenti che fanno parte della tua Active Directory possano accedere a tutti e
tre i sistemi a seconda della politica che hai impostato.
Grande.
Quindi, con questo, andiamo avanti e comprendiamo le basi della federazione da una prospettiva idealista.
Quindi, in sostanza, la federazione consente alle identità esterne denominate anche utenti federati di avere un
account commestibile interno ad accesso protetto senza dover creare utenti e utenti.
Quindi abbiamo già discusso del fatto che le identità non sono archiviate in un luogo, queste sono
archiviate in un server centrale come Active Directory e tutti questi utenti saranno in grado di accedere al tuo account.
Quindi questo è ciò che il concetto della Federazione entra davvero in scena.
Quindi queste identità esterne possono provenire da varie fonti come il provider di identità aziendale può essere
Active Directory IPA, provider di identità web.
Facebook.
Google.
Amazon.
Incognito o aperto, a seconda del caso d'uso che desideri ottenere.
Ora esaminiamo rapidamente il flusso di lavoro di alto livello quando discutiamo della federazione.
Quindi ci sono tre entità primarie che sono coinvolte.
Il primo è l'utente.
Il secondo è il provider di servizi e il terzo è il provider di identità.
Nessun fornitore di servizi è fondamentalmente queste applicazioni sul lato destro di cui stavamo discutendo, come Jenkins EAW è
un sistema di gestione dei dati, ecc.
Inoltre, questi sono i fornitori che forniscono alcuni servizi.
Quindi hai un provider di identità dal nome stesso.
Possiamo identificare cosa fa esattamente questo.
Questo fornisce identità.
Quindi ciò significa sostanzialmente che gli utenti sono archiviati a livello di provider di identità e ciò che il provider di
servizi e il provider di identità esiste una relazione di fiducia tra entrambi.
Quindi questo provider di servizi si fida del provider di identità e quindi gli utenti che provengono
da questo provider di identità potranno accedere al provider di servizi a seconda delle politiche che hai
stato.
Va bene.
Quindi, se guardi nel diagramma, l'utente si autentica prima con il provider di identità.
Non si autentica con un fornitore di servizi.
Quindi questo significa sostanzialmente che diciamo che questo flusso di lavoro è quello di EWR.
Quindi è un fornitore di servizi e c'è un fornitore di identità come Okta.
Quindi gli utenti verranno memorizzati a livello di ottano.
Gli utenti non verranno archiviati a livello di database.
Quindi l'utente si autenticherà prima con il provider di identità.
Ora, poiché esiste una relazione, una relazione di fiducia tra l'IDP e il fornitore di servizi,
l'utente, una volta che si è autenticato con successo con il fornitore di identità, sarà in grado di fare
una richiesta con successo al fornitore di servizi di EWR.
Quindi, con questo, andiamo avanti e comprendiamo rapidamente le cose in modo più dettagliato.
In primo luogo, il concetto importante qui è il broker di identità.
Quindi il broker di identità è un servizio intermedio che collega più provider qui.
Quindi, sotto l'identità, hai un idlis.
Sul lato sinistro, hai una Active Directory che contiene tutti i nomi utente e le password
per tutti i dipendenti della tua organizzazione.
Quindi, che cosa vuoi?
Vuoi intimidire il servizio che può connettere entrambi.
Quindi questo è ciò che viene indicato come il broker di identità.
Quindi andiamo avanti e diamo un'occhiata al video funzionante.
Sul lato destro, hai il posto, sul lato sinistro hai l'Active Directory e ancora
sul posto.
Quindi prima gli utenti dovranno accedere al broker di identità.
Quindi questo broker di identità è connesso a Microsoft Active Directory.
Quindi, in pratica, quale nome utente e password l'utente ha fornito al broker di identità corrisponde a quello
di quello archiviato in Active Directory?
Quindi è qui che avviene davvero l'autenticazione.
Il primo passo è accedere.
Il secondo passaggio consiste nell'autenticare l'utente con Active Directory.
Una volta che l'autenticazione ha esito positivo, questo broker di identità procederà e chiamerà il servizio
A spear e riceverà un token specifico, quindi il broker di identità invia la risposta appropriata al
client.
E questo token è ciò che è stato nuovamente rifiutato utilizzato per connettersi ai servizi Web Amazon.
Quindi, quando discutiamo di questo autore, questo è un segno.
Questo non è altro che un insieme di chiavi di accesso e segrete.
Quindi agli utenti sono state fornite chiavi di accesso e segrete e gli utenti possono utilizzare tali chiavi segrete di
accesso per connettersi all'EWG.
Quindi questo è il flusso di lavoro di alto livello su come funzionerebbero le cose da un punto di vista federato, credo.
Quindi andiamo avanti e rivediamo rapidamente i passaggi.
Il primo sono gli utenti che accedono con il nome utente e la password e queste credenziali vengono fornite al
broker di identità.
Ora Identity Broker convalida queste credenziali rispetto ad Active Directory.
In questo esempio, abbiamo preso Active Directory.
Se le credenziali sono valide.
Fondamentalmente, se il nome utente e la password sono validi, il broker contatterà il servizio SDR poiché questo
andrà avanti e restituirà la sicurezza di accesso.
E questa chiave segreta di accesso verrà fornita dal broker di identità all'utente e l'utente potrà accedere alla console
del database o utilizzare in modo sicuro questo set di chiavi segrete di accesso insieme al token specifico,
che ha una durata specifica.
Quindi se non riesci a ricordare quando discutiamo di identità, identità, nient'altro che utenti.
Quindi, quando discutiamo delle nostre identità esterne, ciò significa sostanzialmente che gli utenti sono archiviati in un
sistema esterno, non in IEM.
Il secondo è il broker di identità, che è fondamentalmente un middleware che porta l'utente dal punto e lo aiuta a
connettersi al punto B.
E il terzo concetto importante è l'identità memorizzata, che è fondamentalmente un luogo in cui si trovano gli utenti, ma
come vengono archiviati gli altri utenti.
Quindi Active Directory o IP o forse Facebook.
Quindi queste sono fondamentalmente l'identità memorizzata.
Ora prima di concludere, cose molto importanti che volevo condividere.
Il primo è che affinché la Federazione funzioni, anche questo fornitore di servizi dovrebbe supportare quella funzionalità perché
alla fine ne stavamo discutendo.
Il provider di identità memorizzerà le identità e costituiranno una relazione di fiducia tra l'identità fornita e anche quella
del provider di servizi.
Ora, se il provider di servizi non supporta affatto quella funzionalità, non puoi davvero avere
una federazione.
Quindi questa è una parte importante da ricordare.
Ora, quando discutiamo di Idlis, quando vai alla console IAM, hai un'opzione specifica di quella del
provider di identità.
Quindi è qui che puoi andare avanti e aggiungere più provider di identità.
Quindi, nel menu Gordon identity, a condizione che tu debba sostanzialmente specificare un tipo di provider, nonché il documento di metadati di
quello del tuo provider di identità.
Quindi, ad esempio, supponiamo che tu abbia scelto il provider di identità di OCTA.
Quindi OCTA è una piattaforma di provider di identità molto popolare.
Quindi questo documento di metadati di cui stavamo discutendo, proviene da OCTA.
Quindi, dopo aver configurato le impostazioni della richiesta in OCTA, puoi procedere e caricare questo
documento di metadati dopo averlo scaricato da OCTA.
Ed è così che a un audit di alto livello, la fiducia si verifica davvero tra un fornitore di servizi e
quella del fornitore di identità.
Quindi questa è una parte.
Seconda cosa di cui stavamo discutendo, prendiamo un esempio di Jenkins.
Andiamo rapidamente su Manager Jenkins e configuriamo la sicurezza globale.
Quindi, in pratica, ciò di cui stiamo discutendo in questi account relativi al modo in cui i dati dell'utente vengono archiviati centralmente
in un laboratorio, dovrebbe essere in grado di accedere a un'applicazione specifica come Jenkins.
Ora, se Jenkins non lo rilascia o lo inserisce, l'intero concetto non funzionerà davvero.
Quindi Jenkins dovrà anche supportare un punto di vista specifico di LDAP.
Quindi, se andrai alle impostazioni di Jenkins sotto URI, hai sostanzialmente due opzioni importanti.
Il primo è il database utente di Jenkins.
Quindi ciò significa fondamentalmente che ogni volta che vai avanti e aggiungi un utente, lo aggiungi al database Jenkins e hai anche
la possibilità di consentire all'utente di dire, no, questo è uno.
Ora vediamo, mentre stiamo discutendo, non vuoi davvero creare l'utente individualmente nel singolo sistema.
Cosa vuoi?
Vuoi finire?
Quindi hai anche un'opzione per una dashboard qui e al suo interno dovrai fornire i dettagli della parola dell'episodio
finale.
Quindi, una volta che hai quel server, fornisci i dettagli a quello di Jenkins e, una volta che hai la
configurazione necessaria, gli utenti che fanno parte di un LDAP saranno in grado di accedere all'audio Jenkins.
Giusto.
Quindi questa è la panoramica di alto livello.
Nel caso in cui questo sia qualcosa che ti interessa davvero, allora Okta è una piattaforma popolare che puoi
provare.
Hanno anche più certificazioni associate, che sono abbastanza buone.
Quindi questo è qualcosa che non vedi l'ora di fare.
Questa è la panoramica di alto livello sulla Federazione.
E con questo si concluderà il video di oggi.