Usando OAuth no IBM WebSphere DataPower Appliances, parte 1: Apresentando o Suporte OAuth 2.0 no Firmware do DataPower Revisão 5.0

Este artigo é o primeiro de uma série de várias partes que descreve o suporte do OAuth em dispositivos WebSphere® DataPower. A parte 1 começa com uma visão geral do OAuth e depois descreve o suporte do DataPower para recursos do OAuth. O restante da série entrará em detalhes sobre diversos aspectos do OAuth e do uso e da configuração do DataPower.

John Rasmussen, Senior Software Developer, IBM

Photo of John RasmussenJohn Rasmussen é engenheiro de software senior do Software Group da IBM. Ele trabalha com a DataPower Corporation e a IBM desde 2002, como engenheiro de desenvolvimento de produtos e especialista em serviços, ajudando diversos clientes na implementação de dispositivos DataPower. John tem experiência em segurança e desenvolvimento de software, incluindo trabalhos com a McCormack & Dodge e Fidelity Investments, e como desenvolvedor independente de software aplicativo e sistemas de segurança.



24/Ago/2012

Introdução

Bem-vindo à série de artigos do IBM® WebSphere DataPower e OAuth .. Esses artigos fornecem uma introdução ao OAuth e à função que o DataPower desempenha como ponto de execução de política (PEP) e ponto de decisão de política (PDP) nas arquiteturas do OAuth. Se você estiver familiarizado com o DataPower, estará ciente da finalidade desses dispositivos e do hardware e firmware especializados que são aproveitados para fornecer uma segurança altamente otimizada e protegida, integração e plataformas de transformação. Discutiremos os recursos mais recentes de suporte do OAuth no release 5.0, incluindo a integração com o Tivoli® Federated Identify Management V6.2.2 da IBM ou produtos posteriores.

A parte 1 apresenta uma introdução ao OAuth e ao suporte do DataPower. Os outros artigos da série são:

Os seguintes artigos na série estarão disponíveis nas próximas semanas:

  • Parte 7: Usando o WebSphere DataPower com o Tivoli Federated Identity Manager para suportar OAuth 2.0 descreve como usar o serviço do DataPower para atuar como um ponto de execução de token do OAuth para um servidor de autorização do Tivoli Federated Identity Manager OAuth.
  • Parte 8: Personalizando o suporte do DataPower para o processamento da identidade e do escopo do OAuth demonstra como ampliar o processamento do DataPower de uma identidade e um escopo do OAuth.
  • Parte 9: Personalizando o suporte nativo do DataPower para tokens de acesso e códigos de autorização do OAuth mostra como personalizar a emissão e a verificação de tokens de acesso e códigos de autorização.
  • Parte 10: Resolução de problemas do suporte do protocolo do DataPower OAuth descreve ferramentas e técnicas para depurar configurações do DataPower OAuth.

Visão Geral do OAuth

O OAuth é uma estrutura de autorização que permite que o proprietário de um recurso conceda permissão para o acesso de seus recursos sem compartilhar suas credenciais e forneça acesso limitado aos recursos armazenados por serviços baseados na web acessados por HTTP. Isso não deve ser confundido com serviços da web e arquitetura orientada a serviços (SOA). Enquanto essas arquiteturas existem em um amplo array de implementações, o OAuth é prioriza mais a infraestrutura da Web 2.0 emergente e a popularidade das APIs que existem para fornecer acesso personalizado aos aplicativos de uma organização. Por exemplo, o eBay® fornece uma API para fornecer experiências de compras aprimoradas integrando aplicativos de terceiros. O Twitter® e o Facebook® fornecem APIs que ampliam seus aplicativos fornecendo recursos de compartilhamento de conteúdo. Cada uma dessas integrações exige uma atenção focada em todos os aspectos da segurança e da necessidade de considerar que todos os acessos não são confiáveis até que se prove o contrário.

Em implementações estabelecidas, os recursos são protegidos e acessados ao se fornecer credenciais que podem ser autenticadas e que um servidor de recurso pode usar para autorizar o acesso ao recurso. Se o proprietário de um recurso quiser conceder acesso a um terceiro, será preciso fornecer credenciais, autenticá-las, e o acesso deve ser autorizado pelo serviço de autorização que protege os recursos.

Essas arquiteturas estabelecidas apresentam diversos problemas, incluindo a fraqueza herdada da autenticação de senha. Senhas são vulneráveis. Uma pessoa que esteja na sala ou talvez olhando pelo canto do olho poderia obter suas credenciais e ter acesso a seus recursos. E, provavelmente, o proprietário do recurso precisa compartilhar sua senha com a entidade que precisa do acesso. E quando uma senha é alterada, a entidade não tem mais acesso ao recurso. Uma limitação mais fundamental é que a autenticação e a autorização são controladas pelo proprietário do recurso e, portanto, limitam o compartilhamento das informações de autenticação. As organizações de TI desempenharam um papel fundamental nessas decisões de segurança que limitam a flexibilidade. Quem você é consiste em um componente do controle de acesso que pode ser externalizado do processo de autorização, fornecendo uma federação do gerenciamento de identidade nos limites organizacionais.

O OAuth trabalha para tratar desses problemas fornecendo um serviço de autorização separado do proprietário do recurso. Serviços de autenticação confiáveis podem ser usados para fornecer "tokens", concedendo acesso aos recursos. Um proprietário do recurso do OAuth concede a um cliente acesso a seus recursos por meio da autenticação com o serviço de autenticação e o serviço de autorização que emite tokens de acesso específicos de serviço para terceiros. Em um caso de uso típico do OAuth (mostrado na Figura 1), você (proprietário do recurso) pode fornecer acesso a um serviço de impressão (terceiro, o cliente) a suas fotos (recurso) autenticando por um serviço de autenticação e fornecendo acesso limitado (token de acesso).

Figure 1. Fluxo do token de acesso ao serviço de impressão do OAuth
Figure 1. Fluxo do token de acesso ao serviço de impressão do OAuth

Os objetivos do OAuth são semelhantes em alguns aspectos com a Security Assertion Markup Language (SAML), publicada peloOASIS. No entanto, como a SAML é associada ao SOA e usa o XML e o SOAP como suas bases de protocolo, o OAuth aproveita a notação do JavaScript. O OAuth é flexível o suficiente para trabalhar na modalidade JSON, comum em ambientes Web 2.0 e web móvel.

A versão atual do OAuth, 2.0, é publicada em formato de rascunho pela Internet Engineering Task Force (IEFT). Você pode querer revisar os documentos OAuth IEFT atuais para obter mais informações.

Termos do OAuth

Agora que você tem um conhecimento básico dos objetivos do OAuth, vamos revisar um pouco da terminologia. Esta seção descreve funções básicas, tipos de autenticação e fluxos básicos que ocorrem no processo de obtenção de acesso a recursos protegidos. Descrevemos alguns deles em nossa introdução, mas vamos revisá-los mais uma vez:

  • Proprietário do recurso: Uma entidade (possivelmente uma pessoa ou usuário final) que é capaz de conceder acesso a recursos protegidos.
  • Servidor de recursos: Um processo (tipicamente um servidor HTTP) que é capaz de aceitar e responder a solicitações de recursos e resolver tokens de acesso.
  • Servidor de autorização: Um processo (tipicamente um Secure Token Service - STS) que é capaz de autenticar um proprietário de recurso e emitir tokens de acesso. O serviço de autorização realiza diversas funções e, portanto, apresenta diversos pontos de extremidade de serviço. Há pontos de extremidade e pontos de execução de token e de autorização para o servidor de recursos.
  • Cliente: Uma entidade que faz uma solicitação para um recurso para a aprovação do proprietário do recurso.

Fluxo de protocolo

Agora vamos revisar o fluxo de protocolo do tipo de concessão de código de autorização do OAuth tradicional mostrado na Figura 2.

Figura 2. Fluxo de protocolo de concessão de código de autorização do OAuth tradicional
Fluxo de protocolo de concessão de código de autorização do OAuth tradicional

O fluxo básico é para frente e, conforme discutimos, o cliente solicita o acesso a um recurso para o proprietário do recurso, que responde com uma concessão de autorização que define privilégios específicos de acesso. O proprietário do recurso normalmente usa o servidor de autorização para a geração de concessões. A concessão de autorização é enviada ao servidor de autorização, que responde com um token de acesso que é usado para acessar o recurso pelo servidor de recursos.


Concessões e tokens

Discutimos a "concessão" dos direitos de acesso pelo proprietário do recurso para seus recursos protegidos. O tipo de concessão pode variar dependendo do nível de confiança entre o cliente e o proprietário do recurso, do relacionamento do cliente com o recurso protegido e também do tipo de implementação. O OAuth definiu dois tipos gerais de cliente, dependendo de suas capacidades de manter a confidencialidade de suas credenciais:

  • Confidencial: Para clientes que são capazes de manter a confidencialidade de suas credenciais.
  • Pública: Para aqueles clientes que não são capazes de manter a confidencialidade de suas credenciais.

Cada cliente deve se registrar no servidor de autorização antes de fazer uma troca de protocolo do OAuth. O registro bem-sucedido resulta no estabelecimento de um "identificador do cliente" e outros metadados no servidor de autenticação, os quais serão usados pelo cliente em interações subsequentes.

A concessão do código de autorização fica disponível quando o servidor de autorização atua como intermediário entre o cliente confidencial e o proprietário do recurso. Os redirecionamentos de HTTP são usados pelo cliente para direcionar o proprietário do recurso ao servidor de autenticação (incluindo seu identificador de cliente e escopo pretendido) que, por sua vez, direciona o código de autenticação de volta para o cliente. A autenticação do proprietário do recurso é realizada sem o compartilhamento de credenciais com o cliente, assim como a transmissão direta do token de acesso ao cliente não atravessa o proprietário do recurso.

Concessões implícitas estão disponíveis como um método simplificado de geração do token de acesso para clientes públicos baseados em navegadores. Em vez de gerar a concessão intermediária, o token de acesso é emitido diretamente ao cliente depois de autenticar o proprietário do recurso. Embora isso melhore a eficiência, é um método menos seguro do que as concessões de código de autorização intermediárias, como a concessão do código de autorização.

As concessões de credencial de senha do proprietário do recurso podem ser usadas diretamente por um cliente para obter um token de acesso. Deve haver um alto nível de confiança entre eles.

As credenciais do cliente podem ser usadas para a geração de token de acesso e autenticação em instâncias onde o cliente é o proprietário do recurso ou está atuando em autorizações já existentes. O cliente pode ser o proprietário do recurso nessa instância.

Os tokens de acesso fornecem direitos de acesso, mas também restrições, como escopo e duração. Esse token normalmente é uma cadeia de caracteres opaca que pode assumir o formato de um cursor para recuperar o token de acesso real ou fornecer informações autocontidas. Os tokens de acesso podem ter formatos diferentes quando usados para acessar recursos protegidos:

  • Um token de acesso consiste em dados opacos. Isso requer protocolos seguros, como HTTPS, para que a transmissão proteja o token.
  • Um token MAC usa uma chave MAC fornecida para assinar seções da solicitação para verificação de integridade.
  • Tokens atualizados podem ser emitidos pelo servidor de autenticação durante a geração do token de acesso. Eles podem ser usados pelo cliente para obter tokens de acesso adicionais quando os tokens de acesso existentes tiverem expirado ou para obter um conjunto de permissões mais limitado do que o definido originalmente.

Fluxos duplos vs. fluxos triplos

Os cenários que descrevemos até agora lidaram com a arquitetura típica do OAuth, em que um proprietário de recurso oferece a um cliente (terceiro) acesso a seus recursos. Isso é autorizado pelo serviço de autorização e fornecido pelo servidor de recursos. Nesse fluxo triplo, o proprietário do recurso não deseja fornecer suas credenciais ao cliente, portanto, o cliente solicita um código de autorização conforme demonstrado na Figura 2.

No entanto, a especificação também possibilita um cenário em que o cliente pode ser o proprietário do recurso ou uma entidade confiável à qual tenham sido fornecidas as credenciais do proprietário do recurso. Nesse caso de uso duplo, não há interação direta do proprietário do recurso. Ele exige uma credencial de senha do proprietário do recurso ou um tipo de concessão de credencial do cliente.


Suporte do DataPower para o OAuth

Agora que descrevemos alguns dos aspectos fundamentais do OAuth, vamos apresentar os recursos fornecidos pela versão 5.0 do firmware do DataPower. Discussões detalhadas e casos de uso específicos serão demonstrados no restante da série de artigos. Por ora, apresentaremos as funções suportadas, os tipos de concessão, novos objetos e casos de uso.

O DataPower pode atuar como um serviço de autorização do OAuth que responde às solicitações de ponto de extremidade de token e de ponto de extremidade de autorização.O DataPower pode atuar como um Ponto de Execução de Política (PEP) para um servidor de recursos que recebe solicitações do OAuth 2.0. O DataPower pode se integrar com o Tivoli Federated Identity Manager V6.2.2 da IBM ou superior. As interações com o Federated Identity Manager usam o protocolo WS-Trust para a verificação do token. O DataPower oferece suporte a tokens de acesso com suporte à integridade e à confidencialidade fornecidas pelo transporte seguro subjacente (HTTPS).

Novos objetos e configurações são fornecidos para suportar interações do OAuth:

  • O OAuth Client Profile é um novo objeto de configuração usado para definir os parâmetros que são usados durante o processo de registro, como ID do cliente, URL de redirecionamento, escopo e tempo de vida. Formulários de autenticação, segredo compartilhado, bem como funções e tipos de concessão suportados que o cliente usará em trocas de protocolo subsequentes também serão definidos aqui. O Grupo de Clientes do OAuth é usado para criar coleções de clientes do OAuth.
  • A Política AAA foi aprimorada para fornecer recursos específicos do OAuth, incluindo:
    • Extract Identity OAuth Method usado para obter o ID do cliente do OAuth e o segredo compartilhado.
    • Extract Resource Processing Metadata usado para obter o escopo do OAuth solicitado.
  • O Web Token Service é um novo objeto de configuração de serviço que atua como um serviço de token e como um serviço de autorização do OAuth. Um assistente é fornecido para orientá-lo pela criação das políticas.

A Figura 3 mostra a troca de protocolo do OAuth anterior atualizada para usar o DataPower tanto como serviço de autorização como serviço de autenticação para o servidor de recursos:

  • Ao atuar como ponto de extremidade do serviço de autorização, o DataPower produz a concessão de autorização.
  • Como ponto de extremidade do token, ele produz tokens de acesso.
  • Ao atuar como ponto de execução para proteger o serviço de recursos, ele valida os tokens de acesso usados para acessar recursos protegidos.
    Figura 3. O DataPower atuando como um serviço de autorização e ponto de execução para um servidor de recursos
    O DataPower atuando como um serviço de autorização e ponto de execução para um servidor de recursos

A Figura 4 mostra a integração do Tivoli Federated Identity Manager para serviços de autorização. Essa integração aproveita os recursos de federação de nível corporativo do Tivoli.

Figura 4. Integração do Tivoli Federated Identity Manager para serviços de autorização
Integração do Tivoli Federated Identity Manager para serviços de autorização

Conclusão

Esse artigo apresentou alguns dos conceitos fundamentais do OAuth e do suporte fornecido pelo release 5.0 do DataPower. Os produtos do dispositivo do DataPower consistem em plataformas de transformação, integração e segurança otimizada comprovadas e altamente seguras. O recurso descrito permite a implementação e a integração das trocas de protocolo do OAuth.

Para obter mais informações, veja o restante da série de artigos a seguir:

Os seguintes artigos na série estarão disponíveis nas próximas semanas:

  • Parte 7: Usando o WebSphere DataPower com o Tivoli Federated Identity Manager para suportar OAuth 2.0
  • Parte 8: Personalizando o suporte nativo do WebSphere DataPower para o escopo do OAuth, processamento de identidade e processamento adicional
  • Parte 9: Personalizando o suporte nativo do DataPower para tokens de acesso e códigos de autorização do OAuth
  • Parte 10: Resolução de problemas do suporte do protocolo do DataPower OAuth

Agradecimentos

Diversas pessoas contribuíram para a implementação do OAuth no DataPower. Os autores desta série de artigos querem agradecer aos membros da organização Serviços de Software IBM para WebSphere por suas contribuições, incluindo: Cindy Claudant, Nicholas A. Glowacki, Tamika Moodye Timothy Baker.

Recursos

Aprender

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tivoli, WebSphere
ArticleID=831549
ArticleTitle=Usando OAuth no IBM WebSphere DataPower Appliances, parte 1: Apresentando o Suporte OAuth 2.0 no Firmware do DataPower Revisão 5.0
publish-date=08242012