visão geral da segurança em java ee
TRANSCRIPT
Conteúdo1. Segurança padrão no Java EE
Mecanismos de segurança em Java SE e Java EE Terminologia essencial APIs padrão do Java EE Passo-a-passo de um cenário típico
2. Segurança em componentes Java EEAlternativas de autenticação Web WebServlets, WebFilters, JSF e backing beans WebSockets EJB (Session e MessageDriven) Web Services REST e SOAP
3. Conclusões, alternativas e tendênciasO que falta? Alternativas à segurança Java EE JSR 375 (outra palestra!)
Quem sou eu? Who am I? Кто я?Helder da Rocha
argonavis.com.br
Tecnologia * Ciência * Arte Java & Web desde 1995 Autor de cursos e livros
+ de 2500 alunos + de 8000 horas de aula
helderdarocha.com.br
O que é Segurança?• Safety: proteção contra danos não-intencionais
• Problemas: bugs em geral e vulnerabilidades intrínsecas do sistema (threads, ambiente, recursos externos, etc.)
• Proteção: qualidade da plataforma, boas práticas, testes, validação, monitoração, logging, checksums, etc.
• Security: proteção contra danos intencionais • Problemas: ataques em geral, acesso e manipulação de
dados protegidos, danos ao sistema ou a terceiros • Proteção: autenticação, autorização,
criptografia, auditoria, filtros, auditoria, hashes, etc.
Escopo desta palestra• Uma visão geral dos recursos de segurança (~ security) da
plataforma Java EE: mecanismos e APIs padrão para • Identificação e autenticação de usuários • Controle de acesso a dados restritos • Controle de execução de operações protegidas • Garantias de integridade e confidencialidade
para informações que trafegam em rede • Não faz parte do escopo desta palestra
• Tópicos de segurança não tratados explicitamente nas specs (ex: vulnerabilidades OWASP, governança, auditoria, etc.)
• Recursos proprietários(WildFly, GlassFish, etc.) • Frameworks de terceiros (Spring Security, Seam Security, OAuth, ...)
Autenticaçãoe Autorização
Policy / Security ManagerJAASJarSigner TSA/TSP (RFC 3161)
ComunicaçãoSegura
JSSE (SSL/TLS) SASL (RFC 2222) GSS-API (RFC 2853)
CriptografiaJCA JCE Java XML DSig (JSR 105)
Infraestrutura de Chave Pública (PKI)
X.509, CRLs e CertPath API OCSP (RFC 2560) PKCS#11
"Sandbox" da JVM Classloader
Garbage collectionBytecode verification
Data-typing
Segurança nativa da Plataforma Java
+
Mecanismos de segurançaJava SE 8
Mensagem
MensagemRole
Principal
Role
useridpass / cert
Cama
da de
Aplic
açõe
sCamada de Aplicações
Camada de Transportes
Autenticação
Mensagem
ConexãoSegura SSL/TLS
ConexãoInsegura
Autorização
Operações e Recursos
APIs programáticas: autenticação (JASPIC) e autorização (JACC + contextos de segurança de cada tipo de componente) APIs declarativas: autorização, config de autenticação HTTP (JAAS) e config de transporte SSL/TLS por recurso/método HTTP
Mecanismos de segurançaJava EE 7
Camada Web
Requisição 1: Pede página restrita GET /app/faces/biblioteca.xhtml
Web Container
Resposta 1: Pede credenciais 401 Unauthorized WWW-Authenticate: Basic realm="jdbc-realm"
Requisição 2: Envia credenciais GET /app/faces/biblioteca.xhtml Authorization: Basic bWFzaGE6MTIzNDU=
Resposta 2: Envia página restrita 200 OK
Configuração (web.xml) HTTPS 2-way (CONFIDENTIAL) Autenticação: jdbc-realm Métodos: GET, POST Roles: todos os logados (**)
Autenticação Realizar autenticação Autenticado? Cria credencial. Ir para Autorização Não autenticado? Retorna 401 Unauthorized
Autorização Verificar permissões Autorizado? Retorna recurso pedido Não autorizado? Retorna 403 Forbidden
HTTP
HTTPSHTTPS
HTTPS
Browser
AutenticaçãoAutorização&
na
EJB ContainerWeb Container
Contexto Web - Credenciais Principal: kusko Roles: {"outro"}
Servlet chama metodo 1 em EJB try { b.getFigura1();} catch (EJBAccessException e) { return "acessonegado.png"; }
Servlet chama metodo 2 em EJB try { b.getFigura2();} catch (EJBAccessException e) { return "acessonegado.png"; }
Contexto EJB (propagados) Principal: kusko Roles: {"outro"}
Autorização
@RolesAllowed("**") public String getFigura1() { return "peixinho.png"; }
@RolesAllowed("amigo") public String getFigura2() { return "lupita.png"; }EJBAccessException
Retornar link
Req2
Res2
Browser
Autorização na Camada EJB
Conexão HTTP Segura• Pode-se proteger recursos em Java EE configurando a
necessidade do uso de HTTP + camada SSL/TLS • SSL/TLS atua na camada de transporte protegendo contra
principais riscos de transferir dados pela rede • Risco de não saber se outro é quem diz que é: autenticação • Risco da mensagem ser interceptada e alterada: integridade • Risco da mensagem ser interceptada e lida: confidencialidade
• SSL/TLS usa vários mecanismos de criptografia • Hashes • Criptografia de chave pública (assimétrica) • Criptografia de chave secreta (simétrica)
• Também protege camada de mensagensmas apenas durante a conexão
Identity
Principal
Subject Credential
User
Caller
Group
Role
RealmDomain
Digest
CypherKey
Token
CertificateAuthority
Signature
Grant
Policy
KeyStore
Permission
Trust
Hash
Rule
AuthenticationAuthorization
Provider
Module
ContextTrustStore
X.509
Identity
Principal
Subject Credential
User
Caller
Group
Role
RealmDomain
Digest
CypherKey
Token
CertificateAuthority
Signature
Grant
Policy
KeyStore
Permission
Trust
Hash
Rule
AuthenticationAuthorization
Provider
Module
ContextTrustStore
X.509
Identificação• Quem é você? • Segurança depende da identificação dos usuários
(pessoas e sistemas) • Um nome, um avatar, um endereço IP, um token, ...
• Como saber se é autêntico?
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
58:87:52:44:D8:60:12:B0: FB:D5:F6:C0:6E:F1:6E:FC: A2:0E:15:8D:58:E9:6E:6F: 76:CE:DA:66:60:B5:9B:C2
^63$t+p@55w0rd#
Autenticação• Como provar que você é mesmo você?
• Apresente credenciais: algo que você tem (ex: documento), é (ex: biometria) ou sabe (ex: senha)
• Autenticidade depende de • Parecer dado por uma autoridade de confiança • Integridade das informações: garantia que os dados
transmitidos não foram alterados pelo caminho)
Realm (~reino, domínio)
• Autoridade que administra usuários e grupos e que determina escopo de políticas de segurança (ex: LDAP, banco de dados, banco de certificados)
• Também chamado de:
• Java EE utiliza apenas o nome do realm (para selecionar o escopo da autenticação via HTTP)
zonedomain
region
security providerlogin module
identity manager
auth provider
authenticatoridentity provider auth store
auth repository
identity store
Usuários (pessoas, máquinas, sistemas)
• A criação e autenticação de usuários não faz parte da especificação Java EE • Isto é responsabilidade do realm (que é configurado usando
ferramentas proprietárias - diferente para cada servidor) • Java EE apenas padroniza a escolha do método de
autenticação em um realm (se através de cabeçalhos HTTP, troca de certificados, sessão, etc.)
• Java EE não trabalha com usuários, mas com principals
marvinspock masha vini kusko cerebro niquel
Principal
• Representa uma entidade autenticada • java.security.Principal
• Contém sua identificação (nome / certificado) verificada através de credenciais
• Tem foco diferente em Java SE e Java EE • Em Java SE (JAAS) um Subject representa um usuário,
que pode ter uma coleção de identidades (Principal) • Em APIs Java EE um Principal representa um usuário,
que pode assumir uma coleção de papéis (Roles)
Autenticação em Java EE• Java EE oferece duas alternativas (excludentes) de configuração
• API declarativa na camada Web para selecionar o realm e o método de autenticação (BASIC, FORM, DIGEST, CLIENT)
• API programática (JASPIC) para criar módulos de autenticação • A realização da autenticação é dependente de fabricante
• Maioria oferece APIs e ferramentas proprietárias baseadas em JAAS
JASPIC (JSR 196) javax.security.auth.message
JAASjava.security.auth
HttpServletRequest
HttpServletResponse
<login-config> <auth-method> BASIC </auth-method> <realm-name> jdbc-realm </realm-name> </login-config>
web.xml
CamadaWeb
BASIC (RFC 2069 / 2617)
<login-config> <auth-method>BASIC</auth-method> <realm-name>jdbc-realm</realm-name> </login-config>
401 Unauthorized WWW-Authenticate: Basic realm="jdbc-realm"
GET /app/secret Authorization: Basic bWFzaGE6MTIzNDU=
Para fazer logout: feche o browser!
Credenciais: encoding Base64
configuraçãoweb.xml
GET /app/secret
200 OK
Servidor WebBrowser
DIGEST (RFC 2069 / 2617)
<login-config> <auth-method>DIGEST</auth-method> <realm-name>jdbc-realm</realm-name> </login-config>
401 Unauthorized WWW-Authenticate: Digest realm="jdbc-realm", qop="auth", nonce="143...064", opaque="DF...5C"
GET /app/secret Authorization: Digest username="masha", realm="jdbc-realm", nonce="143...f89", uri="/app/faces/biblioteca.xhtml", response="2c40...df", opaque="DF...5C", qop=auth, nc=00000001, cnonce="66...948b"
Para fazer logout: feche o browser!
Credenciais: MD5 hash
configuraçãoweb.xml
GET /app/secret
200 OK
Servidor WebBrowser
FORM <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/form.html</form-login-page> <form-error-page>/erro.html</form-error-page> </form-login-config> </login-config>
POST https://localhost:29033/app/faces/j_security_check Referer: https://localhost:29033/app/faces/biblioteca.xhtml Cookie: JSESSIONID=aaab5...b1f6 Authorization:Basic Y2VyZWJybzoxMjM0NQ==
j_username:masha j_password:12345
configuraçãoweb.xml
200 OK Set-Cookie: JSESSIONID=aac...44; Path=/app; Secure; HttpOnly
Para fazer logout: HttpSession#invalidate()
Proteção depende da camada SSL/TLS
GET /app/secret
200 OK
Servidor WebBrowser
<form action="j_security_check" method="POST"> <input type="text" name="j_username"> <input type="password" name="j_password"> <input type="submit"> </form>
Encoding Base64
CLIENT-CERT<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>
Configuração é dependente de plataforma
configuraçãoweb.xml
Servidor WebBrowser
Owner: CN=Helder da Rocha, OU=Argonavis, O=Argonavis, L=Sao Paulo, ST=SP, C=BR Issuer: CN=Helder da Rocha, OU=Argonavis, O=Argonavis, L=Sao Paulo, ST=SP, C=BR Serial number: 156fb994 Valid from: Tue Jul 14 00:28:45 BRT 2015 until: Mon Oct 12 00:28:45 BRT 2015 Certificate fingerprints: MD5: F2:B7:23:7B:61:35:D6:...:27:62:7C SHA1: EC:52:88:9B:4F:63:9D:...:EC:D2:17 SHA256: 2E:35:2B:CF:41:30:...:28:0F:B3
Owner: CN=Self-Signed, OU=Oracle Corporation, O=Glassfish Issuer: CN=Self-Signed, OU=Oracle Corporation, O=Glassfish Serial number: 3E:56:D0:C9 Valid from: Jul 3 00:12:13 BRT 2015 until: Jun 30 00:12:13 BRT 2025 Certificate fingerprints: MD5: F5:A9:21:E3:59:30:E8:...:C3:8C:DE SHA1: BE:F5:1A:C3:8C:DE:68:...:83:72:A4 SHA256: 1E:2D:F1:96:8B:C2:...:C2:C7:6E
GET /app/secret
Recebe certificado do servidor
Envia certificado do cliente
200 OK
JASPIC
javax.security.auth.message.moduleServerAuthModule
javax.servletServletContextListener
javax.security.auth.message.configAuthConfigFactory
javax.security.auth.message.configAuthConfigProvider
contextInitialized()
javax.security.auth.message.configServerAuthConfig
javax.security.auth.message.configServerAuthContext
«create»
«create»
«create»«create»javax.security.auth.message.callbackCallbackHandler
javax.security.auth.message.callbackCallerPrincipalCallback
javax.security.auth.message.callbackGroupPrincipalCallback
validateRequest()
handle()
Web Container
authenticate Auth Service
JSR 196
«create»
«create»
initialize()
validateRequest()
registerConfigProvider()
«create»
HTTPrequest
Register Principal and Groups
* *
*
*
*
*
* Must create implementations of these classes/interfaces
Autenticação via HttpServletRequest
• API programática (facilita a criação de filtros) • getAuthType(): String
• Retorna string com mecanismo de autenticação (BASIC, DIGEST, FORM, CLIENT-CERT) ou null
• authenticate(HttpServletResponse response) • Autenticar usando mecanismo configurado
• login(String nome, String senha) • Autenticar usando login e senha
• logout() • Faz com que getRemoteUser(), getCallerPrincipal() e
getAuthType() retorne null
Autenticação com JAX-WS• Propriedades padrão JAX-WS para enviar credenciais via
mensagens SOAP em javax.xml.ws.BindingProviderDungeonWebService service = new DungeonWebService(); Dungeon port = service.getDungeonPort();
BindingProvider bp = (BindingProvider)port; bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://localhost:29033:/app/dungeon");
bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, "masha"); bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, "12345"); String secret = port.secretMessage();
@WebService(serviceName = "dungeon") public class DungeonWebService { @Resource WebServiceContext ctx; @WebMethod public String secretMessage() { MessageContext mctx = ctx.getMessageContext(); String user = mctx.get(BindingProvider.USERNAME_PROPERTY); String pass = mctx.get(BindingProvider.PASSWORD_PROPERTY);
Cliente
Serviço
WebSockets Seguro
HTTP
HTTP
http://localhost/app/inseguro
https://localhost/app/seguro
401 Unauthorized
SSL
(JavaScript) new WebSocket( ws://localhost/app/endpoint )
new WebSocket( wss://localhost/app/endpoint )
SecurityError
new WebSocket( ws://localhost/app/endpoint )
new WebSocket( wss://localhost/app/endpoint )
(JavaScript)
WebSocket estabelecido
WebSocket estabelecido
Identity
Principal
Subject Credential
User
Caller
Group
Role
RealmDomain
Digest
CypherKey
Token
CertificateAuthority
Signature
Grant
Policy
KeyStore
Permission
Trust
Hash
Rule
AuthenticationAuthorization
Provider
Module
ContextTrustStore
X.509
Autorização• Como controlar o acesso
a recursos protegidos? • Quem pode acessar? • Quais recursos? URLs, componentes, classes, métodos,
blocos de código, tabelas, registros, fragmentos de XML, imagens, arquivos, pastas, aplicações
• Que ações podem executar? GET, POST, ler, gravar, criar, remover
• Quais condições? "das 9 as 17h", "enquanto houver tokens", "apenas duas vezes"
Este tipo de controle de acesso não existe em Java EE 7
Grupos (~coleções de usuários no servidor)
• Usuários podem pertencer a grupos• Mas usuários não fazem parte do escopo do
Java EE, e grupos também não • Conceito é dependente de plataforma
marvinspock
alienigenas
masha vini kusko
cerebro niquel
terraqueos
cerebro niquel
ratos
cerebro
megalomaniacos
marvin
masha
masha
russos
masha vini
Grupos criados para aplicação exemplo no
Glassfish 4.1
Roles (~chaves de acesso a recursos protegidos)
• Principals (grupos e usuários) devem ser mapeados a roles• Mapeamento é proprietário: Não há padrão em Java EE • Definição de grupos, roles, realms, etc. varia entre fornecedores
role: administrador - grupo alienigenas - usuário cerebro
role: especial - usuário vini - usuário masha
role: amigo - usuário vini - usuário masha - usuário niquel
role: outro- usuário kusko
alienigenas
Exemplo de mapeamentos possíveis em Glassfish 4.1 <glassfish-web-app> <context-root>JavaEESecurity</context-root>
<security-role-mapping> <role-name>administrador</role-name> <principal-name>cerebro</principal-name> <group-name>alienigenas</group-name> </security-role-mapping>
<security-role-mapping> <role-name>especial</role-name> <principal-name>vini</principal-name> <principal-name>masha</principal-name> </security-role-mapping>
<security-role-mapping> <role-name>amigo</role-name> <principal-name>masha</principal-name> <principal-name>vini</principal-name> <principal-name>niquel</principal-name> </security-role-mapping>
<security-role-mapping> <role-name>outro</role-name> <principal-name>kusko</principal-name> </security-role-mapping> </glassfish-web-app> /WEB-INF/glassfish-web.xmlAplicação: JavaEESecurity.war (veja código-fonte)
java.securityPermission
Autorização em Java EE
JACC (JSR 115)
• Baseada em roles, fácil de usar e 100% Java EE* • Configuração declarativa via anotações e deployment
descriptor XML, ou através de API programática (JACC) • Acesso (leitura) através APIs programáticas em
contextos de segurança
<method-permission> <role-name>...</role-name> <method> <ejb-name>...</ejb-name> <method-name>...</method-name> </method> </method-permission>
<security-constraint> <web-resource-collection> ... </web-resource-collection> <auth-constraint> <role-name>...</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>...</transport-guarantee> </user-data-constraint> </security-constraint>
ejb-jar.xml
Cama
da EJ
B
* depois de mapeados grupos/usuários a roles
javax.security.jaccEJBMethodPermission
javax.security.jaccWebResourcePermission
javax.security.jaccWebUserDataPermission
javax.security.jaccWebRoleRefPermission
javax.security.jaccEJBRoleRefPermission
Cama
da W
eb web.xml
Deployment descriptorsAnotações
@ServletSecurity( @HttpConstraint( transportGuarantee = ..., rolesAllowed = {...} ) ) public class MyServlet... {...}
@RolesAllowed({...}) public class Bean {... @DenyAll public void m1() {} @PermitAll public void m2() {}
Autorização em web.xml• É preciso declarar os roles no web.xml usando
<security-role> (em servlets pode ser via anotações). • Mapeamento dos roles com usuários/grupos é
dependente de servidor (glassfish-web.xml, jboss-web.xml, etc.)
<web-app> ... <security-role> <role-name>administrador</role-name> </security-role>
<security-role> <role-name>amigo</role-name> </security-role> <security-role> <role-name>especial</role-name> </security-role> ... </web-app>
Security constraints• Bloco <security-constraint> contém três partes
• Um ou mais <web-resource-collection> • Pode conter um <auth-constraint> (lista de roles) • Pode conter um <user-data-constraint> (SSL/TLS)
<security-constraint> <web-resource-collection> <web-resource-name>Área restrita</web-resource-name> <url-pattern>/secreto/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>administrador</role-name> </auth-constraint> </security-constraint>
Web resource collection• Agrupa recursos e operações controladas através de
padrões de URL + métodos HTTP • Métodos HTTP não informados são restritos, mas métodos
não informados estão descobertos • Use <deny-uncovered-http-methods/> ou outro bloco
negando acesso a todos exceto <http-method-omission>
<security-constraint> <web-resource-collection> <web-resource-name>Área restrita</web-resource-name> <url-pattern>/secreto/*</url-pattern> <url-pattern>/faces/castelo.xhtml</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> ... </security-constraint>
Authorization constraint• Com <auth-constraint> as <web-resource-collection>
são acessíveis apenas aos <role-name> declarados • Sem <auth-constraint>: sem controle de acesso (livre) • <auth-constraint /> vazio: ninguém tem acesso
<web-app> ... <security-constraint> <web-resource-collection> ... </web-resource-collection> <web-resource-collection> ... </web-resource-collection> <auth-constraint> <role-name>administrador</role-name> <role-name>especial</role-name> </auth-constraint> </security-constraint> ... <security-constraint> ....</security-constraint> </web-app>
Transport guarantee• Garantias mínimas para comunicação segura SSL/TLS
• NONE: (ou ausente) não garante comunicação segura • INTEGRAL: proteção integral, autenticação no servidor • CONFIDENTIAL: proteção integral, autenticação: cliente e servidor
<web-app> ... <security-constraint> ... <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint>
... <user-data-constraint> <transport-guarantee>INTEGRAL</transport-guarantee> </user-data-constraint> </security-constraint> </web-app>
Servlet 3.x @ServletSecurity@WebServlet(name = "ServletSecreto", urlPatterns = {"/secreto"}) @ServletSecurity( @HttpConstraint( transportGuarantee = TransportGuarantee.CONFIDENTIAL, rolesAllowed = {"amigo", "administrador"} ) ) public class ServletSecreto extends HttpServlet { ... }
@WebServlet(name = "LabirintoServlet", urlPatterns = {"/labirinto"}) @ServletSecurity(httpMethodConstraints={ @HttpMethodConstraint("GET"), @HttpMethodConstraint(value="POST", rolesAllowed={"outro"}), @HttpMethodConstraint( value="TRACE", transportGuarantee = TransportGuarantee.NONE, rolesAllowed = {"amigo", "administrador"} ) }) public class LabirintoServlet extends HttpServlet { ... }
Autorização com HTTPServletRequest• Acesso via API a principal e roles permitem controle
programático da autorização • getUserPrincipal()
• Obtém java.security.Principal (getName() obtém nome) • isUserInRole("role")
• Testa se o usuário autenticado faz parte do role
String loggedUser = request.getUserPrincipal().getName();
if( !request.isCallerInRole("administrador")) { if (!loggedUser.equals("cerebro")) { throw new SecurityException("..."); } }
Autorização em JSF e CDI• Através de request
<h:panelGroup rendered="#{request.userPrincipal == 'masha'}"> <p>Conteúdo visto pelo usuário masha</p> </h:panelGroup> <h:panelGroup rendered="#{request.isUserInRole('especial')}"> <p>Conteúdo visto por quem possui o role especial</p> </h:panelGroup>
• No Managed Bean pode-se usar ExternalContext ExternalContext ctx = FacesContext.getCurrentInstance().getExternalContext();
boolean inRole = ctx.isUserInRole("role");String user = ctx.getUserPrincipal().getName();
• Ou injetar o Principal via CDI @Inject java.security.Principal;
Autorização em WebSockets
• Contexto de segurança em javax.websocket.Session retorna apenas o java.security.Principal
• É possível redefinir o WebSocket Handshake para passar outros dados de contexto via HttpServletRequest
@ServerEndpoint("/secretpoint") public class SecretEndPoint { @OnMessage public void onMessage(String message, Session session) { String user = session.getUserPrincipal().getName(); ... } }
Autorização em EJB@DeclareRoles({"amigo", "administrador"})@Stateless public class ImagemBean { @RolesAllowed("administrador") public void removerUsuario(Usuario u) { ... }
@RolesAllowed("amigo") public List<Usuario> listaDeUsuarios() { ... }
@PermitAll public String getInfo() { ... }
@RolesAllowed("**") public String getFreeStuff() { ... }
@DenyAll public String loggingData() { ... } }
Segurança em ejb-jar.xml• Raramente usado por desenvolvedores (já que toda a
segurança pode ser configurada por anotações)<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" ... > <enterprise-beans> <session> <ejb-name>testeBean</ejb-name> <ejb-class>testebean.TesteBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> <assembly-descriptor> <security-role> <role-name>administrador</role-name> </security-role> <method-permission> <role-name>administrador</role-name> <method> <ejb-name>testeBean</ejb-name> <method-name>*</method-name> </method> </method-permission> ... </assembly-descriptor> </ejb-jar>
Propagação de identidade• @RunAs("role")
• Declarado antes da declaração de classe permite que o componente execute usando um role específico
• Permite que componente tenha um role mesmo que não tenha sido propagado pelo container cliente
@MessageDriven @RunAs("administrador") public class TestEJB { ... }
<message-driven> <ejb-name>TestEJB</ejb-name> <ejb-class>br.com.ejb.examples.TestEJB</ejb-class> <security-identity> <run-as> <role-name>administrador</role-name> </run-as> </security-identity> </message-driven>
O container confia na identidade
propagada (não autentica de novo)
Autorização com EJBContext• Métodos de javax.ejb.EJBContext
• Herdados por SessionContext e MessageDrivenContext • Mesmos métodos, mas com nomes diferentes
• Caller no contexto EJB é o User no contexto Web
String loggedUser = ctx.getCallerPrincipal().getName();
if( !ctx.isCallerInRole("administrador")) { if (!loggedUser.equals("cerebro")) { throw new EJBAccessException("..."); } }
Autorização em JAX-RS• Resources são EJBs, portanto podem usar
mesmos mecanismos de autorização declarativos@Stateless @Path("usuario") @RunAs("administrador") public class UsuarioFacadeREST { @DenyAll @POST @Consumes({"application/xml", "application/json"}) public void create(Usuario entity) { ... }
@RolesAllowed({"administrador"}) @PUT @Path("{id}") @Consumes({"application/xml", "application/json"}) public void edit(@PathParam("id") Integer id, Usuario entity) { ... } ... }
API de segurança em JAX-RS• Aproveita mesmo ambiente do contexto Web • Métodos de javax.ws.rs.core.SecurityContext • getAuthenticationScheme()
• Retorna o string contendo o esquema de autenticação (mesmo que HttpServletRequest#getAuthType())
• isSecure() • Retorna true se a requisição foi feita em canal seguro
• getUserPrincipal() • Retorna java.security.Principal com usuário autenticado
• isUserInRole(String role) • Retorna true se usuário autenticado pertence ao role
API de segurança em JAX-WS
• Mecanismos declarativos de autorização aproveitam a estrutura do contexto Web (<security-constraint>)
• API programática de segurança mínima em javax.xml.ws.WebServiceContext • getUserPrincipal()
• isUserInRole("role")
• Suporte a criptografia na camada de mensagens (ainda) não faz parte do Java EE
Como obter principals e testar roles
javax.servlet.http.HttpServletRequest
getUserPrincipal()isUserInRole()
WebServlets,Facelets, WebFilters
javax.faces.context. ExternalContext
getUserPrincipal()isUserInRole()
JSF backing beans
javax.ejb.EJBContext
getCallerPrincipal()isCallerInRole()
EJBs
javax.websocket. Session
getUserPrincipal()WebSockets
javax.ws.rs.core. SecurityContext
getUserPrincipal()isUserInRole()
RESTful Web Services
javax.xml.ws.WebServiceContext
getUserPrincipal()isUserInRole()
SOAP Web Services
em Java EE 7
CDI
@Inject java.security.Principal
O que falta em Java EE?• Ter uma API padrão de segurança moderna, unificada e
independente de fabricante • Segurança Java EE hoje, na prática, usa recursos proprietários ou
frameworks de terceiros (Spring, etc.) • O que mais?
• Terminologia comum (callers/users, groups/roles, identity store) • Contexto de segurança acessível de qualquer componente • Mecanismo de autenticação mais flexível , independente de servidor
e com implementações padrão • APIs padronizadas para identity stores (não depender de realms
proprietários) • Formas de controlar acesso além de roles (regras, interceptadores)
• Como será o futuro da segurança em Java EE?
To be continued...Hoje, 17:40
Referências (1/3)Documentação oficial
• Eric Jendrock et al. The Java EE 7 Tutorial, Release 7 (Oracle, September 2014). http://docs.oracle.com/javaee/7/tutorial/ O capítulo 50 contém um tutorial sobre Segurança em Java EE com Glassfish (os exemplos e as configurações funcionam apenas no Glassfish).
• Oracle. Java SE Security. http://www.oracle.com/technetwork/java/javase/jaas/index.html Uma visão geral das APIs Java SE de segurança.
• Oracle. JAAS Authentication tutorial. http://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/tutorials/GeneralAcnOnly.html
• Oracle. JAAS Authorization tutorial. http://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/tutorials/GeneralAcnAndAzn.html
• Oracle. Java Security Overview. http://docs.oracle.com/javase/8/docs/technotes/guides/security/overview/jsoverview.html
Java EE 8• Alex Kosowski. Finally EE Security API JSR 375. Devoxx France 2015.
http://pt.slideshare.net/a_kosowski/devoxx-fr-ee8jsr375securityapiv1 • JSR 375 Java EE Security API. https://www.jcp.org/en/jsr/detail?id=375
Página do JSR aberto em dezembro 2014.
Referências (2/3)Especificações Java EE http://www.oracle.com/technetwork/java/javaee/tech/index.html
• Ron Monzillo. Java Authentication SPI for Containers JSR 196, Version 1.1, Oracle, 2013 • Ron Monzillo. Java Authorization Contract for Containers JSR 115, Version 1.5, Oracle, 2013 • Shing Wai Chan e Rajiv Mordani. Java Servlet Specification, Version 3.1, Chapter 13: Security,
Oracle, 2013 • Marina Vatkina. JSR 345 Enterprise JavaBeans, Version 3.2. EJBCore Contracts and Requirements.
Chapter 12 Security Management. Oracle, 2013. • Danny Coward. Java API for WebSocket. Version 1.0. Chapter 8: Server Security. Oracle, 2013 • Jitendra Kotamraju. WebServices for Java EE, Version 1.3. Chapter 9: Security. Sun, 2009. • Jitendra Kotamraju. The Java API for XML-Based Web Services (JAX-WS) 2.2 Rev. a. Section 4.2.2.1
(Standard properties). Oracle, 2011. • Santiago Pericas-Geertsen e Marek Potociar. JAX-RS: Java API for RESTful Web Services. Version
2.0. Section 9.2.5 Security Context. Oracle, 2013 • Pete Muir et al. Contexts and Dependency Injection for Java EE, Version 1.1. Section 3.8 (Additional
built-in beans). Oracle, 2013.
Livros• Arun Gupta. Java EE 7 Essentials O'Reilly, 2013.
Código-fonte com vários exemplos usando recursos de segurança em Java EE 7: https://github.com/javaee-samples/javaee7-samples
Referências (3/3)Artigos e apresentações sobre Java EE 7
• Marian Muller. “Please Log In”: Authentication and Authorization in Java SE and Java EE. JavaONE 2013. https://www.youtube.com/watch?v=pBDqIavwMYwTutorial (video) sobre recursos de segurança em Java SE e Java EE, cobrindo JAAS e JASPIC.
• Arjan Tijms. Implementing container authentication in Java EE with JASPIC Nov/2012. http://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.htmlTutorial abrangente sobre JASPIC 1.0 (veja também posts do autor sobre JACC).
• Ron Monzillo. Using JACC to determine a caller's roles. Ron Monzillo's Weblog. Aug 18 2008. https://blogs.oracle.com/monzillo/entry/using_jacc_to_determine_a Aplicações práticas de alguns recursos da API JACC.
• Ron Monzillo. Adding Authentication Mechanisms to the GlassFish Servlet Container. Ron Monzillo's Weblog. Apr 30, 2008. https://blogs.oracle.com/enterprisetechtips/entry/adding_authentication_mechanisms_to_the Um tutorial de JASPIC.
Produtos, extensões e alternativas• Bauke Sholtz. Apache Shiro. Is it ready for Java EE 6? The BalusC Code, Janeiro/2013.
http://balusc.blogspot.com.br/2013/01/apache-shiro-is-it-ready-for-java-ee-6.html • Social Auth. https://code.google.com/p/socialauth/
Ferramenta de extensão para autenticação usando CAS, OAuth, OpenID. • Seam Security. http://docs.jboss.org/seam/3/security/latest/reference/en-US/html_single/
Alternativa à segurança padrão Java EE. • Spring Security. http://projects.spring.io/spring-security/
Alternativa à segurança padrão Java EE.
2015
https://github.com/argonavisbr/JavaEE7SecurityExamples
http://www.argonavis.com.br/download/tdc_2015_javaee7security.htmlPalestra
Código-fonte