Simplifique a implementação do OAuth para a sua organização

Um guia para a segurança de OAuth e de API

DOCUMENTAÇÃO TÉCNICA | NOvembrO de 2014

ca.com/br

Sumário

2 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

O que é o OAuth? 3

É possível fornecer um exemplo simples de OAuth? 4

Esse problema não foi resolvido antes? 6

Como o OAuth 2.0 difere das versões anteriores? 6

Por que o OAuth é difícil de ser aplicado? 8

Como o CA API Gateway pode me ajudar a implementar o OAuth? 9

Qual é o benefício de um OAuth Toolkit? 10

Como o CA API Gateway ajuda em casos de uso do OAuth com duas ou três partes? 11

Entre em contato com a CA Technologies 12

ca.com/br3 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

O que é o OAuth?O OAuth é um padrão web emergente para a autorização de acesso limitado a aplicativos e dados. ele foi projetado para que os usuários possam conceder acesso restrito a recursos próprios (como fotos que residem em um site, como o flickr ou o Smugmug) para um cliente terceiro, como um site de impressão de fotos. Antes, era comum solicitar que o usuário compartilhasse seu nome de usuário e sua senha com o cliente, uma solicitação ilusoriamente simples que mascara riscos de segurança inaceitáveis. em contrapartida, o OAuth promove um modelo com menos privilégios, que permite que um usuário conceda acesso limitado a seus aplicativos e dados por meio da emissão de um token com capacidade limitada.

O OAuth é importante porque coloca o gerenciamento da delegação na web nas mãos do verdadeiro proprietário do recurso. O usuário faz a conexão entre suas contas em diferentes aplicativos web sem um envolvimento direto dos administradores de segurança de cada um dos respectivos sites. esse relacionamento pode ser duradouro, mas também pode ser facilmente rescindido a qualquer momento pelo usuário. um dos grandes avanços trazidos pelo OAuth para a comunidade web é a formalização do processo de delegação de mapeamento de identidades para os usuários.

O OAuth está rapidamente se tornando um padrão de base da web moderna e já foi muito além de suas raízes na mídia social. O OAuth agora é muito importante para as empresas. As seguradoras, as operadoras de tv a cabo e até mesmo a área da saúde estão usando o OAuth para gerenciar o acesso a seus recursos. parte dessa adoção é motivada pela necessidade corporativa de oferecer suporte a clientes e dispositivos móveis cada vez mais diversificados, especificamente. essas organizações estão implantando Apis agressivamente para atender a esse novo canal de entrega, e o OAuth é a melhor prática para a autorização de Apis.

No entanto, é importante reconhecer que o OAuth é apenas um componente de uma solução completa de segurança e controle de acesso de Apis. é fácil se concentrar nos detalhes do protocolo e perder a visão geral do gerenciamento de Apis, desde o gerenciamento de usuários até a auditoria, a limitação e a detecção de ameaças. As Apis geralmente representam um canal direto para os aplicativos corporativos essenciais. elas precisam de uma solução de segurança corporativa para protegê-las.

A cA technologies tem o compromisso de fornecer a infraestrutura para os aplicativos corporativos ativados pelo OAuth. Nós oferecemos soluções adicionais que se integram totalmente aos investimentos existentes em tecnologia de iAm (identity and access management - gerenciamento de identidades e acesso) a fim de fornecer um modelo de autorização consistente para toda a empresa. todas as soluções cA Api gateway estão disponíveis como imagens virtuais fáceis de implantar. A cA technologies também fornece a flexibilidade para a integração com implementações de OAuth de terceiros que talvez não estejam totalmente em conformidade com os padrões atuais, isolando você das mudanças que surgem de uma tecnologia em rápida evolução.

esta documentação técnica da cA technologies descreve o que é o OAuth e mostra como você pode tornar o OAuth simples em sua organização.

ca.com/br4 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

É possível fornecer um exemplo simples de OAuth?A mídia social foi a primeira grande adotante do OAuth. O facebook e o twitter devem muito de seu sucesso ao fato de que eles não são apenas sites autônomos, mas plataformas que incentivam a integração com outros aplicativos. Os pontos de integração são Apis reStful que geralmente usam o OAuth como um meio de autenticação, autorização e vinculação de diferentes contas pessoais.

O twitter e o facebook fornecem excelentes exemplos do OAuth em ação. como muitas pessoas, você provavelmente tem contas separadas nessas duas mídias sociais robustas. Os nomes de suas contas podem ser semelhantes (e, em nome da boa segurança, espera-se que você use senhas diferentes), mas elas são contas distintas gerenciadas em sites diferentes. dessa maneira, como você pode fazer para que seus tweets sejam exibidos instantaneamente em sua página do facebook?

Antes, você provavelmente teria de armazenar seu nome de usuário e sua senha do facebook em seu perfil do twitter. dessa maneira, sempre que publicasse um novo tweet, o aplicativo twitter poderia fazer logon para você para publicá-lo também no facebook. essa abordagem passou a ser chamada de antipadrão de senha e é uma má ideia por diversos motivos. confiar ao twitter sua senha do facebook simplesmente dá poder em excesso a esse aplicativo. Se um hacker comprometesse o site ou um administrador interno resolvesse se tornar um fora-da-lei, sua senha sem criptografia poderia ser usada para publicar imagens prejudiciais, bloquear você de entrar no facebook ou até mesmo excluir totalmente a sua conta.

felizmente, o twitter e o facebook usam o OAuth para enfrentar esse desafio. O OAuth fornece um modelo de autorização delegada que permite que o twitter publique em sua página e nada mais além disso. isso é mostrado na figura A, a seguir.

Permitindo que o Twitter publique tweets em seu mural do Facebook

Cliente

Proprietário do recurso (mais

conhecido como Usuário)

1. O usuário publica um novo tweet

2. O Twitter publica o tweet no Facebook

em nome do usuário

Servidor de autorização (AS) Servidor de

recursos (RS)

Figura A.

O OAuth permite que o twitter publique tweets em sua conta do facebook sem usar a sua senha do facebook.

ca.com/br5 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

do ponto de vista do usuário, a interação é muito simples e intuitiva. você pode verificá-la na figura b, a seguir. A partir do painel de configurações do twitter, o usuário clica em um botão que o transfere para o facebook, onde ele pode fazer logon. isso cria uma associação entre essas duas contas separadas do usuário sem nenhum envolvimento dos administradores de segurança do facebook ou do twitter. Após ser autenticado no facebook, o usuário passa por uma cerimônia de consentimento, na qual ele pode escolher o subconjunto de privilégios que deseja conceder ao twitter para permitir que o aplicativo execute ações em seu nome. por fim, o usuário retorna automaticamente ao twitter, onde pode reiniciar a publicação de tweets, que agora também serão exibidos em sua página do facebook. A relação estabelecida será mantida indefinidamente ou até que o usuário decida interrompê-la explicitamente usando os controles encontrados na página de configurações.

para o usuário, esse é um processo simples e intuitivo — e, sem dúvida, isso é boa parte da atração do OAuth. mas por trás disso há uma interação muito mais complexa entre os sites, geralmente chamada de dança do OAuth. OAuth com três partes é o nome popular para o cenário descrito aqui; ele é o caso de uso mais comum da especificação OAuth 1.0a, agora publicada como rfc 5849.

essa especificação é detalhada, mas surpreendentemente específica. ela define o fluxo de redirecionamento que permite que um usuário associe suas contas, autorize um subconjunto limitado de operações e retorne um token ininteligível que o twitter pode manter com segurança para o acesso, em vez de uma senha com poder ilimitado. ela fornece detalhes (pelo menos na versão 1.0) até mesmo de um método para vincular o token ao conteúdo do parâmetro usando assinaturas digitais, o que permite verificações de integridade no conteúdo enviado por canais não criptografados.

um dos pontos fortes da especificação OAuth 1.0a é que, em vez de tentar definir uma estrutura de autorização generalizada, ela foi configurada para oferecer uma solução para o desafio de design comum descrito acima. ela foi uma iniciativa fundamental de pessoas com um problema para resolver no momento certo. como seria de se esperar, ela se tornou admiravelmente bem-sucedida, sendo implementada em sites como google, dropbox, Salesforce, fourSquare e linkedin.

O OAuth, no entanto, está evoluindo. A versão 2, publicada em outubro de 2012, ambiciosamente busca satisfazer um conjunto muito mais generalizado de casos de uso. isso naturalmente adiciona complexidade para a solução e aumenta a dificuldade enfrentada pelos desenvolvedores que tentam implementá-la para proteger as Apis corporativas.

1. Sem autorização para publicar no Facebook

2. Faça logon no Facebook e autorize o Twitter a publicar no mural

3. Com autorização para publicar no Facebook

Figura B.

como um usuário autoriza o twitter a publicar tweets em sua página do facebook.

ca.com/br6 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

Esse problema já não tinha sido resolvido?Não existe nenhum processo formal totalmente definido para a resolução do problema de autorização delegada abordado pelo OAuth. Seus criadores consideraram as alternativas e propuseram apenas algumas soluções (completamente proprietárias). A necessidade com certeza foi a mãe da invenção do OAuth, mas a abrangência era um objetivo importante.

é obviamente concebível que o SAml, com frequência usado para o logon único federado, poderia ser usado como um formato de token para comunicar operações delegadas entre sites por meio do tipo de token de garantia do remetente. entretanto, o SAml sozinho não define o fluxo de interações para estabelecer o relacionamento de confiança ou as vinculações de contas. Além disso, como um formato Xml muito complexo, o SAml não se dá bem com as práticas de desenvolvimento atuais com foco em princípios de reStful e estruturas de dados JSON simples.

O Open id connect tentou oferecer um logon único na web. em um mundo perfeito, no qual o Open id connect fosse universal, talvez o OAuth não fosse necessário. mas, apesar do sucesso em sites influentes, como o Yahoo e o Wordpress, o Open id connect nunca teve uma adoção disseminada. entretanto, o Open id connect pode ter uma segunda chance para o sucesso devido à maneira como complementa o OAuth.

Como o OAuth 2.0 difere das versões anteriores?O OAuth 1 evoluiu muito rapidamente devido à demanda. ele forneceu uma solução para um problema comum, e sua adoção pelos principais aplicativos de mídia social lhe proporcionou uma grande exposição. A implementação mais comum no momento é a 1.0a, que incorpora uma pequena modificação em relação à especificação original, para resolver uma vulnerabilidade de segurança.

A especificação 1.0a é bem-projetada e bastante completa, mas apenas para um pequeno conjunto de casos de uso. possivelmente, esse é um de seus pontos fortes; ele faz uma única coisa, e a faz muito bem. O OAuth 1.0 possui um amplo suporte, com bibliotecas disponíveis em muitos idiomas. entretanto, ele sofre de um forte sentimento de "faça você mesmo", uma característica que pode ser atraente para desenvolvedores individuais, mas que não afeta as empresas.

O OAuth 1.0a possui algumas complexidades adicionais que evitaram que ele fosse mais amplamente aceito. ele adiciona complexidade aos clientes, especialmente em torno do processamento de criptografia, o que pode ser difícil de codificar usando linguagens como JavaScript. por exemplo, o OAuth 1.0a exige que os clientes assinem parâmetros http. essa é uma boa ideia para transmissões não criptografadas (um padrão de uso comum na web convencional), mas não tão boa com Apis.

O próprio processo de assinatura é confuso devido à necessidade de canonizar parâmetros (por exemplo, normalizar a ordenação, lidar com sequências de escape, etc.). essa tem sido uma grande fonte de frustração para os desenvolvedores, pois os clientes e os servidores de recursos geralmente têm interpretações diferentes sobre como as assinaturas são aplicadas.

certamente, existem bibliotecas que podem ajudar nessa questão, mas um problema ainda maior é que a necessidade de assinatura limita a capacidade dos desenvolvedores de testar as transações usando utilitários de linha de comando simples, como curl. muito do encanto do estilo reStful em relação ao uso de alternativas como serviços web SOAp é que ele não exige ferramentas especiais para a codificação. As assinaturas do OAuth contrariam essa vantagem.

ca.com/br7 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

A especificação anterior também tinha uma visão limitada dos tipos de clientes. No caso de três partes mais claro, o cliente geralmente era um aplicativo web. entretanto, os desenvolvedores queriam usar o OAuth cada vez mais em aplicativos em execução em um navegador ou em aplicativos autônomos em execução em dispositivos móveis, como telefones ou tablets. isso é possível com o OAuth 1.0, mas a experiência do usuário é ruim, pois ela pode envolver uma complicada operação do tipo copiar e colar entre um navegador e o aplicativo.

O OAuth 2.0 tenta generalizar a implementação do OAuth original a fim de simplificar o desenvolvimento de clientes, melhorar a experiência de usuário geral e expandir as implantações do OAuth. isso exigiu mudanças significativas, incompatíveis com as versões anteriores.

A nova especificação separa explicitamente as funções de autorização do controle de acesso. Agora, o servidor de autorização está claramente separado do servidor de recursos. Além da segregação lógica de funções, isso também possibilita o uso de um servidor de autorização central e a distribuição de servidores de vários recursos, muito semelhante a uma arquitetura de SSO clássica. Na verdade, um servidor de autorização do OAuth 2.0 é realmente o equivalente reStful de um StS (Security token Service - Serviço de token de segurança).

O OAuth 2.0 tenta oferecer suporte a três perfis de cliente: aplicativos web convencionais, aplicativos com base em um agente de usuário (ou seja, um navegador web) e aplicativos nativos (como um aplicativo de celular, um decodificador de sinais ou até mesmo um console de videogame). cada um desses perfis pode ter funcionalidades diferentes em termos de interação entre os proprietários do recurso, os servidores de autorização e os recursos protegidos. cada um deles também pode estar sujeito a requisitos de segurança diferentes. A especificação descreve várias concessões de autorização novas para acomodar essas necessidades diversificadas. As concessões descrevem um processo pelo qual um cliente pode adquirir acesso autorizado a um recurso.

essas concessões incluem:

•Código de autorização — essa concessão descreve o típico cenário de três partes, no qual o cliente é um aplicativo web, como o twitter. ela usa um código de autorização intermediário para delegar a autorização de maneira segura a partir de um servidor de autorização para um cliente por meio do agente de usuário (navegador) do proprietário do recurso. Seu benefício é que as credenciais do proprietário do recurso nunca são compartilhadas com o cliente, nem o token de acesso é compartilhado com o agente de usuário do proprietário do recurso, onde ele poderia ser interceptado.

Cliente

Proprietáriodo recurso

Servidor de autorização

Servidor de recursos

Adquirirtoken

Usartoken

Figura C.

O OAuth 2.0 faz uma distinção clara entre o servidor de autorização e o servidor de recursos e, além disso, ele define os fluxos que descrevem a aquisição do token.

ca.com/br8 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

•Implícita — essa é uma concessão um pouco mais simples que é mais adequada para aplicativos em execução em um agente de usuário, como aplicativos JavaScript. O cliente adquire diretamente um token de acesso a partir do servidor de autorização. isso elimina boa parte da complexidade do código de autorização intermediário, mas apresenta a desvantagem de que o proprietário do recurso pode potencialmente obter o token de acesso.

•Credenciais de senha do proprietário do recurso — nessa concessão, o proprietário do recurso compartilha as credenciais diretamente com o cliente, que as utiliza para obter um token de acesso de maneira direta, em uma única transação. As credenciais não são mantidas, pois o cliente usa o token de acesso para todas as interações subsequentes com recursos protegidos. esse é um fluxo muito simples, mas ele exige que haja confiança entre o proprietário do recurso e o cliente.

•Credenciais de cliente — nesse fluxo, o cliente usa suas próprias credenciais para acessar um recurso. dessa maneira, os direitos existentes do cliente estão realmente sendo utilizados.

Além dessas concessões, existe um mecanismo de extensibilidade para acomodar outras formas de autorização. por exemplo, existe uma especificação de token de transmissão de SAml que descreve o uso de tokens de SAml como meio de adquirir tokens de acesso do OAuth. isso é muito importante porque representa uma ponte entre a infraestrutura de SSO de navegador clássica e as Apis modernas.

Os tokens foram alterados no OAuth 2.0 para oferecer um suporte melhor ao gerenciamento de sessões. Anteriormente, os tokens de acesso tinham uma duração muito longa (até um ano) ou, como no caso do twitter, tinham duração ilimitada. O OAuth 2.0 introduz o conceito de tokens de curta duração e autorizações de longa duração. Os servidores de autorização agora emitem tokens de atualização de cliente. eles são tokens de longa duração que um cliente pode usar várias vezes para adquirir tokens de acesso de curta duração. um de seus benefícios é que os proprietários de recursos ou os administradores de segurança podem facilmente impedir que clientes adquiram novos tokens, se necessário.

As assinaturas de token agora são opcionais. A preferência é pelo uso de tokens de transmissão simples (o que significa que o token é utilizado diretamente para a obtenção de acesso e é considerado secreto) protegidos por SSl. isso é muito mais simples do que o processamento de assinaturas, embora esse processamento ainda exista em uma forma simplificada para dar suporte a transações que não são SSl.

Por que o OAuth é difícil de ser aplicado?criar uma prova de conceito de OAuth simples não é difícil; existem bibliotecas na maioria dos principais idiomas que podem ajudar a enfrentar o desafio de escrever o código de uma demonstração completa do OAuth. entretanto, a implementação do OAuth em grande escala — onde o volume de transações, a quantidade de Apis a serem protegidas e a quantidade de clientes variados contribuem para a escala — continua sendo um grande desafio para qualquer grupo de desenvolvimento e operações.

O OAuth 2.0 também é um alvo em movimento. A especificação 1.0a resolveu um problema, e fez isso muito bem. mas o crescente escopo e a generalização da nova especificação criaram uma ambiguidade considerável que torna a interoperabilidade extremamente desafiadora. é por isso que muitos aplicativos de rede social — os principais constituintes do movimento do OAuth — permanecem na especificação 1.0, aguardando que tudo seja estabelecido.

A abertura de formatos de token ilustra bem isso. embora, por um lado, tenha simplificado muito o processo de assinatura, que era desafiador para os desenvolvedores nas especificações anteriores, isso também introduziu a capacidade de encapsular tokens diferentes (como SAml) — criando oportunidades para utilizar os investimentos existentes, mas, também, criando desafios significativos de interoperabilidade.

ca.com/br9 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

O maior erro que as pessoas cometem com o OAuth hoje é considerá-lo isoladamente. O OAuth é realmente uma tendência atraente, mas é apenas uma peça do quebra-cabeça do controle de acesso corporativo. A autorização não pode ser totalmente determinada pelo cliente; a empresa que hospeda o recurso protegido também deve ter controle. As implementações do OAuth de ponto único raramente reconhecem essa via de mão dupla, mas a confiança e o controle recíprocos são essenciais para a empresa.

O OAuth deve fazer parte do sistema geral de controle de acesso com base em diretivas para Apis corporativas, e não apenas uma solução independente. O controle de acesso com base em diretivas fornece controle sobre o acesso a ambas as partes. ele incorpora controles como restrições de hora do dia e listas brancas/negras de ips. identifica e neutraliza ameaças como injeção de Sql ou ataques de XSS (cross-Site Scripting - Script entre Sites). ele valida parâmetros e o conteúdo de mensagens (incluindo JSON ou Xml) de acordo com valores aceitáveis. também se integra completamente a sistemas de auditoria corporativa, de forma que os provedores de recursos saibam exatamente quem está acessando o que e quando. e, por fim, o controle de acesso com base em diretivas permite o gerenciamento de ANSs por meio de modelagem das comunicações de rede, roteamento das transações para servidores disponíveis e controle do tráfego excessivo antes de ele afetar a experiência do usuário ou colocar os servidores em risco.

As empresas nunca deveriam considerar a criação de sua própria infraestrutura de iAm para seu site — os arquitetos e os desenvolvedores reconhecem que existe muito mais nisso do que apenas a autenticação http básica. O OAuth é semelhante, ilusoriamente simples e, no fim, uma peça de um processo de autorização geral muito complexo.

Como o CA API Gateway pode me ajudar a implementar o OAuth?A cA technologies fornece uma solução completa e pronta para uso para as implementações do OAuth 1.0a e do OAuth 2.0. O OAuth está incluído no mecanismo de controle de acesso avançado e com base em diretivas do cA Api gateway. isso é o OAuth realmente em larga escala, lidando com dezenas de milhares de transações por segundo em uma única instância do gateway. esses gateways podem ser implantados como equipamentos de hardware ou imagens virtualizadas de baixo custo. Ambos os fatores forma fornecem uma infraestrutura de segurança de nível militar para o OAuth corporativo, incorporando módulos de criptografia certificados para fipS, detecção avançada de ameaças, gerenciamento de tráfego de ANS e controle de acesso refinado em um único pacote. é como ter um guarda em sua porta, em vez de apenas uma tranca.

Os gateways de Api da cA technologies podem ser implantados como servidores de autorização (AS) e como servidores de recursos protegidos (rS). Ambos os elementos de arquitetura podem ser mesclados em uma única instância de gateway ou eles podem ser separados, permitindo que um servidor de autorização centralizado atenda a muitas instâncias de servidores de recursos protegidos distribuídos, conforme ilustrado na figura d.

como os cA Api gateways são fornecidos como fatores forma de equipamento de hardware e virtual, eles oferecem suporte à mais ampla variedade possível de implantações. Os gateways de hardware são disponibilizados com hSms (hardware Security modules - módulos de segurança de hardware) integrados, o que fornece uma importante proteção para os ambientes mais seguros. Os equipamentos virtuais simplificam a implantação e podem ser executados em qualquer lugar, desde o computador até a mais robusta infraestrutura de servidores.

ca.com/br10 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

Qual é o benefício de um OAuth Toolkit?O OAuth toolkit do cA Api gateway usa modelos padronizados criados para funcionar prontamente para implantações do OAuth comuns. Ao utilizá-los, os clientes podem adicionar recursos robustos do OAuth toolkit às Apis existentes em minutos, em vez de dias.

entretanto, a verdade é que a solução universal prometida por tantos fornecedores raramente funciona bem fora de uma oportunidade nova muito limitada. por exemplo, a maioria dos projetos do mundo real possui sistemas de identidades existentes que precisam ser acessados ou uma infraestrutura de chave pública com a qual é necessário se integrar. como um setor, nós somos muito bons em integração de aplicativos e dados; a integração de segurança permanece um desafio constante.

para enfrentar melhor esses desafios de integração, o cA Api gateway também fornece componentes do OAuth toolkit básicos, desde criptografia até canonização de parâmetros e gerenciamento de sessões. esses são os mesmos componentes básicos usados em nossa solução pronta para uso completa, mas apresentados como asserções totalmente configuráveis em uma diretiva de controle de acesso. isso permite que arquitetos e desenvolvedores ajustem suas implementações do OAuth toolkit para atender a praticamente todos os desafios que possam vir a enfrentar.

A personalização da cerimônia de consentimento do OAuth toolkit é outra área que se beneficia muito da abertura dos modelos de gateway, aprimorada pela potência de um kit de ferramentas flexível e aberto. A definição da confiança inicial é uma parte essencial de todo o processo do OAuth toolkit. O cA Api gateway permite que você personalize totalmente essa etapa para garantir que ela se integre com a infraestrutura de identidades existente e atenda às demandas de conformidade da empresa.

Cliente

Proprietário do recurso (mais conhecido como Usuário)

Servidor de autorização (AS)

Servidor de recursos (RS)

Rede corporativa

As funções de AS e RS podem ser combinadas em um único gateway

ou distribuídas pela rede

CA APIGateway

CA APIGateway

Figura D.

Os gateways de Api da cA technologies simplificam a implementação do OAuth.

ca.com/br11 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

Como a CA Technologies ajuda em casos de uso do OAuth com duas ou três partes?O cA Api gateway pode fornecer serviços de autorização de ponto de extremidade e controle de acesso para serviços protegidos. essas duas funções podem coexistir em um único gateway ou podem ser separadas. A vantagem de separá-las está relacionada à escalabilidade, redundância e distribuição geográfica de serviços. isso também permite o alinhamento em torno de casos de negócios, como particionamento físico de Apis corporativas versus públicas. A maioria das organizações tem uma grande quantidade de Apis para proteger, geralmente em vários locais diferentes. Nesses casos, faz sentido implantar gateways de Api centralizados da cA technologies como servidores de autorização (normalmente, em um agrupamento para redundância) e agrupamentos remotos de gateways para proteger instâncias de Api específicas.

Os dois padrões de implantação podem atender às versões OAuth 1.0a e 2.0 simultaneamente. esse padrão também funciona para os cenários clássicos com duas e três partes, bem como para o modelo de concessão do OAuth 2.0, incluindo as concessões de extensão, como o token de transmissão de SAml. essas implantações estão ilustradas nas figuras e e f.

Implantação de duas partes da CA Technologies

Proprietário do recurso

Clientes

Firewall 1 Firewall 2

Balanceador de carga

Servidor de recursos (RS)

Servidor de autorização (AS)

Servidor de recursos protegidos (APIs seguras)

Infraestrutura de identidades

CA API Gateway

CA API Gateway

Implantação de três partes da CA Technologies

Proprietáriodo recurso

Firewall 1 Firewall 2

Balanceador de carga

Servidor de recursos (RS)

Servidor de autorização (AS)

Servidor de recursos protegidos (APIs seguras)

Infraestrutura de identidades

Cliente

CA API Gateway

CA API Gateway

Figura E.

implantação típica para o cenário clássico de duas partes ou concessões como credenciais do proprietário do recurso e credenciais do cliente.

Figura F.

cenários típicos de implantação com três partes e concessão de código de autorização, bem como tipos de concessão implícita. Observe que o cA Api gateway pode oferecer suporte a todas as versões do OAuth simultaneamente, bem como a mapeamentos personalizados para acomodar questões de interoperabilidade.

Conecte-se com a CA Technologies em ca.com/br

A cA technologies (NASdAq: cA) cria software que acelera a transformação das empresas e permite que elas aproveitem as oportunidades da era dos aplicativos. O software está no cerne de todas as empresas, em todos os setores. do planejamento ao desenvolvimento e do gerenciamento à segurança, a cA está trabalhando com empresas de todo o mundo para mudar a maneira como vivemos, fazemos negócios e nos comunicamos – usando dispositivos móveis, as nuvens privada e pública e os ambientes distribuídos e de mainframe. Obtenha mais informações em ca.com/br.

12 | dOcumeNtAçãO técNicA: Simplifique A implemeNtAçãO dO OAuth pArA A SuA OrgANizAçãO

copyright © 2014 cA technologies. conteúdo confidencial. todos os direitos reservados. cS200-87200_1114

Entre em contato com a CA TechnologiesA cA technologies agradece as suas perguntas e os seus comentários em geral. para obter mais informações, entre em contato com o representante da cA technologies ou visite www.ca.com/br/api