Este artigo fornece informações adicionais sobre a utilização de identidades externas com o Identity-Aware Proxy (IAP) em vez de Contas Google.
Vista geral
O IAP controla o acesso às suas aplicações e recursos. Tira partido da identidade do utilizador e do contexto de um pedido para determinar se um utilizador deve ter acesso permitido. O IAP é um elemento essencial do Chrome Enterprise Premium, uma solução de segurança empresarial que permite aos funcionários trabalhar a partir de redes não fidedignas sem usar uma VPN.
Por predefinição, o IAP usa identidades Google e o IAM. Em alternativa, ao tirar partido da Identity Platform, pode autenticar utilizadores com uma vasta gama de fornecedores de identidade externos, como:
- Email/palavra-passe
- OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etc.)
- SAML
- OIDC
- Número de telefone
- Personalizado
- Anónimo
Isto é útil se a sua aplicação já estiver a usar um sistema de autenticação externo e a migração dos seus utilizadores para Contas Google for impraticável.
Multitenancy
A multilocatária da Identity Platform foi originalmente concebida para cenários B2B, em que uma empresa vende um serviço a outras empresas. Nestes casos, é comum os programadores quererem segregar as populações de utilizadores em conjuntos isolados. Estes silos são denominados inquilinos.
Considere o diagrama de relações fictícias abaixo:
Neste exemplo, a Acme é um fabricante de automóveis (o agente) que usa a Identity Platform para fornecer um serviço a concessionários (os inquilinos). Estes concessionários, por sua vez, prestam serviços aos respetivos clientes, funcionários e contratados. Embora o fabricante seja proprietário do serviço, cada concessionário pode usar o seu próprio conjunto de fornecedores de identidade para autenticação. As sessões dos utilizadores e os dados são definidos ao nível do inquilino. Por isso, se um utilizador tiver relações com várias concessionários, cada um é processado de forma independente.
Consoante o seu exemplo de utilização, existem várias formas de estruturar a hierarquia de inquilinos.
Nenhum inquilino
Só precisa de multi-tenancy se precisar de isolar recursos. Nem todas as aplicações têm este requisito. Por exemplo, se tiver uma única app do App Engine e quiser bloquear o acesso a todos os utilizadores fora da sua rede, não precisa de multi-tenancy. Por predefinição, o Identity Platform armazena e autentica utilizadores por projeto, pelo que não é necessária configuração adicional neste caso.
Outro exemplo é um conglomerado com várias subsidiárias. Mesmo que cada subsidiária tenha o seu próprio sistema de autenticação gerido (através do OIDC ou SAML), todos os funcionários podem partilhar as mesmas vantagens de alto nível, como cuidados de saúde, férias e folha de pagamentos. Neste caso, a autenticação ao nível do projeto é suficiente.
Um inquilino por recurso
Por predefinição, os tokens do Identity Platform que não são de inquilinos são válidos ao nível do projeto. Teoricamente, isto significa que um utilizador pode autenticar-se com um recurso do IAP e, em seguida, usar o token para aceder a outro serviço no mesmo projeto. Isto representa um risco de segurança.
Para evitar a fuga de tokens, isole cada CAPP atribuindo a cada um o seu próprio inquilino. Os tokens cunhados num contexto específico do inquilino só são válidos para esse inquilino específico. Se o utilizador tentar aceder a outro recurso de IAP que use um inquilino diferente, é-lhe pedido que se autentique novamente.
Vários inquilinos por recurso
Um único recurso de IAP pode ter vários inquilinos associados.
Quando um utilizador acede ao recurso, tem várias opções para determinar que inquilino usar. Por exemplo, pode pedir ao utilizador que introduza primeiro o respetivo email e, em seguida, localizar programaticamente um inquilino que corresponda ao domínio do email. Em alternativa, pode apresentar uma IU que liste todos os inquilinos válidos e pedir ao utilizador que escolha um.
Os utilizadores podem pertencer a vários inquilinos com diferentes níveis de acesso. Embora não possa usar o IAM para gerir o controlo de acesso com identidades externas, o token Web JSON gerado pelo IAP contém as reivindicações do token de ID da Identity Platform, e a aplicação pode filtrar o acesso com base nestas reivindicações.
Um exemplo de um cenário de multi-tenancy é uma empresa de benefícios para funcionários que tem muitos clientes a partilhar um único portal Web. Quando um utilizador visita o portal, seleciona primeiro a respetiva empresa (o inquilino) e, em seguida, autentica-se com o fornecedor que o empregador usa com as respetivas credenciais empresariais.