Estou no processo de projetar 3 componentes que funcionarão em sinfonia entre si:
- Um serviço da Web RESTful que requer
BasicAuth
HTTPS em todas as chamadas e é o que realmente faz todo o trabalho pesado para o meu sistema (faz o trabalho) - Uma interface da web que converte ações do usuário final em chamadas de API para o serviço da web mencionado acima; portanto, a interface do usuário é "apoiada por" o WS
- Uma ferramenta da interface da linha de comandos (CLI) que os desenvolvedores podem instalar e executar localmente, que também converte comandos em chamadas de API para o WS (portanto, também é "suportada" pelo WS)
Um dos primeiros obstáculos que estou tentando superar é no que diz respeito à autenticação e autorização.
Vamos fingir que o WS usa um serviço de diretório / LDAP (como o AD ou talvez o Apache DS) como região de autenticação. Ou seja, quando uma chamada de API é recebida por fio (digamos, um HTTPS GET
para algum recurso), as BasicAuth
credenciais são extraídas da solicitação e encaminhadas ao serviço LDAP para determinar se este é um usuário válido ou não. Se eles estiverem autenticados, digamos que um domínio de autorização separado, talvez um banco de dados, seja usado para determinar se o usuário identificado pode ou não fazer o que está tentando na solicitação HTTPS. Por enquanto, tudo bem.
No caso da ferramenta CLI, o usuário terá que se autenticar antes de executar qualquer comando e, portanto, esse modelo funcionará perfeitamente, pois um único usuário estará sempre operando a mesma instância da CLI em um determinado momento.
O problema surge quando tentamos integrar o aplicativo Web (UI) ao WS, porque muitas pessoas podem fazer logon no aplicativo ao mesmo tempo, todas com permissões diferentes, determinando quais chamadas de API subjacentes podem fazer.
Tanto quanto eu vejo, parece que tenho apenas quatro opções aqui:
- Credenciais em cache : depois de fazer login no aplicativo, as credenciais são armazenadas em algum lugar em cache (de modo que o aplicativo tenha acesso a elas), e o aplicativo não impõe nenhum tipo de política de autorização. Quando os usuários tentam fazer coisas que geram chamadas de API ocultas, suas credenciais são consultadas no cache e encaminhadas com as chamadas de API. Se o WS determinar que não está autorizado, ele retornará um erro.
- Contas em nível de serviço : o aplicativo e o WS usam os mesmos domínios de autenticação / autorização, exceto que a interface do usuário da Web agora impõe autorização sobre o que os usuários podem realmente ver e fazer dentro do aplicativo. Se eles têm permissão para fazer algo que gera uma chamada de API subjacente, o aplicativo envia credenciais da conta de serviço (por exemplo
myapp-admin-user
) com cada chamada de API em nome do usuário. - OAuthv2 : Não tenho idéia do que é o OAuth ou se é aplicável a esse cenário, mas sinto que pode ser uma solução aqui de alguma forma.
- Servidores de token : use um servidor de token, como o CAS ou talvez o Kerberos, para garantir aos usuários, da mesma maneira que a opção Conta de nível de serviço se comporta. Aqui, quando um usuário faz login no aplicativo com sucesso, o servidor de token envia o aplicativo de volta a um UUID de sessão e também registra esse UUID no WS. Toda vez que o aplicativo gera uma chamada de API, ele adere o UUID à solicitação, que é validada no lado do WS.
A opção " Credenciais em cache " parece uma aberração de tudo o que é bom e saudável em áreas de segurança. Parece errado armazenar em cache credenciais em qualquer lugar, sempre.
A opção " Token Server " parece válida para uma configuração do tipo SSO, mas não nesse caso específico e me parece estranha. Também acho que não há uma boa maneira de usar o conceito UUID da sessão e BasicAuth
/ HTTPS ao mesmo tempo.
Portanto, isso deixa o OAuthv2, do qual eu não conheço nada, e " SLA (Conta de nível de serviço) * " como as únicas opções restantes. A opção SLA parece boa, mas tem algumas desvantagens a seguir:
- Requer que a conta de serviço tenha basicamente "privilégios de Deus" sobre o WS. Em outras palavras, uma vez que o aplicativo julgue que um usuário pode clicar em um botão ou fazer algo na interface do usuário, isso se traduz em uma chamada incondicional à API pela conta de serviço usada pela interface do usuário. Isso parece ruim, ok?
- Ocorre-me que manter dois conjuntos de permissões (o conjunto de permissões para cada usuário do aplicativo e, em seguida, o conjunto de permissões da conta de serviço usada pelo aplicativo no WS) pode resultar na perda de sincronia entre as permissões. de alguma forma
Parece que eu realmente não tenho boas opções aqui. Certamente não posso ser o primeiro desenvolvedor a se deparar com isso, mas pedir aos deuses do Google não me ajudou muito aqui. Alguma ideia?