OAuth2 based SSO

Question

OAuth2 based SSO

o nosso projecto consiste em várias sub-aplicações, e estamos à procura de uma solução para implementar SSO para evitar a autenticação para cada sub-aplicação.

Suponha que esta seja a estrutura do nosso projecto.

authentication server(call it AS or IdP or something else)
order-system
product-system
data-analysis-system
.......

e descobrimos que existem muitos artigos do SSO implementados com base no OAuth2 como Este .

Neste artigo, preferimos a estratégia {[[2]} porque é simples e clara, no entanto existem algumas limitações para aplicação nativa, em seguida, focámo-nos no OAuth2.

Este é o fluxo de trabalho.

1 Regras na OAuth2

Resource Server (SP) – este é o servidor web a que está a tentar aceder informações sobre.
Cliente
- é assim que o utilizador interage com o servidor de recursos. Isto pode ser um aplicativo web baseado em navegador, um aplicativo móvel nativo, um desktop app, uma aplicação do lado do servidor.

servidor de autorização (Idp) – este é o servidor que dono do utilizador identidades e credenciais. É quem o utilizador autentica. e autoriza.

Tomar OctoDroid como exemplo, as regras são muito claras:

Client: OctoDroid
Idp: GitHub
SP: Github
User: one who use OctoDroid application.

o fluxo de trabalho é que o OctoDroid(Client) lhe pede(User) para se autenticar e conceder permissões através do Github(Idp) para obter os recursos(repos,issues) do Github(SP).

Mas na nossa aplicação, o que é que cada sub-sistema pode tratar? a SP ou a Client?

se tratado como SP, o navegador web é o Client? Sempre achei que um Client devia ser uma candidatura. Além disso, o sub-sistema valida o access_token através do Idp para cada pedido e, em seguida, retornar o recurso relacionado, isso vai aumentar a pressão para o Idp?

se tratado como um Client, Quem é o SP?

2 Regras de Aplicação

para um mesmo Utilizador, ele pode ter regras diferentes em diferentes subsistemas, por exemplo, ele pode ler / escrever todas as ordens de order-system, mas ele não pode aceder o product-system. Então onde deve acontecer a configuração das regras? No Idp ou em cada sub-sistema?

Sincronização De 3 Sessões

para um sistema SSO típico, quando o utilizador se autentica (através do Idp), todo o sub-sistema deverá autenticar-se , quando o utilizador se autentica, todo o sub-sistema deverá sair.

No entanto, no fluxo de trabalho de OAuth2 acima, parece que diferentes SP s ou Clients são independentes. Quando sair de OctoDroid, Poderá à mesma usar O OpenHub Assim que tiver a autenticação. Neste caso, parece como o OAuth2 é diferente do SSO, como eles podem trabalhar juntos?

4 Idp ligar a outro Idp

na nossa aplicação, para além do Utilizador básico e do login da senha,o servidor de autenticação deve fornecer o login também do google, do facebook e de outros fornecedores CAS. Isto é possível?

BTW, Não tenho a certeza se fui suficientemente claro, se não, pergunte-me nos comentários.

4

oauth-2.0 single-sign-on openid-connect

Author: Kavindu Dodanduwa, 2020-07-25

Source

3 answers

score 2 · Answer 1

Pensei em juntar-me à discussão com alguns comentários do mundo real sobre o tipo de padrões que tendem a funcionar melhor. Muito do jargão de OAuth não é útil e confunde as pessoas. Mas o Mark Kavindu é a resposta aceite ...

Q1. Subsistemas

As empresas produtoras de Software muitas vezes querem construir uma plataforma de UIs e APIs. Na maioria das vezes, em sua terminologia, os UIs são os clientes (eles recebem tokens) e os APIs são os subsistemas (eles recebem tokens). Existem algumas exceções, tais como clientes back end, mas estes tendem a ser secundários. [[1]}o SAML é uma tecnologia antiga que foi usada pelos aplicativos web do lado do servidor, e ainda é usado para logins Federados. Hoje em dia, a maioria das empresas quer construir aplicativos móveis e aplicativos baseados em Javascript, para o qual OAuth 2.o X e o Open Id Connect são mais adequados - com muitas bibliotecas-como diz O Kavindu.

Q2. Regras

Uma opção aqui é gerir as regras no servidor de autorização. Por exemplo, você pode use o OAuth custom scopes como privilégios de alto nível, que então são adicionados aos tokens de acesso e lidos por APIs:

O âmbito da ordem significa que pode efectuar operações relacionadas com a ordem
Produto + escopos de Escrita significa que você pode atualizar o sistema de produtos

Isto pode ser bom para aplicações simples. Para aplicativos mais complexos, ele não tem uma escala bem, e há um risco de que os scopes / reivindicações para a API ordem começar a impactar negativamente a API de produtos. As regras mais complexas as suas APIs, onde são mais fáceis de gerir ao longo do tempo. Isto normalmente envolve a pesquisa do usuário a partir do token de acesso nos próprios dados do subsistema. A minha preferência pessoal é usar uma arquitectura baseada em reivindicações para trabalhar melhor na aplicação das regras. Se estiver interessado nesta abordagem, veja meus posts no blog abaixo:

Q3. SINCRONIZAÇÃO DA SESSÃO

Às vezes isto é uma área onde os sistemas baseados em OAuth não se comportam da maneira que os stakeholders esperam, e as pessoas só precisam ser educadas sobre as limitações da tecnologia. Os usuários finais não se importarão se o único log out funciona e você não vai falhar revisões de segurança.

Como exemplo, num dispositivo móvel, a saída de uma interface de navegador não o fará sair de uma interface móvel. A interface móvel continuará a usar um token de acesso de curta duração, mas o Usuário será solicitado a se autenticar novamente quando o token de acesso expirar. - talvez 30 minutos depois.

Q4. Federação

A maioria dos servidores de autorização podem ser Federados a múltiplos fornecedores de identidade para suportar vários tipos de login. No mundo corporativo isso muitas vezes usa SAML 2.0 como um protocolo. Quais provedores que você permite muitas vezes depende do tipo de ativos que seus subsistemas lidam com:

para os activos corporativos, não permitiria que um utilizador assinasse com a sua conta no Facebook
para bens pessoais, isto pode ser está bem.

Muitas vezes é um bom objetivo técnico lidar com múltiplos provedores de identidade dentro do servidor de autorização. Seus UIs e APIs então só precisam interagir com o servidor de Autorização e seus tokens, o que reduz a complexidade.

score 2 · Answer 2

Tens muitas perguntas. Perguntas Parte 1

se tratado como um SP, o navegador web é o cliente?
se tratado como um cliente, quem é o SP?

Acho que estas perguntas estão relacionadas com: OAuth 2.0 quatro papéis

Papéis Do Oauth2

Vamos começar com este diagrama de fluxo clássico:

Pode usar estas regras para determinar qual o papel das suas aplicações:

Cliente
- Moderns web (reat, angular, vue, linkstart, etc) e aplicativos móveis(android/ios). Em geral, qualquer software que precise de Dadosde outro software pode ser um cliente . Normalmente, o cliente é uma web e os dados solicitados é uma API http descanso, mas o conceito pode aplicar-se ao legado (aplicativos de renderização de servidor) ou aplicações futuras (robôs em um mall)
Servidor De Recursos
- Http Rest Api. Mantém as coisas simples!! estamos a falar de uma api desenvolvida em alguma linguagem de infra-estrutura (java, python, nodejs, etc) consumível do carteiro, Soapui, curl, javascript, etc
Servidor De Autorização
- aplicação que é responsável por gerações simbólicas e mais recursos relacionados com asegurança das suas aplicações

Perguntas Parte 2

Então onde deve acontecer a configuração das regras? No Idp ou em cada sub-sistema?
para além do Utilizador básico e da autenticação por senha, o servidor de autenticação deve fornecer o login do google, facebook e outros Fornecedores de CAS também. Isto é possível?

Plataformas de autenticação e autorização

Neste momento você conhece os tokens jwt, utilizador / Senha, tabela de utilizadores, etc

Mas tens de garantir que um utilizador com "convidado" o role não pode executar uma invocação de remoção para um endpoint de resto da api /user/100. Então você precisa de regras

A solução clássica para implementar este regras é ter algumas tabelas na sua base de dados como: utilizador, funções, roles, role_permission, permission_option. A tabela de opções deve ter registrado todos os seus endpoints api e seu método. Também isso poderia ser usado para criar a relação entre as rotas web do Usuário<:>. Verifique isto

Podes desenvolver a tua própria segurança. plataforma tendo em consideração as regras anteriores ou utilizar algumas plataformas chamadas plataforma/fornecedores oauth2, plataformas de identidade/acesso, etc:

auth0
keycloack, etc

Mais detalhes aqui: https://stackoverflow.com/a/62049409/3957754

Perguntas Parte 3

Parece que o OAuth2 é diferente do SSO, como podem trabalhar juntos?

Como resumo, SSO apenas garante que todo o seu utilizador pode aceder a aplicativos e webs com o mesmo usuário/senha.

O Oauth2 está estritamente relacionado com autorização , mas a autorização não é possível com autenticação, e a autenticação está relacionada com o utilizador/senha, por isso esta é a relação entre oauth2 e sso

Algumas ligações

score 1 · Answer 3

Se você está construindo algo novo, então vá em frente com OAuth 2.0. Em comparação com o SAML, ele é amigável (IE - JSON baseado) e também moderno. Além disso, existem muitos recursos para ajudá-lo (IE-bibliotecas e adaptações IDP). Mais uma coisa, dado que quer autenticação, deverá usar o OpenID Connect (spec). Pense nisso como uma simples extensão construída em OAuth 2.0.

1 mas em nossa aplicação, o que exatamente cada sub-sistema pode tratar? um SP ou um cliente ?

OAuth 2. 0 define alguns tipos de aplicação diferentes (Leia). Indo com a sua explicação, há poucos deles em seu sistema - aplicações web e aplicativos nativos (pode ser móvel). Se for esse o caso,

IDP-o seu servidor de identidade
User agent-Browser usado para activar o fluxo de OAuth

E o servidor de recursos (SP) pode ser o fim de cada uma destas aplicações. Ou pode ser um serviço de apoio comum. Mas, em qualquer caso, deve ser protegido por fichas de OAuth obtidas por cada cliente.

O token introspection (spec - } rfc7662) define como pode validar os tokens do servidor de recursos. Sobre a carga em IDP, bem, tudo depende de sua escala da implantação.

2 Regras de Aplicação

Então, agora, vamos ao OpenID Connect. Define o token ID, que comunica o seu cliente sobre o estado autenticado do utilizador final. E vem em forma de JWT. E a coisa boa sobre JWT é (além de ser JSON), ele pode ter reivindicações personalizadas. O spec suporta isso ( alegações Adicionais ). Assim, no seu IDP, terá de configurar os papéis/grupos de utilizadores/permissão e comunicar isto em ID Token aos clientes.

3 Sincronização Da Sessão

IDPs usam sessões de navegação para fornecer o comportamento SSO dos seus clientes. Quando você faz login em um cliente, seu IDP cria uma sessão. Assim, quando o Usuário Final usar outro cliente, o IDP pode verificar o estado já registrado, pedir permissão em falta e completar os tokens necessários para emissão de fluxo de login.

O OpenID Connect vem com o programa de gestão de sessões (source), que fornece ao seu cliente um mecanismo para verificar as alterações nesta sessão. Verifique com a sua escolha de IDP no suporte para isso.

4 Idp ligar-se a outro Idp

Isto é algo fora do âmbito do ecossistema OAuth2.0. SAML tem a Federação SAML que faz isso (nota - eu não sou um especialista SAML). E os diferentes fornecedores de identidade têm as suas próprias soluções (ex: - WSO2 trazem a sua própria identidade ). Tal provisionamento de Usuários depende de seus requisitos, bem como capacidades de IDP. Mas, como eu disse, está fora de âmbito para OAuth. Nota: cerca de 4ª pergunta, se o seu IDP suporta e se estiver de acordo, pode aceitar fichas emitidas por terceiros (ie - Google, Facebook) para autenticar os utilizadores no apps. Isto pode seja feito no topo do OpenID Connect. Além disso, existe o SCIM (resources) que permite consultar os dados do utilizador através de diferentes fornecedores de identidade.