Como vai?
E bem-vindo de volta.
Agora, no vídeo de hoje, vamos discutir sobre o conceito de federação.
Agora, antes de prosseguir e analisá-lo com mais detalhes, vamos analisar um caso de
uso simples para entender o desafio que muitos milhões enfrentam e a maioria das organizações de grande escala enfrenta.
Portanto, vamos supor que haja 500 usuários em sua organização e que essa organização esteja usando três
serviços principais ativamente.
A primeira é a ajuda, pelo menos para infra-estrutura.
O segundo é Jenkins e o terceiro é o aplicativo relacionado à idade.
E seu papel é basicamente dar aos usuários acesso a todos os três serviços.
Então vamos supor que todos os usuários, todos os 500 usuários dentro da organização precisam ter acesso
a todos esses três sistemas.
Agora, um dos desafios que veremos primeiro é que você terá que criar usuários individuais em
todos esses três sistemas.
Portanto, em qualquer lista, você terá que criar um usuário do IAM no sistema de gerenciamento de HIV.
Novamente, você terá que criar usuário e assim por diante.
Agora, digamos que um novo usuário ingressou na sua organização ou um novo usuário está deixando sua organização.
Então, essencialmente, você terá que fazer login em todos esses três aplicativos para adicionar ou remover os usuários.
Agora, vamos supor que há dois novos aplicativos que estão chegando na organização.
Então, essencialmente, novamente, você terá que adicionar todos os 500 usuários aos próximos dois novos sistemas que estão sendo
planejados.
Portanto, esta não é realmente uma maneira muito eficiente de fazer as coisas.
Portanto, esse é um dos desafios que você realmente enfrentará na organização de médio a grande porte.
Especificamente, quando você discute sobre organizações de grande porte que têm milhares de usuários,
nesse caso, o gerenciamento dos usuários em cada sistema não é recomendado, assim como a identidade.
Então, para superar isso, basicamente o que o sistema é usado é armazenar a central do usuário.
Digamos que você tenha um sistema.
Portanto, neste aplicativo antigo, você tem todas as identidades dos usuários armazenadas.
Assim, todo o nome de usuário e todas as senhas são armazenadas neste diretório central.
E este diretório único está conectado a todos os sistemas de tal forma que os usuários do centro podem fazer
login diretamente com o nome de usuário e senha em todos esses três sistemas.
Portanto, isso se torna uma arquitetura muito mais eficiente porque haverá apenas um único conjunto de nome
de usuário e senha que será armazenado no nível final e a partir do final.
Como haverá uma relação de confiança entre todos esses sistemas, o usuário pode fazer login facilmente.
Portanto, sempre que um novo usuário ingressar na organização, tudo o que o administrador precisa fazer, ele precisa
adicionar seu usuário como parte do aplicativo antigo, e pronto.
Será capaz de fazer login em todos esses três sistemas e talvez amanhã um novo sistema esteja planejado para ser
adicionado em sua organização.
Tudo o que você precisa fazer é confiar entre seu aplicativo antigo e esse novo sistema e todos
os usuários existentes também poderão fazer login nos novos sistemas.
Agora, existem muitas soluções que nos permitem armazenar o usuário centralmente.
Um dos principais que você pode ter ouvido é o Microsoft Active Directory.
Esta é uma solução muito popular que permite armazenar o centro do usuário e também permite que você tenha
um gerenciamento ordenado.
O segundo aplicativo popular especificamente para Linux é o Red Hat Identity Management, também conhecido como aplicativo
gratuito.
Portanto, se você observar a captura de tela, ela está associada ao Active Directory e
verá que vários usuários foram adicionados aqui e a edição do pedido do usuário é muito simples.
Você vê que pode clicar em Novo e clicar em usuário e um novo usuário será adicionado ao seu Active Directory.
Agora, digamos que você tenha o Active Directory e esses três sistemas.
O que você precisa fazer, você tem que confiar entre seu Active Directory e esses
três sistemas de tal forma que os usuários que fazem parte de seu Active Directory possam fazer login em
todos esses três sistemas, dependendo da política que você definiu.
Excelente.
Então, com isso, vamos em frente e entender os fundamentos da federação a partir de uma perspectiva idealista.
Então, basicamente, a federação permite que identidades externas também chamadas de usuários federados tenham uma conta
de alimentação interna de acesso seguro sem ter que criar nenhum e usuários.
Portanto, já discutimos que as identidades não são armazenadas em um local, elas são armazenadas
em um servidor central como o Active Directory e todos esses usuários poderão fazer login em sua conta.
Então é isso que o conceito de Federação realmente entra em cena.
Portanto, essas identidades externas podem vir de várias fontes, como o provedor de identidade corporativa pode ser o
Active Directory IPA, provedor de identidade da web.
Facebook.
Google.
Amazonas.
Incógnito ou aberto, dependendo do caso de uso que você deseja alcançar.
Agora vamos examinar rapidamente o fluxo de trabalho de alto nível quando discutirmos sobre a Federação.
Portanto, há três entidades primárias envolvidas.
O primeiro é o usuário.
O segundo é o provedor de serviços e o terceiro é o provedor de identidade.
Nenhum provedor de serviços é basicamente esses aplicativos do lado direito que estávamos discutindo, como Jenkins EAW é
um sistema de gerenciamento de dados, etc.
Além disso, esses são os provedores que estão fornecendo alguns serviços.
Então você tem um provedor de identidade do próprio nome.
Podemos identificar o que exatamente isso faz.
Isso fornece identidade.
Então isso basicamente significa que os usuários são armazenados no nível do provedor de identidade e que o provedor de serviços
e o provedor de identidade existe uma relação de confiança entre ambos.
Portanto, esse provedor de serviços está confiando no provedor de identidade e, portanto, os usuários que
vêm desse provedor de identidade poderão fazer login no provedor de serviços, dependendo das políticas que você
possui.
Tudo bem.
Portanto, se você examinar o diagrama, o usuário será autenticado primeiro com o provedor de identidade.
Ele não autentica com um provedor de serviços.
Então isso basicamente significa que vamos dizer que esse fluxo de trabalho é o de EWR.
Portanto, é um provedor de serviços e existe um provedor de identidade como o Okta.
Assim, os usuários serão armazenados no nível de octanagem.
Os usuários não serão armazenados em um nível de banco de dados.
Portanto, o usuário primeiro se autenticará com o provedor de identidade.
Agora, uma vez que existe uma relação, uma relação de confiança entre o IDP
e o provedor de serviços, o usuário, uma vez autenticado com sucesso no provedor de identidade, poderá
fazer uma solicitação bem-sucedida ao provedor de serviços de EWR.
Então, com isso, vamos em frente e rapidamente entender as coisas com mais detalhes.
Primeiro, o conceito importante aqui é o agente de identidade.
Portanto, o identity broker é um serviço intermediário que conecta vários provedores aqui.
Então, sob identidade, você tem um idlis.
No lado esquerdo, você tem um Active Directory que possui todos os nomes de usuário e senhas
de todos os funcionários da sua organização.
Então o que você quer?
Você quer intimidar o serviço que pode conectar ambos.
Portanto, isso é o que chamamos de agente de identidade.
Então vamos em frente e olhar para o vídeo de trabalho.
No lado direito, você tem o lugar, no lado esquerdo você tem o Active Directory e ainda
no lugar.
Então, primeiro os usuários terão que entrar no agente de identidade.
Portanto, esse agente de identidade está conectado ao Microsoft Active Directory.
Então, basicamente, qual nome de usuário e senha o usuário forneceu ao agente de identidade que corresponde ao
que está armazenado no Active Directory?
Então é aqui que a autenticação realmente acontece.
O primeiro passo é entrar.
A segunda etapa é autenticar o usuário com o Active Directory.
Depois que a autenticação for bem-sucedida, esse agente de identidade irá em frente e chamará o serviço de lança
A e receberá um token específico e, em seguida, o agente de identidade enviará a resposta apropriada de volta ao
cliente.
E esse token é o que declinou novamente usado para se conectar aos serviços da Amazon Web.
Então, quando discutimos sobre este autor, este é o token.
Isso nada mais é do que um conjunto de chaves de acesso e secretas.
Portanto, as chaves secretas e de acesso são fornecidas aos usuários, e os usuários podem usar essas chaves secretas de acesso para
se conectar ao EWG.
Então este é o fluxo de trabalho de alto nível sobre como as coisas funcionariam em um ponto de vista federado, eu acho.
Então vamos em frente e revisar rapidamente as etapas.
O primeiro é o login dos usuários com o nome de usuário e a senha, e essas credenciais são fornecidas
ao agente de identidade.
Agora o Identity Broker valida essas credenciais no Active Directory.
Neste exemplo, pegamos o Active Directory.
Se as credenciais forem válidas.
Basicamente, se o nome de usuário e a senha forem válidos, o corretor entrará em contato com o serviço SDR, pois isso
seguirá em frente e devolverá a segurança de acesso.
E essa chave secreta de acesso será fornecida pelo agente de identidade ao usuário e o usuário poderá fazer login no
console do banco de dados ou com segurança usando esse conjunto de chave secreta de acesso junto com o token
específico, que tem uma duração específica.
Então, se você não consegue se lembrar quando discutimos sobre identidades, identidades, nada além dos usuários.
Então, quando discutimos nossas identidades externas, isso basicamente significa que os usuários estão armazenados em um
sistema externo, não no IEM.
O segundo é o agente de identidade, que é basicamente um middleware que leva o usuário do ponto e o ajuda a
se conectar ao ponto B.
E o terceiro conceito importante é a identidade armazenada, que é basicamente um local onde os usuários estão, mas
como outros usuários são armazenados.
Então Active Directory ou IP ou talvez Facebook.
Então, essas são basicamente a identidade armazenada.
Agora, antes de concluirmos, coisas muito importantes que eu queria compartilhar.
A primeira é que, para a Federação funcionar, esse provedor de serviços também deve oferecer suporte a essa funcionalidade porque, no
final das contas, estávamos discutindo uma.
O provedor de identidade armazenará as identidades e elas serão uma relação de confiança entre a identidade fornecida e também a
do provedor de serviços.
Agora, se o provedor de serviços realmente não oferece suporte a essa funcionalidade, você não pode realmente
ter uma federação.
Portanto, esta é uma parte importante a ser lembrada.
Agora, quando discutimos sobre o Idlis, ao acessar o console do IAM, você tem uma opção específica
do provedor de identidade.
Portanto, é aqui que você pode adicionar vários provedores de identidade.
Portanto, no menu Gordon identity, você terá que especificar basicamente um tipo de provedor, bem como o documento de
metadados do seu provedor de identidade.
Por exemplo, digamos que você escolheu o provedor de identidade do OCTA.
Portanto, a OCTA é uma plataforma de provedor de identidade muito popular.
Este documento de metadados que estávamos discutindo vem do OCTA.
Portanto, depois de definir as configurações de solicitação no OCTA, você pode fazer o upload deste
documento de metadados depois de baixá-lo do OCTA.
E é assim que em uma auditoria de alto nível, a confiança realmente acontece entre um provedor de serviços
e o provedor de identidade.
Então essa é uma parte.
Segunda coisa que também estávamos discutindo, vamos dar um exemplo de Jenkins.
Vamos rapidamente ao Manager Jenkins e configurar a segurança global.
Então, basicamente, o que estamos discutindo nessas contas, sobre como os dados do usuário são armazenados centralmente em um laboratório,
deve ser capaz de fazer login em um aplicativo específico como o Jenkins.
Agora, se Jenkins não lançar ou colocar isso de volta, todo esse conceito não funcionará realmente.
Portanto, o Jenkins também precisará oferecer suporte a um ponto de vista específico do LDAP.
Então, se você for para as configurações do Jenkins em URI, basicamente terá duas opções importantes.
O primeiro é o banco de dados de usuários do próprio Jenkins.
Então isso basicamente significa que sempre que você adiciona um usuário, você o adiciona ao banco de dados Jenkins e também tem a
opção de permitir que o usuário diga, não, este é um.
Agora vamos ver, como estamos discutindo, você realmente não quer criar o usuário individualmente em um sistema
individual.
O que você quer?
Você quer acabar?
Então você também tem uma opção para um painel aqui, e dentro dele você terá que fornecer os detalhes da palavra do
episódio final.
Assim, uma vez que você tenha esse servidor, forneça os detalhes ao do Jenkins e, uma vez que você tenha
a configuração necessária, os usuários que fazem parte de um LDAP poderão fazer login no áudio do Jenkins.
Direita.
Portanto, esta é a visão geral de alto nível.
Caso isso seja algo que realmente lhe interesse, Okta é uma plataforma popular que você pode
experimentar.
Eles também têm várias certificações associadas, que são muito boas.
Então isso é algo que você pode esperar fazer.
Essa é a visão geral de alto nível sobre a Federação.
E com isso concluiremos o vídeo de hoje.