JavaOne LATAM 2015 - Segurança em recursos RESTful com

Segurança em Recursos
RESTful com OAuth2
Rodrigo Cândido da Silva
@rcandidosilva
About Me
• JUG Leader do GUJavaSC
• http://gujavasc.org
• Twitter
• @rcandidosilva
• Contatos
• http://rodrigocandido.me
Agenda
• Segurança em APIs
• HTTP Basic Auth
• Network Security
• Certificated Based
• OAuth 2.0
• Porque utilizar OAuth2?
• Conceitos
• Grant types
• Tokens
• Implementações
• Demo
Web Service API’s
Segurança
Closed
Autenticação
Open
Autorização
Closed
Quais são os requisitos de segurança?
“Stop bad guys from accessing your resources"
• Como identificar as permissões que serão manipuladas?
• Como a informação será codificada e decodificada?
• Quais dados serão necessários para restrição de acesso?
• Quem será responsável por armazenar e fornecer os
dados de segurança?
• Como identificar se a requisição não foi modificada?
Segurança em APIs
• Estratégias para proteger os serviços
• Basic Auth (HTTP Basic)
• Network Security
• Certificate Based
• Arquitetura RESTful não define procedimentos de
segurança
• HTTP methods: GET, POST, PUT, DELETE
• API’s REST são tão vulneráveis quanto aplicações web
tradicionais
• SQL Injection, replay attacks, cross-site scripting, etc
HTTP Basic Auth
$ curl “https://$username:$password@myhost/resource"
• Qual o problema com isto?
• Nada, mas…
• Em qual lugar você busca as credenciais?
• Ok para sistemas onde todos os participantes podem
compartilhar dados confidenciais de um modo seguro
• Apenas suporta informações de "usuário / senha”
• Apenas trabalha com autenticação
• Sem distinção entre usuários e máquinas
Network Security
"Security architecture based on top of web server"
• Qual o problema com isto?
• Nada, mas…
• Chato para "debugar" e um pouco difícil de manter
• Configuração fica fora do escopo de desenvolvedores
• Não existe o conceito de identidade e autenticação
Certificate Based
$ curl -k -cert file.pem:password https://myhost:443/resource
• Qual o problema com isto?
• Nada, mas…
• Não existe o conceito de identidade, apenas caso o
browser tenha os certificados instalados
• Obriga keystores e certificados nas aplicações e nos
serviços
• Não existe uma distinção muito clara quanto a usuários
e máquinas
Porque OAuth
• Protocolo baseado em uma especificação de padrão
aberto definido pelo IETF
• Habilita as aplicações acessarem e compartilharem
serviços sem necessidade de compartilhar credenciais
• Evita problemas com "passwords"
• Essencial para mecanismo via delegação de acesso
• Aplicações terceiras
• Para serviços específicos
• Por um tempo limitado
• Pode trabalhar com revogação seletiva
Quem está utilizando OAuth
OAuth Timeline
• OAuth 1.0
• Especificação core publicada em dezembro/2007
• OAuth 1.0a
• Especificação revisada publicada em junho/2009
• Relacionado a correções de vulnerabilidades de segurança
• OAuth 2.0
• Especificação publicada em outubro/2012
• Ser mais seguro, simples e padronizado
• RFCs adicionais ainda continuam sendo trabalhadas
OAuth 2.0
• Sem username ou passwords (apenas tokens)
• Protocol para autorização – não autenticação
• Utilizada modelo de delegação
• Evita o password sharing anti-pattern
• Estabelece confiança entre recurso, servidor de identidade e o
cliente da aplicação
• Objetivo principal é simplicidade
• Fortemente integrado com TLS/SSL
• Não é compatível com OAuth1
• Facilidades para revogação
OAuth 2.0 Tokens
• Tipos
• Bearer
• Large random token
• Necessita de SSL para proteção em transito
• Servidor necessita gerar e armazenar este hash
• Mac
• Utilizado para evitar repetição
• Não requer a utilização de SSL
• Apenas suportado no OAuth 1.0
• Access Token
• Short-lived token
• Refresh Token
• Long-lived token
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":“bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}
OAuth 2.0 Flow
OAuth 2.0 Flow
Papéis Envolvidos
• Resource Server
• Proteção dos serviços
• Authorization Server
• Emissão de tokens de acesso para os clientes
• Client Application
• Solicita os serviços protegidos em nome do proprietário
• Resource Owner
• Concede o acesso a um serviço protegido
OAuth 2.0 Grant Types
• Authorization Code (web apps)
• Confidencialidade aos clientes
• Utiliza um código de autorização emitido pelo servidor
• Implicit (browser-based and mobile apps)
• Script heavy web apps
• Usuário final pode ver o access token gerado
• Resource Owner Password Credentials (user / password)
• Utilizado em casos aonde o usuário confia no cliente
• Expõe as credenciais do usuário para o cliente
• Client Credentials (application)
• Clientes recebem um token (secret) para acesso
• Ideal para acesso entre aplicações
OAuth 2.0 Grant Types
• Authorization Code / Implicit
http://server/oauth/authorize?response_type=code&client_id=client
&scope=read+write+trust
&redirect_uri=http://localhost/app
http://server/oauth/token?grant_type=authorization_code&code=SkiGJ8
&client_id=client
&client_secret=secret
&redirect_uri=http://localhost/app
{"access_token":"292e1ec1-fda9-4968-b1c3-7cc0dd99483f",
"token_type":"bearer",
"expires_in":299997,
"scope":"trust write read"}
OAuth 2.0 Grant Types
• Resource Owner Password Credentials
http://server/oauth/token?grant_type=password&client_id=client
&client_secret=secret
&username=admin
&password=admin
{"access_token":"292e1ec1-fda9-4968-b1c3-7cc0dd99483f",
"token_type":"bearer",
"expires_in":299997,
"scope":"trust write read"}
OAuth 2.0 Grant Types
• Client Credentials
http://server/oauth/token?grant_type=client_credentials
&client_id=client&client_secret=secret
{"access_token":"292e1ec1-fda9-4968-b1c3-7cc0dd99483f",
"token_type":"bearer",
"expires_in":299997,
"scope":"trust write read"}
OAuth 2.0 Prós & Contras
• Prós
• Ótima integração para acesso de aplicações à
serviços oferecidos por web sites
• Acesso permitido para um escopo limitado ou por
tempo (duração)
• Sem necessidade de compartilhamento de
passwords com aplicações terceiras
• Contras
• Implementação pode ser um pouco complexa
• Problemas de interoperabilidade
• Algumas más implementações podem expor falhas
de segurança
OAuth 2.0 Java Implementations
• Algumas implementações Java disponíveis
• Jersey
• Apache Oltu
• Spring Security OAuth2
• Outras: CXF, Google OAuth2 API, etc
• Não suportado ainda como um padrão Java EE
Jersey
• Open source RESTful Web services framework
• Implementação de referência para JAX-RS
• Integrado com as anotações de segurança Java EE
• @RolesAllowed
• @PermitAll
• @DenyAll
• Suporta funcionalidades para filtro de conteúdo
• @EntityFiltering
• Apenas suporta OAuth2 como cliente :/
Apache Oltu
• Implementação do protocolo OAuth da Apache
• Também oferece outras implementações para padrões de
segurança
• JSON Web Token (JWT)
• JSON Web Signature (JWS)
• OpenID Connect
• Suporta todos os requisitos definidos pelo OAuth2
• Authorization Server
• Resource Server
• Client
• Fornece implementação de clientes OAuth2 para
• Facebook, Foursquare, Github, Google, etc
• Ainda continua sendo melhorado…
Spring Security OAuth
• Oferece implementação para OAuth (1a) e OAuth2
• Implementa os 4 tipos de authorization grants
• Suporta todos os requisitos definidos pelo OAuth2
• Authorization Server
• Resources Server
• Client
• Ótima integração com JAX-RS e Spring MVC
• Configuração utilizando anotações
• Integração com todo o eco-sistema Spring
Spring Authorization Server
• @EnableAuthorizationServer
• Anotação utilizada para configurar OAuth2 authorization server
• Existe também disponível em XML <authorization-server/>
• ClientDetailsServiceConfigurer
• Define os detalhes do cliente do serviço
• Implementação in-memory ou via JDBC
• AuthorizationServerTokenServices
• Operações para gerenciar OAuth2 tokens
• Tokens in-memory, JDBC ou JSON Web Token (JWT)
• AuthorizationServerEndpointConfigurer
• Fornece os grant types suportado pelo servidor
• Todos os grant types são suportados exceto via password
Spring Resource Server
• Pode ser a mesma instância do Authorization Server
• Ou então instalado como uma aplicação separada
• Fornece um filtro de autenticação para aplicações web
• @EnableResourceServer
• Anotação utilizada para configurar OAuth2 resource server
• Existe também disponível em XML <resource-server/>
• Suporta controle de acesso via expressions
• #oauth2.clientHasRole
• #oauth2.clientHasAnyRole
• #oauth2.denyClient
Spring OAuth2 Client
• Cria um filtro para armazenar o contexto do request
• Gerencia o redirecionamento de/para o servidor de
autenticação OAuth2
• @EnableOAuth2Client
• Anotação utilizada para configurar o OAuth2 client
• Existe também disponível em XML <client/>
• OAuth2RestTemplate
• Wrapper client object para acessar os serviços
Demo
• OAuth 2.0 Use Case
• Aplicação compartilhando serviços para diferentes clientes
• http://github.com/rcandidosilva/rest-oauth2-sample
Conclusões…
• Segurança é importante, mas não deve ser intrusiva
• OAuth 2.0 é um padrão que possui muitas funcionalidades
• Spring Security oferece uma boa infra-estrutura para
configuração e segurança de aplicações Java
• Spring Security OAuth oferece uma implementação
completa para o protocolo OAuth2
Perguntas
?
Referências
• http://oauth.net/2/
• http://tools.ietf.org/html/rfc6749
• http://projects.spring.io/spring-security-oauth/
• https://github.com/spring-projects/spring-security-oauth
• http://cxf.apache.org/docs/jax-rs-oauth2.html
• https://jersey.java.net/documentation/latest/security.html#d0e10940
• https://oltu.apache.org
Muito obrigado!
@rcandidosilva
rodrigocandido.me