Neste artigo, você verá mais informações sobre como usar identidades externas com o Identity-Aware Proxy (IAP) em vez de contas do Google.
Informações gerais
O IAP controla o acesso aos aplicativos do App Engine e às VMs do Compute Engine em execução no Google Cloud. Ele usa a identidade do usuário e o contexto de uma solicitação para determinar se o usuário terá permissão de acesso. O IAP é um BeyondCorp, um modelo de segurança empresarial que permite que os funcionários trabalhem em redes não confiáveis sem usar uma VPN.
Por padrão, o IAP usa as identidades do Google e o IAM. Se, em vez disso, você usar o Identity Platform, será possível autenticar usuários com uma grande variedade de provedores de identidade externos, como os seguintes:
- E-mail/senha
- OAuth (Google, Facebook, Twitter, GitHub, Microsoft etc.)
- SAML
- OIDC
- Número de telefone
- Personalizado
- Anônimo
Isso será útil se seu aplicativo já estiver usando um sistema de autenticação externo e não for possível migrar seus usuários para as contas do Google.
Multilocação
A multilocação do Identity Platform foi criada originalmente para cenários B2B, em que uma empresa vende um serviço para outras empresas. Nesses casos, é comum que os desenvolvedores queiram separar populações de usuários em pools isolados. Esses silos são chamados de chamados de locatários.
Veja o diagrama de relacionamento fictício abaixo:
Nesse exemplo, a Acme é um fabricante de automóveis ( o agente) que usa o Identity Platform para fornecer um serviço às concessionárias (os locatários). Essas concessionárias, por sua vez, prestam serviços a clientes, funcionários e prestadores de serviços. Embora o fabricante seja proprietário do serviço, cada concessionária pode usar o próprio conjunto de provedores de identidade para autenticação. O escopo das sessões de usuário e dos dados é definido para cada locatário. Portanto, se um usuário tiver relações com vários revendedores, cada um deles será tratado de maneira independente.
Dependendo do seu caso de uso, existem várias maneiras de estruturar a hierarquia do locatário.
Nenhum locatário
A multilocação só será necessária se você precisar isolar recursos. Nem todos os aplicativos têm esse requisito. Por exemplo, se você tiver um único aplicativo do App Engine e quiser bloquear o acesso a todos os usuários fora da sua rede, a multilocação não será necessária. Por padrão, o Identity Platform armazena e autentica usuários por projeto. Portanto, nenhuma configuração extra é necessária nesse caso.
Outro exemplo é um conglomerado com várias subsidiárias. Mesmo que cada subsidiária tenha seu próprio sistema de autenticação gerenciada (usando OIDC ou SAML), todos os funcionários podem compartilhar os mesmos benefícios de alto nível, como plano de saúde, férias e folha de pagamento. Nesse caso, a autenticação para envolvidos no projeto é suficiente.
Um locatário por recurso
Por padrão, os tokens sem locatário do Identity Platform são válidos para envolvidos no projeto. Teoricamente, isso significa que um usuário pode se autenticar com um recurso do IAP e usar o token para acessar outro serviço no mesmo projeto. Isso é um risco para a segurança.
Para evitar o vazamento de token, isole os IAPs atribuindo um locatário a cada um. Os tokens emitidos em um contexto específico de locatário são válidos apenas para esse locatário em particular. Se o usuário tentar acessar outro recurso do IAP que usa um locatário diferente, será solicitado que ele se autentique novamente.
Vários locatários por recurso
Um único recurso do IAP pode ter vários locatários associados a ele.
Quando um usuário acessa o recurso, você tem várias opções para determinar qual locatário usar. Por exemplo, é possível solicitar que o usuário insira o e-mail dele e localizar programaticamente um locatário que corresponda ao domínio do e-mail. Como alternativa, também é possível exibir uma IU que lista todos os locatários válidos e solicitar que o usuário escolha um.
Os usuários podem pertencer a vários locatários com diferentes níveis de acesso. Embora não seja possível usar o IAM para gerenciar o controle de acesso com identidades externas, o JSON Web Token gerado pelo IAP carrega as declarações do token de ID do Identity Platform, e o aplicativo pode filtrar o acesso com base nessas declarações.
Um exemplo de cenário de multilocação é uma empresa de benefícios para funcionários em que muitos clientes compartilham um único portal da Web. Quando um usuário visita o portal, ele primeiro seleciona a empresa dele (o locatário) e, em seguida, faz a autenticação com o provedor usado pelo empregador e suas credenciais corporativas.