Domesticar protocolos de confiança - autenticação OAuth com o InterSystems IRIS

Como permitir que os computadores confiem um no outro na sua ausência, mantendo a segurança e a privacidade?



- Martini seco. Em um copo grande.
- Oui, monsieur. [Sim, Monsieur (Fr.)]
"Só um segundo, não todos." Três dedos de Gordon, um de vodka, meio dedo de Kina Lyklet. Bata bem em uma coqueteleira e coloque uma fatia grande de limão. Você se lembra?

Jan Fleming, Cassino Royale, 1953

Parte 1. Histórias OAuth 2.0 e OpenID Connect

Universal e, ao que parece, hoje no século 21, o pacote favorito de todos dos protocolos de delegação e autenticação de acesso aberto é chamado OAuth + OIDC. Melhor para uso em massa, eles ainda não inventaram nada. Eles são especialmente populares entre os fornecedores de front-end, porque seguem os protocolos HTTP (S) e usam o contêiner JWT ( JSON Web Token ). O OpenID Connect usa o OAuth para seu trabalho ou, em outras palavras, o OIDC é um wrapper para o OAuth.

OpenID - um padrão aberto para autenticação e criação de sistemas de identificação digital não é novidade para os desenvolvedores. Este ano, ele completa 14 anos. Na terceira versão atual, o nome completo é OpenID Connect ou menor que OIDC. É popular no desenvolvimento web e móvel e em sistemas corporativos.

Seu parceiro, o Padrão de delegação de acesso aberto OAuth, está completando 12 anos. E 9 anos desde o surgimento do padrão RFC 5849. Contaremos com a versão moderna do protocolo OAuth 2.0 e o atual RFC 6749 . Lembre-se de que o OAuth 2.0 não é compatível com o seu antecessor OAuth 1.0.

OAuth - um protocolo aberto (esquema, transporte) para delegar acesso, que permite fornecer a terceiros acesso limitado aos recursos protegidos do usuário sem a necessidade de transferir para eles (terceiros) o login e a senha do RFC 6749

oauth.net é o principal site do OAuth hospedado por Aaron Parecki

oauth.com - Tutorial do OAuth e ambiente de teste

O Open ID Connect (OIDC) é um padrão aberto para sistemas de identificação descentralizados que permite ao usuário criar uma conta única para identificação em uma variedade de recursos da Internet não relacionados usando serviços de terceiros, usa mensagens OAuth e um contêiner JWT para comunicação segura.

Estritamente falando, o OAuth não é um protocolo, mas um conjunto de regras (esquema) para separar e transferir operações de identificação do usuário para um servidor confiável separado ao implementar a arquitetura de delimitação do controle de acesso em sistemas de software.

E atenção, o OAuth não pode dizer nada sobre um usuário específico ! Nem quem ele é, nem onde ele está agora, nem mesmo se ele trabalha no computador agora ou não. Porém, torna possível interagir com sistemas sem intervenção do usuário, usando tokens de acesso já emitidos. Este é um ponto importante.

Pode ser útil:

• OAuth combina perfeitamente com o uso da linguagem de descrição de acesso a atributos XACML
• OAuth também conta com o acesso gerenciado pelo usuário ( UMA )

O uso conjunto do OAuth + OIDC + UMA permite implementar sistemas de identificação segura e controle de acesso (Gerenciamento de Identidade e Acesso - IdM, IAM) em diferentes áreas, por exemplo:

• usando o perfil HEART (Health Relationship Trust) dos dados pessoais de um paciente na medicina
• nas plataformas de identificação de clientes CIAM (Consumer Identity and Access Management) para empresas de manufatura e comércio
• personalização de certificados digitais de dispositivos inteligentes em sistemas IoT (Internet of Things)

Um novo Venn de controle de acesso para a economia da API

Mais importante ainda, não armazene dados pessoais no mesmo local que o resto do sistema. Separe fisicamente autenticação e autorização. E melhor ainda - forneça toda a identificação pessoalmente à pessoa e nunca a mantenha com você. Confie no proprietário do dispositivo.

A Apple disse que dados pessoais os russos armazenam na Rússia. Este é o nome, endereço, email, número de telefone. Mas mensagens, fotos, etc., as próprias pessoas confiam na nuvem do iCloud (que não está na Rússia).

Parte 2. Reprodução curta “Confiança e autenticação”

Portanto, decidimos que não era comum armazenar os dados pessoais de nossos queridos usuários nem em nosso aplicativo, nem em um único armazenamento, juntamente com um banco de dados em funcionamento. Ou seja, eles escolheram um administrador confiável que fornecerá esse serviço para nós. E assim, quando Sua Majestade o Usuário aparecer, forneceremos o seguinte diálogo.

Atores:

• Usuário
• Aplicativo Cliente
• Serviço de identidade
• Servidor de Recursos

A ação ocorre em um navegador no computador do usuário. Todos os personagens estão familiarizados há muito tempo. O usuário tem uma conta pessoal no serviço de identidade. O Aplicativo Cliente possui um contrato válido assinado com o Serviço de Identificação e interfaces mútuas. O Servidor de Recursos confia no Serviço de Identidade na emissão de chaves de acesso a qualquer paciente que ele possa identificar.

Usuário (P): (iniciando um aplicativo cliente baseado na Web) Caro aplicativo cliente, preciso desse "recurso".
Aplicativo cliente (K): Caro usuário, primeiro apresente a chave para "este recurso". Sem uma chave, o acesso a "este recurso" está fechado.
P: Eu não tenho essa chave.
K: Então, mudarei temporariamente você para um serviço de identificação com o qual temos um acordo para emitir chaves para o servidor de recursos. (redireciona P. ao serviço de identificação)
Serviço de Identificação (I): Caro usuário, diga-me quem você é e quais chaves você precisa?
P: Eu, usuário usuário do Ytsuken, a senha é tal e qual, quero obter acesso a "este recurso".
E: Obrigado, camarada Jtsuken. A autenticação foi bem-sucedida e sua identificação foi verificada. Aqui está a chave para "este recurso" (P. redireciona de volta para K.)
P: Cliente, eu trouxe a chave do "recurso" de que preciso.
K: Obrigado usuário. A chave está correta. Aqui está o "recurso" que você solicitou.

A cortina. A sinfonia de abertura de Richard Strauss do filme "Space Odyssey of 2001" toca

Parte 3. Serviço de autorização real

Agora vamos ao que interessa. Temos três tarefas na agenda: nomear os personagens, preparar o palco e tocar a peça. E tudo é decidido de uma vez na plataforma IRIS da InterSystems. Mas isso não é necessário, você pode montar um design a partir de diferentes plataformas, a seu critério. Por exemplo, nesta combinação: servidor OAuth Keycloak + cliente OAuth e recurso OAuth no IRIS. Em outras palavras:

1. Configure e inicie o servidor OAuth com o registro do nosso cliente de demonstração.
2. Configure um cliente OAuth de demonstração conectando-o ao servidor OAuth e aos recursos da Web.
3. Desenvolva aplicativos clientes que podem usar o OAuth. Você pode usar Java, Python, C #, NodeJS. A seguir, é apresentado um código de aplicativo de amostra no ObjectScript.

O site da comunidade de desenvolvedores tem instruções detalhadas de Daniel Kutak em três partes, com exemplos de uso do OAuth no IRIS para diferentes aplicativos baseados no CSP ( parte 1 , parte 2 , parte 3 ).

Existem muitas configurações no OAuth. Portanto, escreva listas de verificação - esta é a aplicação mais correta para elas. Exemplos e espaços em branco abaixo.

Onde obter o InterSystems IRIS pronto para uma amostra? Há pelo menos duas opções disponíveis para todos:

Obtenha um servidor IRIS na nuvem pré-configurado e pronto na plataforma de treinamento do InterSystems Learning Services na seção InterSystems Learning Labs.

Instale um contêiner de encaixe pronto para uso . Leia mais no artigo - uma instrução passo a passo para iniciantes em desenvolvedores do Iniciando IRIS Using Docker ou, se preferir um vídeo, uma instrução de screencast de Developing Solutions with InterSystems IRIS Using Docker and VSCode

1-1 Configurando o servidor OAuth

Entramos no portal de gerenciamento IRIS e selecionamos a seção:

Administração do sistema >> Segurança >> OAuth 2.0 >> Servidor

Em seguida, em cada parágrafo, haverá um nome para a linha de configurações e, através dos dois pontos, um exemplo ou explicação, se necessário.



Guia Configurações Gerais:
Descrição: opcional, por exemplo, "Servidor de autorização"
O terminal do gerador (doravante CTG) é o nome do host: nome DNS do seu servidor
Tipos de permissão suportados (selecione pelo menos um):
Código de autorização
Implícito
Credenciais: recurso, proprietário, senha
Credenciais do cliente
Configuração SSL / TLS: oauthserver

Guia Permissões:
adicionar volumes suportados: por exemplo, scope1 e scope2

Guia Intervalos:
Intervalo da chave de acesso: 3600
Intervalo do código de autorização: 60
Intervalo de atualização: 86400
Intervalo de interrupção de sessão: 86400
Período de validade da chave do cliente: 0

Guia Configurações do JWT:
Algoritmo de entrada: RS512
Algoritmo de gerenciamento de chaves: RSA-OAEP
Algoritmo de criptografia de conteúdo: A256CBC-HS512

Guia Customizing:
Identifique a classe:% OAuth2.Server.Authenticate
Verifique a classe do usuário:% OAuth2.Server.Validate
Classe de serviço de sessão: OAuth2.Server.Session
Gerar classe de chave:% OAuth2.Server.JWT
Namespace de personalização:% SYS
Funções de personalização (selecione pelo menos uma):% DB_IRISSYS e% Manager

Salve.

1-2 Registrar o cliente no servidor OAuth

Botão Descrição do cliente >> botão Criar descrição do cliente:

Guia Configurações Gerais:
Nome: CLIENT
Descrição: arbitrário
Tipo de Cliente: Confidencial
URLs de redirecionamento: o endereço do ponto de retorno em nosso aplicativo após a autenticação
Tipos de permissão suportados
Código de autorização: sim
Implícito
Credenciais: recurso, proprietário, senha
Credenciais do cliente
Autorização JWT
Tipos de resposta suportados
código
id_token
chave id_token
token
Tipo de autorização: Simples

Guia Credenciais do cliente: preenchida automaticamente

Guia Informações do cliente:
URL de lançamento:
Tela de login
Nome do cliente
URL do logotipo
URL da página inicial do cliente
URL da política
Termos de URL de serviço

2-1 Configurando a ligação no cliente do servidor OAuth

Administração do sistema >> Segurança >> OAuth 2.0 >> Cliente



Crie uma descrição do servidor:
Ponto de extremidade do gerador: obtenha dos parâmetros gerais do servidor, veja acima
Configuração SSL / TLS: selecione na lista de configurações pré-configuradas

O conteúdo dos campos restantes será baixado automaticamente do servidor, mas você também pode configurá-los manualmente:

Servidor de autorização
Terminal de Autorização: CTG + / authorize
Ponto final principal: CTG + / token
Terminal de informações do usuário: CTG + / userinfo
Ponto final principal de autodiagnóstico: CTG + / revogação
Ponto final de revogação de chaves: CTG + / introspecção
Configurações de token da Web JSON (JWT)
Outra fonte além do registro dinâmico: selecione JWKS na URL
URL: CTG + / jwks



Nessa lista, por exemplo, pode ser visto (scopes_supported e claim_supported) que o servidor pode fornecer informações diferentes sobre o usuário ao cliente OAuth. E vale a pena prestar atenção que, ao implementar seu aplicativo, você precisará perguntar ao usuário quais dados ele está pronto para compartilhar. Além disso, em nosso exemplo, apenas seremos solicitados com permissão pelo escopo1.

Salve.

Se houver um erro indicando SSL, vá para as configurações:
Administração do sistema >> Segurança >> Configuração de SSL / TSL

2-2 Configurando o cliente OAuth

Administração do sistema >> Segurança >> OAuth 2.0 >> Cliente >> Configuração do cliente >> Criar configuração do cliente



Guia Geral:
Nome do aplicativo: cliente de demonstração
Nome do cliente: demo client
Descrição: opcional
Ativado: Sim
Tipo de Cliente: Confidencial
Configuração SSL / TCL: oauthclient
URL de redirecionamento do cliente: nome DNS do seu servidor
Tipos de permissão necessários
Código de autorização: sim
Implícito
Credenciais: recurso, proprietário, senha
Credenciais do cliente
Autorização JWT
Tipo de autorização: Simples

Guia Informações do cliente:
Tela de login
URL do logotipo
URL da página inicial do cliente
URL da política
Termos de URL de serviço
Volume padrão: usamos os especificados anteriormente no servidor, por exemplo, scope1
Endereços de email de contato (separados por vírgula)
Idade padrão máxima (em segundos)

Guia Configurações do JWT:
Configurações de token da Web JSON (JWT)
Criando configurações de JWT a partir de credenciais X509
Algoritmos do IDToken
Assinatura: RS256
Criptografia: A256CBC
Chave: RSA-OAEP
Algoritmos de informações do usuário
Algoritmos de token de acesso
Algoritmos de consulta

Guia Credenciais do cliente:
Id cliente: daquele emitido no registro do cliente no servidor (veja acima)
ID do cliente emitida
Segredo do cliente: daquele emitido ao registrar o cliente no servidor (veja acima)
O segredo do cliente expira
URI de registro do cliente

Salve.

Parte 4. Código

Vamos criar um aplicativo da web minimalista com autorização OAuth e REST.

Ao trabalhar, o OAuth conta com o fato de que os canais de comunicação entre os participantes da interação (servidor, clientes, aplicativo da web, navegador do usuário, servidor de recursos) são protegidos de alguma forma. Na maioria das vezes, esse papel é desempenhado pelo SSL / TLS. Mas o OAuth também funcionará em canais inseguros. Por exemplo, o servidor Keycloak, por padrão, usa o protocolo HTTP e fica sem proteção. Isso simplifica o desenvolvimento e a depuração durante o desenvolvimento. Com o uso real dos serviços OAuth, a proteção de canal deve ser estritamente ativada - isso é registrado na documentação do Keycloak. Os desenvolvedores do InterSystems IRIS adotam uma abordagem mais rigorosa para o OAuth - é necessário SSL / TSL. A única simplificação é que você pode usar certificados autoassinados ou usar o serviço PKI embutido no IRIS (Sistema de Administração >> Segurança >> Sistema de Chave Pública).

A autorização do usuário é verificada com a indicação explícita de dois parâmetros - o nome do seu aplicativo e o volume suportado pelo servidor OAuth e no cliente OAuth (escopo - gostaria de saber como nomeá-lo corretamente em russo?):

Parameter OAUTH2APPNAME = "OAuthClient"; set isAuthorized = ##class(%SYS.OAuth2.AccessToken).IsAuthorized( ..#OAUTH2APPNAME, .sessionId, "scope1", .accessToken, .idtoken, .responseProperties, .error) 

Na falta de autorização, estamos preparando um link para uma solicitação de identificação do usuário e obtendo permissão dele para trabalhar com nosso aplicativo. Aqui, precisamos indicar não apenas o nome do aplicativo e o volume (escopo) solicitado registrados no servidor OAuth e no cliente OAuth, mas também um link para o ponto em que o aplicativo Web deve retornar o usuário.

 Parameter OAUTH2CLIENTREDIRECTURI = "https://52773b-76230063.labs.learning.intersystems.com/oauthclient/" set url = ##class(%SYS.OAuth2.Authorization).GetAuthorizationCodeEndpoint( ..#OAUTH2APPNAME, "scope1", ..#OAUTH2CLIENTREDIRECTURI, .properties, .isAuthorized, .sc) 

Usamos o serviço de autenticação IRIS embutido e, portanto, registramos usuários no servidor OAuth IRIS. Por exemplo, basta definir o usuário apenas com um nome de usuário e senha, não será necessário fazer outras configurações na conta.

Ao transferir o usuário usando o link recebido, o servidor executará o procedimento de identificação do usuário e solicitará permissão para operar com credenciais no aplicativo Web, além de salvar o resultado em seu OAuth2.Server.Session global na área% SYS:





3. Demonstre os dados de um usuário autorizado. Após a conclusão bem-sucedida dos procedimentos, temos, por exemplo, um token de acesso. Vamos entender:

 set valid = ##class(%SYS.OAuth2.Validation).ValidateJWT( .#OAUTH2APPNAME, accessToken, "scope1", .aud, .JWTJsonObject, .securityParameters, .sc ) 

Se necessário, ative as mensagens de depuração estendidas no servidor OAuth e no cliente OAuth. As mensagens são gravadas no ISCLOG global na área% SYS. Digite seu terminal IRIS (ou instale e use um terminal da Web ):

 set ^%ISCLOG = 5 set ^%ISCLOG("Category", "OAuth2") = 5 set ^%ISCLOG("Category", "OAuth2Server") = 5 

Consulte a documentação do IRIS Using OAuth 2.0 e OpenID Connect para obter mais informações .

Conclusões:

1. O OAuth ajuda a separar física e geograficamente os serviços com credenciais de usuário e bancos de dados "funcionais". E, assim, fortalecer a proteção dos dados de identificação e, se necessário, cumprir os requisitos das leis de proteção de dados pessoais de diferentes países.
2. Usando o OAuth, você pode fornecer ao usuário a capacidade de trabalhar com segurança simultaneamente a partir de vários dispositivos e "transmitir" seus dados pessoais minimamente a vários serviços e aplicativos. Além de não receber informações "redundantes" sobre os usuários em seus serviços, ou seja, para conduzir o processamento de dados despersonalizados em seus serviços.
3. Ao usar o InterSystems IRIS, você tem um conjunto completo de ferramentas prontas para testar e implantar serviços OAuth e OIDC, de maneira independente e em cooperação com produtos de software de terceiros.

Quais setores costumam usar a plataforma IRIS da InterSystems?
Para automação de assistência médica, no setor financeiro, para projetos de governo eletrônico, em logística, varejo e muitas outras indústrias.

Se você estiver interessado nas tarefas de automação de assistência médica, preste atenção ao padrão FHIR. O InterSystems IRIS for Health (uma versão especial da plataforma InterSystems IRIS) oferece suporte ao padrão FHIR para integração e desenvolvimento de aplicativos

Como você pode ver acima, todos os recursos do OAuth são facilmente acessíveis e totalmente prontos para uso. Se necessário, você pode substituir as classes de manipulador e as interfaces de usuário pelas suas. As configurações do servidor e do cliente OAuth podem ser feitas a partir dos arquivos de configuração, em vez de usar o portal de gerenciamento.