E poi torna, non in Grecia, discuteremo ad alto livello di una panoramica sul salmone.
Quindi Salmon è l'acronimo di Security Association markup language ed è un meccanismo di comunicazione
sicuro basato su XML per comunicare le identità tra le organizzazioni.
Ora, questo punto sarà compreso meglio tra un momento qui.
Quindi il salmone elimina la necessità di mantenere più credenziali di autenticazione, come le password
in più posizioni.
Quindi, se esamini il modo classico in cui hai più applicazioni e servizi in esecuzione
all'interno della tua organizzazione e ogni applicazione ha le sue identità.
Quindi Jenkins ha il proprio nome utente e password.
L'editor ha il proprio nome utente e password in termini di H. R. il software di gestione avrà il proprio nome
utente e password e così via.
Quindi avere questi è un po' un dolore.
Quindi esaminiamo alcune delle sfide nel modo classico di cui stavamo discutendo.
Il primo è che l'amministratore non ha realmente la visibilità con il database sottostante del
provider SAS.
Quindi attualmente stavamo discutendo di JENKINS.
Quindi, se stai ospitando un Jenkins all'interno del tuo servizio, hai una buona visibilità.
Ma ci sono molti fornitori di servizi che in realtà non ti danno alcuna visibilità del database.
E infatti, è stato visto che molti dei luoghi in cui sono archiviati i nomi utente
e le password alla base della memorizzazione in testo semplice e anche le grandi organizzazioni sono coinvolte qui.
Quindi questa è una grande sfida.
La seconda sfida è che se ci sono più provider SaaS, è difficile tenere traccia di quale
utente ha accesso a quale applicazione SaaS.
Quindi potrebbe accadere che lo sviluppatore abbia accesso a Jenkins.
Tuttavia, lo sviluppatore, Steve, ha accesso al database e tutti gli utenti possono accedervi.
Quindi, alla fine, se un determinato utente lascia l'organizzazione, è difficile scoprire che l'utente ha accesso a questa
applicazione, in particolare se si dispone di un'applicazione all'interno della propria organizzazione.
Ed è proprio questo il terzo punto, che quando l'utente lascia l'organizzazione, deve essere rimosso da
tutte le entità.
Può essere Jenkins, ET, ecc. e così via.
Quindi ricordo ancora che nell'organizzazione con cui ho lavorato in modo che qualsiasi utente che
lascia l'organizzazione nel suo ultimo giorno si presenti con un modulo e abbia bisogno della firma dell'autorità.
Quindi, ad esempio, ha accesso a una VPN e quindi viene nel nostro team e gli rimuoviamo l'accesso e poi
lo firmiamo nel documento, che dovrà inviare all'API.
Quindi, in questi casi, dovrà prendere una firma da tutti dicendo che il suo utente e il suo accesso
sono stati rimossi e Post invierà quel modulo all'ATO.
Quindi nelle organizzazioni che non hanno davvero un single sign per fare queste cose è un po' una seccatura perché ora
dovrai rimuovere manualmente il suo accesso da tutte le applicazioni.
Quindi esaminiamo i diversi punti di vista qui in un approccio classico.
Quindi gli amministratori vedono nell'approccio classico qui che dovrà accedere a un provider diverso
per gestire e controllare l'autorizzazione di un singolo utente all'interno dell'organizzazione.
E nel caso in cui abbia dimenticato il nome utente e la password e magari abbia perso questo
per Amethi, l'amministratore dovrà impostare il nuovo MFA su tutte le applicazioni.
Quindi questo è un po' un dolore.
Il secondo è che gli utenti visualizzano la visualizzazione degli utenti è che dovrà ricordare la password di tutte le
applicazioni all'interno dell'organizzazione.
E potrebbe anche essere presente che l'idea di utilizzo dell'utente tra le applicazioni è diversa.
Quindi questo è più aperto e la visione più ampia del sito nel caso in cui il fornitore di servizi, se sta memorizzando
il nome utente e la password, il fornitore di servizi dovrà mantenere il database di nome utente e password
dei propri clienti.
E nel caso, se questo database è trapelato, allora è una grande responsabilità per la sicurezza di questo aspiratore.
Quindi nella visualizzazione classica, l'amministratore, l'utente, così come il sud della Florida, non sono tutti contenti.
Quindi ora arriva il modo migliore, che è lo stesso.
Quindi, in sintesi, quello che hai, hai un provider di identità e hai un provider di servizi, Banzet.
Quindi il fornitore di servizi può essere Jenkins, può essere EWR, può essere una configurazione e così via.
E il provider di identità è quello che memorizzerà tutte le identità.
Quindi, invece di archiviare tutte le identità presso un provider di servizi, spostiamo quell'identità nel sito del provider di
identità.
Quindi diamo un'occhiata al diagramma del flusso di lavoro in cui hai il provider di identità, tutto ciò che è il.
E il fornitore di servizi per ADP.
Quindi ciò che accadrà qui è l'uso del suo primo accesso al provider di identità, il provider
di identità verificherà se le credenziali sono corrette e verrà data una risposta.
Quindi l'utente andrà avanti e invierà quella risposta al fornitore di servizi e al fornitore di servizi.
Se la risposta è quella prevista, verrà reindirizzata al consulente di gestione.
Quindi ricorda che affinché il fornitore di servizi accetti questa risposta, deve esserci un rapporto di fiducia
tra il fornitore di identità e il fornitore di servizi, che sarebbe stato stabilito prima che
l'intero processo funzionasse.
Quindi questo è ciò che è il Samawi.
E questa risposta può anche essere chiamata questa affermazione di Samael.
Quindi diamo un'occhiata al livello più alto o giù di lì il flusso viene avviato quando l'utente apre l'ADP preoccupato e fa
il nome utente e la password e seleziona l'applicazione appropriata o così l'applicazione può essere un jenkins con
bordi e così via.
Quindi il provider di identità convaliderà le credenziali e le autorizzazioni associate e quindi utilizzerà su
di esso, riceverà un'asserzione Samit dalla parte della risposta dell'IDP.
Quindi, sai, stavamo discutendo di questa risposta.
Questa è fondamentalmente questa affermazione di Samin che l'utente riceve.
Quindi, una volta che l'utente ha ricevuto questa asserzione, l'utente esegue la maggior parte di tale asserzione
Samin nella pagina di firma della fonte e il fornitore di servizi convaliderà tali asserzioni al momento della convalida.
Il fornitore di servizi creerà credenziali temporanee pertinenti e creerà anche un mandato di firma per
la console e lo rispedirà all'utente.
Quindi questo è il livello più alto in cui, sai, esaminiamo rapidamente una demo in modo che questo venga compreso
meglio.
Ora, il primo passaggio di cui stiamo discutendo è che l'utente dovrà inviare un nome utente e una password
al provider di identità.
Quindi sarebbero una preoccupazione, qualcosa di simile a questo, e il nome utente e la password dell'utente dovrebbero
essere inviati.
Quindi proviamolo sulla griglia.
Quindi l'autenticazione è andata a buon fine.
Ora, se guardi qui, una volta che l'autenticazione ha esito positivo, l'utente
dovrà selezionare l'applicazione appropriata perché potrebbero essere presenti più applicazioni.
Quindi può essere un database, può essere di Jenkins, può essere altri.
Quindi, a seconda dell'applicazione, perché il fornitore di servizi ti cambia tutto in modo da avere un fornitore di servizi di
un W. S. Jenkins, ecc..
Quindi questo è importante.
Quindi ciò che accadrà dipenderà dal fornitore di servizi che l'utente sceglie, verrà detta l'asserzione
Samin appropriata.
Quindi proviamolo.
Quindi, non appena clicco sulla console di gestione attualmente in corso, vedi
che è Stammen e fondamentalmente sta effettuando l'accesso e verifica e sei connesso all'account.
Quindi dietro le quinte sono successe cose del genere.
Come hai ricevuto l'affermazione del salmone, la Salmon Association è stata inoltrata al fornitore di servizi.
Il fornitore di servizi aveva convalidato quel salmone, come ho detto, e avrebbe aggiunto reindirizzato alla console di
gestione.
Quindi facciamo una cosa per capirlo meglio.
Ho installato un pressa domenica nella mia squadra e lo usiamo per vedere cosa succede esattamente dietro le quinte per comprendere questo
processo a una panoramica di alto livello.
Va bene.
Quindi la prima cosa che stavamo discutendo, l'utente farà clic sulla console di gestione.
Quindi ti sta registrando e tu stai firmando.
Quindi andiamo.
E.
Quindi ora fammi massimizzare.
Quindi la prima cosa qui è fondamentalmente la richiesta di gate.
Quindi questa è la richiesta del cancello che viene fatta alla ISS qui.
Ora, se guardi qui, ora c'è anche la posta poiché stavamo discutendo che una volta ricevuta questa
affermazione, la posta verrà inviata al fornitore di servizi.
Quindi, se esamini questa specifica richiesta di post, questo post è stato inviato a questa pagina di firma di Dawe
con salmone.
Quindi ricorda che Eatables ha un ufficio separato per l'autenticazione se stai usando salmone.
Quindi questa è l'area esatta di cui avrai bisogno per affondare la tua affermazione di salmone, come stavi discutendo una
volta che hai ricevuto un'affermazione di salmone.
Tale affermazione deve essere inviata a uno specifico in nel caso di un dispositivo.
È questa Eweida.
Quindi è qui che sta accadendo il post.
E se guardi nel salmone, questa è l'affermazione del salmone, che viene inviata a, sai,
se scendi a.
C'è una piccola lettura che sta arrivando e all'interno di questo reindirizzamento, se guardi nella posizione, questa
è la posizione che viene condivisa dall'AWB.
Quindi, in modo simile a quello di cui stiamo discutendo, una soluzione simile viene inviata al fornitore
di servizi, il fornitore di servizi verificherà e quindi invierà un reindirizzamento alla console di gestione.
Ed è quello che sta succedendo.
Quindi questa è la panoramica di alto livello su Simon.
E esaminiamo anche come i singoli fornitori di Sinon utilizzino Samin per andare avanti e consentire agli utenti di connettersi a
un fornitore di servizi specifico in modo che questo concluda questo video.
Spero che questo video sia stato informativo per te.
E non vedo l'ora di vederti nel prossimo video.