E depois, voltando, não na Grécia, estaremos discutindo em uma visão geral de alto nível sobre o salmão.
Portanto, Salmon significa a linguagem de marcação Security Association e é um mecanismo de comunicação
baseado em XML seguro para comunicar as identidades entre as organizações.
Agora, esse ponto será melhor entendido daqui a pouco.
Portanto, o salmão elimina a necessidade de manter várias credenciais de autenticação, como senhas em
vários locais.
Portanto, se você olhar para a maneira clássica, onde você tem vários aplicativos e serviços
em execução em sua organização e cada aplicativo tem suas próprias identidades.
Então Jenkins tem seu próprio nome de usuário e senha.
O editor tem seu próprio nome de usuário e senha em termos de H. R. o software de gerenciamento terá seu próprio nome de
usuário e senha e assim por diante.
Então ter isso é um pouco chato.
Portanto, vamos examinar alguns dos desafios da maneira clássica que estávamos discutindo.
O primeiro é que o administrador não tem realmente a visibilidade com o banco de dados subjacente
do provedor SAS.
Então, atualmente, estávamos discutindo sobre JENKINS '.
Portanto, se você estiver hospedando um Jenkins dentro do seu próprio serviço, terá uma boa visibilidade.
Mas há muitos provedores de serviços que não oferecem nenhuma visibilidade do banco de dados.
E, de fato, foi visto que muitos dos lugares onde os nomes de usuário e
senhas são armazenados subjacentes ao armazenamento em texto simples e até mesmo grandes organizações estão envolvidos aqui.
Portanto, este é um grande desafio.
O segundo desafio é que, se houver vários provedores de SaaS, é difícil controlar qual usuário
tem acesso a qual aplicativo SaaS.
Portanto, pode acontecer que o desenvolvedor tenha acesso ao Jenkins '.
No entanto, o desenvolvedor, Steve, tem acesso ao banco de dados e todos os usuários têm acesso a ele.
Portanto, no final, se um determinado usuário está deixando a organização, é difícil descobrir que o usuário tem acesso
a este aplicativo, especificamente se você tiver talvez um aplicativo dentro de sua organização.
E esse é o terceiro ponto, que quando o usuário sai da organização, ele precisa ser afastado
de todas as entidades.
Pode ser Jenkins, ET, etc. e assim por diante.
Por isso ainda lembro que na organização que tenho trabalhado para que qualquer usuário
que esteja saindo da organização no último dia apareça um formulário e precise da assinatura da autoridade.
Então, por exemplo, ele tem acesso a uma VPN e então ele vem para a nossa equipe e retiramos o acesso dele e depois
assinamos no documento, que ele terá que enviar para a API.
Então, em tais casos, ele terá que obter a assinatura de todos dizendo que seu usuário e seu acesso
foram removidos e Post enviará esse formulário ao ATO.
Então, nas organizações, quem realmente não tem logon único para fazer essas coisas é um pouco chato, porque agora você
terá que remover o acesso manualmente de todos os aplicativos.
Então, vamos examinar as diferentes visualizações aqui em uma abordagem clássica.
Portanto, a visão do administrador na abordagem clássica aqui é que ele terá que fazer logon em um provedor
diferente para gerenciar e controlar a permissão de um usuário individual em toda a organização.
E caso ele tenha esquecido seu nome de usuário e senha e talvez tenha perdido este para Amethi,
o administrador terá que definir o novo MFA em todos os aplicativos.
Então, isso é um pouco chato.
A segunda é que a visão dos usuários é que ele terá que lembrar a senha de todos os
aplicativos da organização.
E também pode estar presente que usar a ideia do usuário em todos os aplicativos é diferente.
Então este é mais aberto e a visão mais ampla do site no caso do provedor de serviço, se estiver armazenando o nome de
usuário e senha, o provedor de serviço terá que manter o banco de dados de nome de usuário e senha
de seus clientes.
E no caso, se este banco de dados vazar, então é um grande passivo de segurança deste aspirador.
Portanto, na visão clássica, o administrador, o usuário, assim como o sul da Flórida, nem todos estão contentes.
Então agora vem o melhor caminho, que é o mesmo.
Resumindo, o que você tem é um provedor de identidade e um provedor de serviços, o Banzet.
Então o provedor de serviço pode ser Jenkins, pode ser EWR, pode ser um set up e assim por diante.
E o provedor de identidade é aquele que vai armazenar todas as identidades.
Portanto, em vez de todas as identidades serem armazenadas em um provedor de serviços, movemos essa identidade para o site do provedor
de identidade.
Então, vamos dar uma olhada no diagrama de fluxo de trabalho onde você tem o provedor de identidade, tudo o que é o.
E o provedor de serviços para ADP.
Então o que acontecerá aqui é o uso de seu primeiro login para o provedor de identidade, o
provedor de identidade verificará se as credenciais estão corretas e uma resposta será dita.
Assim, o usuário seguirá em frente e enviará essa resposta ao provedor de serviços e ao provedor de serviços.
Se a resposta for a esperada, ela será redirecionada para o consultor de gestão.
Portanto, lembre-se de que, para que o provedor de serviços aceite essa resposta, é necessário que haja uma
relação de confiança entre o provedor de identidade e o provedor de serviços, que seria estabelecida antes de
todo o processo funcionar.
Então é isso que o Samawi é.
E essa resposta também pode ser referida como esta afirmação de Samael.
Então, vamos dar uma olhada em alto nível ou então o fluxo é iniciado quando o usuário abre o ADP preocupado e faz
o nome de usuário e senha e seleciona o aplicativo apropriado ou então o aplicativo pode ser um jenkins
afiado e assim por diante.
Portanto, o provedor de identidade validará as credenciais e as permissões associadas e, em seguida, as usará
para receber uma declaração Samit da parte do IDP da resposta.
Então, você sabe, estávamos discutindo essa resposta.
Esta é basicamente esta afirmação de Samin que o usuário recebe.
Assim, uma vez que o usuário tenha recebido esta afirmação, o usuário envia a maior parte dessa afirmação
Samin para a página de assinatura de origem e o provedor de serviços irá validar essa afirmação na validação.
O provedor de serviços construirá credenciais temporárias relevantes e também construirá uma garantia de assinatura para o console
e a enviará de volta ao usuário.
Então esse é o nível mais alto em que, você sabe, vamos dar uma olhada rápida em uma demonstração para que seja mais bem
compreendida.
Agora, a primeira etapa que estamos discutindo é que o usuário terá que enviar um nome de usuário e uma senha
ao provedor de identidade.
Então, eles seriam uma preocupação, algo semelhante a isso, e o nome de usuário e a senha precisariam
ser enviados.
Então, vamos tentar na grade.
Portanto, a autenticação foi bem-sucedida.
Agora, se você olhar aqui, depois que a autenticação for bem-sucedida, o usuário terá
que selecionar o aplicativo apropriado porque pode haver vários aplicativos presentes.
Portanto, pode ser um banco de dados, pode ser Jenkins ', pode ser outros.
Então, dependendo da aplicação, porque o provedor de serviço muda tudo de você para que você tenha um provedor de serviço
de W. S. Jenkins, etc.
Então, isso é importante.
Portanto, o que acontecerá é que, dependendo do provedor de serviços que o usuário escolher, a afirmação apropriada de
Samin será dita.
Então, vamos experimentar.
Assim que clico no console de gerenciamento atualmente em vigor, você vê que
é Stammen e basicamente se conecta e verifica e você está conectado à conta.
Então, algo aconteceu nos bastidores.
Assim como você recebeu a declaração do salmão, a Associação do Salmão foi encaminhada ao prestador de serviço.
O provedor de serviços validou aquele salmão, como eu disse, e ele adicionaria redirecionado para o console de
gerenciamento.
Então vamos fazer uma coisa para entender melhor.
Tenho um prensador de domingo instalado em minha equipe e usamos isso para ver o que exatamente acontece nos bastidores para entender este
processo em uma visão geral de alto nível.
Tudo bem.
Então, a primeira coisa que estávamos discutindo, o usuário irá clicar no console de gerenciamento.
Portanto, é conectar você e você está assinando.
Então vamos.
E.
Agora, deixe-me maximizar.
Portanto, a primeira coisa aqui é basicamente que a solicitação do portão está sendo feita.
Então este é o pedido de portão que está sendo feito para a ISS aqui.
Agora, se você olhar aqui, também há uma postagem agora, pois estávamos discutindo que, uma vez que essa afirmação seja
recebida, a postagem está sendo enviada para o prestador de serviço.
Então, se você olhar para esta solicitação de postagem específica, esta postagem foi enviada para esta página de assinatura de Dawe
com salmão.
Portanto, lembre-se de que o Eatables tem uma agência separada para autenticar se você estiver usando salmão.
Portanto, esta é a área exata de que você precisará para afundar sua afirmação sobre o salmão, como você estava
discutindo quando recebeu uma afirmação sobre o salmão.
Essa afirmação precisa ser enviada para um específico no caso de um dispositivo.
É essa Eweida.
Então é aqui que a postagem está acontecendo.
E se você olhar para o salmão, esta é a afirmação do salmão, que está sendo enviada, você sabe,
se você descer em.
Há uma pequena leitura que está entrando e dentro deste redirecionamento, se você olhar para a localização, esta é
a localização que está sendo compartilhada pelo AWB.
Assim, semelhante ao que estamos discutindo, uma solução semelhante está sendo enviada ao provedor de serviços,
o provedor de serviços verificará e enviará um redirecionamento para o console de gerenciamento.
E é isso que tem acontecido.
Essa é a visão geral de alto nível sobre o Simon.
E também verificamos como os únicos provedores de Sinon usam o Samin para ir em frente e permitir que os usuários se
conectem a um provedor de serviços específico para que este vídeo seja concluído.
Espero que este vídeo tenha sido informativo para você.
E estou ansioso para ver você no próximo vídeo.