Este documento discute segurança em Java EE, abordando mecanismos de autenticação e autorização padrão, como Basic, Digest e client certificates, e como aplicá-los em componentes como Servlets, EJBs e serviços web.
1. JavaEE7JaJa
S E G U R A N Ç A
helderdarocha helder@argonavis.com.br
Julho/2015
JaJa
2. Conteúdo
1. 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 EE
Alternativas 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ências
O que falta? Alternativas à segurança Java EE
JSR 375 (outra palestra!)
3. 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
4. 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.
5. 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, ...)
6. Autenticação
e Autorização
Policy / Security Manager
JAAS
JarSigner TSA/TSP (RFC 3161)
Comunicação
Segura
JSSE (SSL/TLS)
SASL (RFC 2222)
GSS-API (RFC 2853)
Criptografia
JCA
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 collection
Bytecode verification
Data-typing
Segurança nativa da
Plataforma Java
+
Mecanismos de segurança
Java SE 8
7. Mensagem
Mensagem
Role
Principal
Role
userid
pass / cert
CamadadeAplicações
CamadadeAplicações
Camada de Transportes
Autenticação
Mensagem
Conexão
Segura
SSL/TLS
Conexão
Insegura
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ça
Java EE 7
8. 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
HTTPS
HTTPS
HTTPS
Browser
Autenticação
Autorização&
na
9. 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
10. 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 mensagens
mas apenas durante a conexão
13. 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#
14. 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)
15. 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)
zone
domain
region
security provider
login module
identity manager
auth provider
authenticator
identity provider
auth store
auth repository
identity store
16. 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
17. 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)
18. 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
JAAS
java.security.auth
HttpServletRequest
HttpServletResponse
<login-config>
<auth-method>
BASIC
</auth-method>
<realm-name>
jdbc-realm
</realm-name>
</login-config>
web.xml
Camada
Web
19. 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ção
web.xml
GET /app/secret
200 OK
Servidor WebBrowser
20. 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ção
web.xml
GET /app/secret
200 OK
Servidor WebBrowser
24. 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
25. Autenticação com JAX-WS
• Propriedades padrão JAX-WS para enviar credenciais via
mensagens SOAP em javax.xml.ws.BindingProvider
DungeonWebService 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
28. 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
29. 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
30. 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)
31. java.security
Permission
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
CamadaEJB
* depois de mapeados grupos/usuários a roles
javax.security.jacc
EJBMethodPermission
javax.security.jacc
WebResourcePermission
javax.security.jacc
WebUserDataPermission
javax.security.jacc
WebRoleRefPermission
javax.security.jacc
EJBRoleRefPermission
CamadaWeb
web.xml
Deployment descriptorsAnotações
@ServletSecurity(
@HttpConstraint(
transportGuarantee = ...,
rolesAllowed = {...}
)
)
public class MyServlet... {...}
@RolesAllowed({...})
public class Bean {...
@DenyAll
public void m1() {}
@PermitAll
public void m2() {}
32. 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>
33. 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>
34. 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>
35. 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>
36. 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>
38. 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("...");
}
}
39. 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;
40. 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();
...
}
}
41. 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() { ... }
}
42. 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>
43. 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)
44. 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("...");
}
}
45. 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) { ...
} ...
}
46. 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
47. 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
48. 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
49. 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?
51. 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.
52. 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
53. 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=pBDqIavwMYw
Tutorial (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.html
Tutorial 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.