Helder da Rocha, profile picture
Carregado porHelder da Rocha
PDF, PPTX4,952 visualizações

JSR 375 Segurança em Java EE 8

O documento discute as propostas para o JSR-375, que visa modernizar e simplificar a API de segurança do Java EE. As principais idéias incluem: 1) introduzir uma terminologia unificada; 2) simplificar a API de autenticação; e 3) fornecer uma API padronizada para armazenamento de identidades.

Incorporar apresentação

Transferir como PDF, PPTX
helderdarocha helder@argonavis.com.br Julho/2015 JSR 375 O futuro da segurança em Java EE 8
Objetivos Discutir os problemas que existem na API padrão de segurança do Java EE atual Apresentar as idéias que estão sendo discutidas sobre o JSR-375: API de Segurança do Java EE 8
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
A API padrão de segurança do 
 Java EE 
 é muito complexa?
Java EE 8 Community Survey O que deve ser priorizado? Fonte: Java EE 8 Community Survey
Java EE 8 Community Survey O que deve ser priorizado? 2˚ Fonte: Java EE 8 Community Survey
Java EE 8 Community Survey O que deve ser priorizado? 2˚ Security Simplification 11.1% Fonte: Java EE 8 Community Survey
Quais são os problemas? • É complexa, confusa, difícil de usar • Redundância desnecessária • Volta aos tempos do J2EE • Precisa ser modernizada • Não suporta OpenID Connect, OAuth, etc • Difícil de usar na nuvem e PaaS
Como mapear usuários no
 Tutorial Java EE 7 Glass
 fish É possível implementar uma solução completa de segurança em Java EE que não dependa de APIs ou configurações proprietárias ou frameworks de terceiros?
Quais são os problemas? • É complexa, confusa, difícil de usar • Redundância desnecessária • Volta aos tempos do J2EE • Precisa ser modernizada • Não suporta OpenID Connect, OAuth, etc • Difícil de usar na nuvem e PaaS • Não existe API padrão Java EE para segurança! • Vendor lock-in com solução do fabricante • Desenvolvedores abandonam Java EE em busca de soluções de terceiros (Spring, Shiro, etc.)
Problemas da segurança Java EE • Necessidade de usar configurações proprietárias • Em ambiente de nuvem/PaaS é problema: desenvolvedores não tem acesso a recursos proprietários - não se adapta ao paradigma do desenvolvedor de apps para a nuvem • API não é portável, é confusa, antiquada • Desenvolvedores migram para frameworks de terceiros já que o padrão não existe
Wild Fly Segurança padrão no Java EE • Vendor lock-in: escolha a sua prisão Web
 Sphere Glass
 fish ?
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
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
?
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?
JSR 375
O que fazer • Resolver problemas de portabilidade • Facilitar a vida do desenvolvedor • Usar defaults e não precisar XML • Configuração independente de servidor • Modernizar • Atender demandas atuais de segurança • Inspiração em frameworks existentes OmniSecurity + ...
Objetivos da JSR-375 "The goal of this JSR is to improve the Java EE platform by ensuring the Security API aspect is useful in the modern cloud/PaaS application paradigm." "This promotes self-contained application portability across all Java EE servers, and promotes use of modern programming concepts such as expression language, and contexts and dependency injection." "This JSR will holistically attempt to simplify, standardize, and modernize the Security API across the platform in areas identified by the community via survey results and submitted JIRA issues."
JSR 375 - Linha do tempo Q3 2014 Expert Group formed NÓS ESTAMOS AQUI (Jul/2015) Q4 2015 Early Draft Q1 2016 Public Review Q3 2016 Proposed Final Draft H1 2017 Final Release
• Baseadas nos resultados finais do Java EE 8 Community Survey • Password aliases Quais as prioridades? Fonte: Java EE 8 Community Survey
• Baseadas nos resultados finais do Java EE 8 Community Survey • Password aliases • API de Autenticação (simplificação do JASPIC) Quais as prioridades? Fonte: Java EE 8 Community Survey
• Baseadas nos resultados finais do Java EE 8 Community Survey • Password aliases • API de autenticação (simplificação do JASPIC) • API para atribuir roles e permissões Quais as prioridades? Fonte: Java EE 8 Community Survey
Fonte: Java EE 8 Community Survey Quais as prioridades? • Baseadas nos resultados finais do Java EE 8 Community Survey • Password aliases • API de autenticação (simplificação do JASPIC) • API para atribuir roles e permissões • Interceptadores de autorização
Quais as prioridades? • Baseadas nos resultados finais do Java EE 8 Community Survey • Password aliases • API de autenticação (simplificação do JASPIC) • API para atribuir roles e permissões • Interceptadores de autorização • API para Identity Store Fonte: Java EE 8 Community Survey
Quais as prioridades? • Resultados finais do Java EE 8 Community Survey • Password aliases • API de autenticação (simplificação do JASPIC) • API para atribuir roles e permissões • Interceptadores de autorização • API para Identity Store • + Simplificar a API • Introduzir um contexto de segurança unificado • Unificar a terminologia
Principais idéias do JSR 375 • Terminologia unificada • API de autenticação • API de identity store • API de password aliasing • API de atribuição de roles e permissões • API de interceptadores de autorização • API de contexto de segurança Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Relacionamentos entre as propostas Identity Store Mecanismo de Autenticação Contexto de Segurança Atribuição de Permissões / Roles Interceptadores de Autorização Aliasing de Senhas Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Onde estamos? (24/jul/2015) https://java.net/projects/javaee-security-spec
Identity Principal Subject Credential User Caller Group Role Realm Domain Digest Cypher Key Token Certificate Authority Signature Grant Policy KeyStore Permission Trust Hash Rule Authentication Authorization Provider Module Context TrustStore X.509 Terminologia
Terminologia • Como se chama a entidade que se autentica? get????Principal() get????InRole()
Terminologia • Como se chama a entidade que se autentica? getUserPrincipal() getUserInRole()
Terminologia • Como se chama a entidade que se autentica? getCallerPrincipal() getCallerInRole()
Terminologia • O que é um grupo? Conjunto de usuários? Uma permissão? ??????
Discussão sobre terminologia • Epic (JIRA) sobre terminologia da API • https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-21 • + em SPECs 1, 2, 3 e 28 • Nas discussões a preferência tem sido maior para "Caller" em vez de "User" para usuário logado (SPEC-2) Fonte: https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-2
Terminologia • Como se chama a coisa que guarda identidades? zone domain region security provider login module identity manager provider authenticator identity provider auth store repository identity store realm authentication repository auth provider
Autenticação ^63$t+p@55w0rd#
Mecanismo de autenticação • Situação: desenvolvedor tem uma aplicação que • Gerencia seus próprios usuários e grupos • Precisa autenticar usuários para atribuir roles • Quer autenticar usando modelos do domínio da aplicação • Precisa usar método não suportado (ex: OpenID Connect) • Solução simples • Vendor lock-in com o fabricante do servidor de aplicações • Framework de terceiros (Spring, Shiro, etc.) • Solução Java EE: ?
Autenticação em Java EE • Java EE oferece duas alternativas (excludentes) de configuração • API declarativa na camada Web para selecionar 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
JAAS Principal != Java EE Principal • O foco é diferente em Java SE e Java EE • Java SE (JAAS): um Subject representa um usuário, que pode ter uma coleção de identidades (Principal) • Java EE: um Principal representa um usuário
 que pode ter uma coleção de permissões (Roles)
JASPIC SAM public interface ServerAuthModule { public void initialize(...) throws AuthException; public AuthStatus validateRequest(...); public Class<?>[] getSupportedMessageTypes(); public AuthStatus secureResponse(...); public void cleanSubject(...); }
JASPIC javax.security.auth.message.module
 ServerAuthModule javax.servlet
 ServletContextListener javax.security.auth.message.config
 AuthConfigFactory javax.security.auth.message.config
 AuthConfigProvider contextInitialized() javax.security.auth.message.config
 ServerAuthConfig javax.security.auth.message.config
 ServerAuthContext «create» «create» «create»«create»javax.security.auth.message.callback
 CallbackHandler javax.security.auth.message.callback
 CallerPrincipalCallback javax.security.auth.message.callback
 GroupPrincipalCallback validateRequest() handle() Web Container authenticate Auth Service JSR 196 «create» «create» initialize() validateRequest() registerConfigProvider() «create» HTTP
 request Register Principal and Groups * * * * * * * Must create implementations of these classes/interfaces
Proposta JSR-375: JASPIC • Por que ninguém usa JASPIC? • Complexo! Tem que programar 6 classes • Ideia: reduzir 5 classes a uma (SAM) • Registrar no ServletContextListener e/ou anotações @Authenticator("org.acme.TokenAuthModule") @WebServlet("/SimpleServlet") @ServletSecurity(@HttpConstraint(rolesAllowed = {"manager"})) public class SimpleServlet extends HttpServlet { • Em vez de implementar toda a interface, usar um Profile • ex: MySAM extends HttpServerAuthModule {} Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Proposta JSR-375: JASPIC • Fornecer autenticadores padrão • Lançar eventos CDI • @PreAuthenticate, @PostAuthenticate
 @PreLogout, @PostLogout • Para contar usuários logados, • Rastrear tentativas de login mal-sucedidas • Criar usuário local depois de autenticação remota • Preferências do usuário, etc. @Authenticator("javax.security.authenticator.OpenIDConnect") @WebServlet("/SimpleServlet") @ServletSecurity(@HttpConstraint(rolesAllowed = {"manager"})) public class SimpleServlet extends HttpServlet { Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Identity Store
Gerência de usuários: hoje • Atualmente não existe suporte padrão para gerenciar usuários em Java EE • Aplicações não tem como criar, remover, atualizar e agrupar usuários em Java EE • Dependência de soluções 
 proprietárias (vendor-lock-in), 
 frameworks de terceiros 
 ou soluções in-house Realm
Proposta JSR-375: Identity Store • Serviço padrão para criar, atualizar, remover, e agrupar usuários • Usa um recurso de usuários • Escopo pode ser limitado à aplicação e/ou compartilhado por outras aplicações • LDAP, arquivos, datasource, embedded, servidor • Poder ser ntercambiável: recurso diferente para desenvolvimento, teste, produção • API poderia informar quais os serviços disponíveis em determinado recurso de usuários.
Primeiro esboço: API de Identity Store public interface IdentityStore { Identity loadIdentityByName(String name); void changePassword(char[] oldPassword, char[] newPassword); void createIdentity(Identity user); void deleteIdentity(String name); void updateIdentity(Identity identity); boolean identityExists(String name); void createGroup(String group); void deleteGroup(String group); void addIdentityToGroup(String name, String group); void removeIdentityFromGroup(String name, String group); boolean isIdentityInGroup(String name, String group); List<String> getIdentityGroups(String name); } public interface Identity { String getUsername(); char[] getPassword(); boolean isAccountExpired(); boolean isAccountLocked(); boolean isPasswordExpired(); boolean isEnabled(); IdentityAttributeValue getAttribute(String name); } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Proposta + recente para Identity Store public interface IdentityStore { // Callers and Groups Caller loadCaller(String loginName); boolean callerExists(String loginName); List<Caller> getCallers(String regEx); boolean groupExists(String name); List<String> getGroups(String regEx); boolean isCallerInGroup(String callerLoginName, String groupName); List<Caller> getCallersInGroup(String group); List<String> getCallerGroups(String callerLoginName); List<String> getCallerGroups(Caller caller); // Credentials CredentialValidationResult validateCredentials(Credentials credentials); // Role Mapping boolean roleExists(String name); enum RoleSetSelector {ALL, ASSIGNED, UNASSIGNED} List<String> getRoles(String regEx, RoleSetSelector roleSet); // Roles mapped to Caller // boolean callerHasRole(String loginName, String role); boolean callerHasRole(Caller caller, String role); List<Caller> getCallersWithRole(String role); List<String> getRolesForCaller(String loginName); List<String> getRolesForCaller(Caller caller); // Roles mapped to Group // boolean groupHasRole(String groupName, String role); List<String> getGroupsWithRole(String role); List<String> getRolesForGroup(String groupName); } public class Caller { private String loginName; public String getLoginName() { return loginName; } public void setLoginName(String loginName) { this.loginName = loginName; } } Fonte: 
 https://github.com/javaee-security-spec/javaee-security-proposals
 Jun 08 2015 Baseada em PicketLink (picketlink.org)
Identity Store: implementação Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015 Identity IdentityStore LDAP BD Arquivo Servidor Embedded
Identity store: idéias de como usar • Como embutir um Identity Store na própria aplicação @EmbeddedIdentityStore(name="java:app/devIdentityStore",
 {
 @Identity(username="ray", password="secret", groups="admin"),
 @Identity(username="jo", password="secret", groups="user"),
 @Identity(username="sam", password="secret", groups="user")
 }) • Identity Store em banco de dados relacional @DatabaseIdentityStore(
 name="java:app/testIdentityStore",
 lookup="somedatabase",
 userQuery="SELECT passwd FROM principals WHERE userid=?",
 groupQuery="SELECT group FROM groups where username=?", ...) Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Password aliasing 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
Password Aliasing • Atualmente não há suporte padrão para referenciar e guardar uma senha (para acessar recursos) de forma segura em Java EE • Aplicações precisam de uma senha assim, por exemplo, para acessar recursos de bancos de dados, em um persistence.xml • Soluções são in-house ou usando ferramentas de terceiros
Proposta JSR-375: Password Aliasing • Sintaxe padrão para indicar um alias de senha, e um meio para resolver o alias para um valor de senha • Repositório seguro que poderia ser mantido com a aplicação <data-source> <name>java:app/env/testDS</name> <user>APP</user> <password>${ALIAS=token}</password> ... </data-source> @DataSourceDefinition( name="java:app/jdbc/test", user="root", password="${ALIAS=token}", ...) Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015 ${ALIAS=a#6W@+2&3_} "senha"
Autorização e role-mapping
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() {}
Role Mapping em Java EE • Atualmente não há suporte padrão a mapeamento de roles em Java EE • Soluções implicam em vendor lock-in ou uso de APIs de terceiros <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>
Proposta JSR-375: Role Mapping • Serviço de roles padronizado que permite que a aplicação realize operações de mapeamento de roles • granting, pesquisa, para roles de usuários e grupos • Serviço manipularia mapeamentos de um role mapper (pode ser embedded, JDBC, LDAP, etc.) @EmbeddedRoleMapper( users={ @RoleMap(user=“foo”,roles=“admin”), @RoleMap(group=“admin”,roles={“admin”,”manager”}) } ) public class MyServlet { } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Role Mapper dinâmico public interface RoleMapper { void grantRoleToUser(String username, String role); void revokeRoleFromUser(String username, String role); boolean hasRoleForUser(String username, String role, boolean includeGroups); List<String> getRolesForUser(String username, boolean includeGroups); List<String> getUsersWithRole(String role, boolean includeGroups); void grantRoleToGroup(String group, String role); void revokeRoleFromGroup(String group, String role); boolean hasRoleForGroup(String group, String role); List<String> getRolesForGroup(String group); List<String> getGroupsWithRole(String role); } @Inject RoleMapper roleMapper; roleMapper.grantRoleToGroup("Manager", "EDIT_ACCOUNTS"); boolean has = roleMapper.hasRoleForGroup("Manager", "CLOSE_ACCT"); List<String> roles = roleMapper.getRolesForGroup("Manager"); List<String> groups = roleMapper.getGroupsWithRole("VIEW_ACCOUNTS"); Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Limitações da autorização • Atualmente Java EE apenas suporta autorização por permissões (roles) • Não há suporte padrão para incluir regras do domínio da aplicação na decisão de autorização • Soluções são in-house ou proprietárias
Proposta JSR-375: interceptadores • Anotação padrão de interceptador para métodos, capaz de incluir regras que seriam usadas na autorização • Seria chamada se forma similar a @AroundInvoke • As regras teriam acesso ao contexto atual • Regras poderiam ser baseadas em texto (como Java EL) • Suporte a eventos CDI como parte do processo de decisão @LdapAuthorizationRules ( name="java:app/accountAuthRules", ldapUrl="ldap://blah", ldapUser="ElDap", ldapPassword=“mysecret” )
 public class MyBean { 
 @ EvaluateSecured(ruleSourceName="java:app/accountAuthRules", 
 rule="transferFunds")
 void transferFunds() {..}; } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Contexto de 
 segurança
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
Proposta JSR-375: 
 contexto de segurança • Deveria haver apenas um contexto de segurança que pudesse ser obtido por qualquer componente Java EE public class MyFutureCdiBean { @Inject private SecurityContext securityContext; public String sayHello() { if (securityContext.isUserInRole("admin")) { return "Hello World!"; } throw new SecurityException("User is unauthorized."); } } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Exemplo (idéia) public interface SecurityContext { String getUserPrincipal(); boolean isUserInRole(String role); List<String> getAllUsersRoles(); boolean isAuthenticated(); boolean isUserInAnyRole(List<String> roles); boolean isUserInAllRoles(List<String> roles); void login(Object request, Object response); void login(Map map); void logout(); void runAs(String role); boolean hasAccessToResource(); boolean hasAccessToBeanMethod(); } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
Conclusões • Java EE não tem uma API de segurança padrão independente de plataforma, moderna e fácil de usar • Java EE 8 pode ser que tenha - essa é a meta do JSR-375 • Se você tem interesse, envolva-se! • Como se envolver • Página do projeto: 
 https://java.net/projects/javaee-security-spec • Lista de discussões:
 users@javaee-security-spec.java.net • Playground no GitHub (faça fork e explore):
 https://github.com/javaee-security-spec/javaee-security-proposals
Referências • Página da JSR-375 • https://www.jcp.org/en/jsr/detail?id=375 • Discussões do JIRA do JSR-375 e listas de e-mail • https://java.net/jira/browse/JAVAEE_SECURITY_SPEC • https://java.net/projects/javaee-security-spec/lists • Artigos de Arjan Tijms sobre JASPIC e JAAC • arjan-tijms.omnifaces.org • Palestra do spec lead Alex Kosowski no DevoXX France (Abril 2015)
obrigado! helder@argonavis.com.br 2015 https://github.com/argonavisbr/JavaEE7SecurityExamples http://www.argonavis.com.br/download/tdc2015_javaee8_security.html Palestra Código-fonte (Experimentos com JASPIC e JACC)

Mais conteúdo relacionado

PDF
Visão geral da segurança em Java EE
porHelder da Rocha
 
PDF
JavaOne 2015 - Simplificando a segurança de sua aplicação com Java EE
porLeonardo Zanivan
 
PDF
TDC 2016 - Simplificando a segurança de sua aplicação com Java EE
porLeonardo Zanivan
 
PPTX
Workshop05
porPhilippe Guillaume, MBA,CISSP, COBIT
 
PPTX
DevSecOps - Segurança em um pipeline contínuo
porEndrigo Antonini
 
PPTX
AppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEE
porMagno Logan
 
PPTX
Desenvolvimento de Software Seguro
porAugusto Lüdtke
 
PPT
Tratando as vulnerabilidades do Top 10 do OWASP by Wagner Elias
porMagno Logan
 
Visão geral da segurança em Java EE
porHelder da Rocha
 
JavaOne 2015 - Simplificando a segurança de sua aplicação com Java EE
porLeonardo Zanivan
 
TDC 2016 - Simplificando a segurança de sua aplicação com Java EE
porLeonardo Zanivan
 
Workshop05
porPhilippe Guillaume, MBA,CISSP, COBIT
 
DevSecOps - Segurança em um pipeline contínuo
porEndrigo Antonini
 
AppSec Latam 2011 - Treinamento OWASP Top 10 + JavaEE
porMagno Logan
 
Desenvolvimento de Software Seguro
porAugusto Lüdtke
 
Tratando as vulnerabilidades do Top 10 do OWASP by Wagner Elias
porMagno Logan
 

Mais procurados

PPTX
Java security
porarmeniocardoso
 
PPTX
Engenharia de Software II - Teste de segurança de software
porJuliano Padilha
 
PPTX
Dica 02 - Como mitigar os ataques de SQL Injection em aplicações WEB
porAlcyon Ferreira de Souza Junior, MSc
 
PDF
Segurança em Aplicações Web conforme OWASP
porFabiano Pereira
 
PDF
Minicurso de Segurança em Java EE 7
porHelder da Rocha
 
PDF
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações
porClavis Segurança da Informação
 
PPT
Testes de Segurança de Software (tech-ed 2008)
porConviso Application Security
 
PPT
Jaas apresentado
porBruno Taboada
 
PPTX
Aula 03 - Curso GRATUITO EAD de Desenvolvimento Seguro de Software com Alcyon...
porAlcyon Ferreira de Souza Junior, MSc
 
PDF
Testes de segurança em aplicações web
porSynergia - Engenharia de Software e Sistemas
 
ODP
PHP Seguro em 2013
porPatrick Kaminski
 
PPTX
Aula 04 - Curso GRATUITO EAD de Desenvolvimento Seguro de Software com Alcyon...
porAlcyon Ferreira de Souza Junior, MSc
 
PPT
Tratando as vulnerabilidades do Top 10 com php
porConviso Application Security
 
PPTX
Teste de segurança em aplicações web ( sites )
porPablo Ribeiro
 
ODP
Aprendendo a atacar (e proteger) aplicações web através de jogos de guerra
porClavis Segurança da Informação
 
PDF
Teste seguranca aplicacoes web security testing
porCristiano Caetano
 
PDF
TDC 2016 - Rodando JavaScript Server com Wildfly
porLeonardo Zanivan
 
PPT
Ameacas e Vulnerabilidades em Apps Web-2013
porKleitor Franklint Correa Araujo
 
PDF
Joomla!, SSL e um pouco sobre segurança
porFernando Soares
 
PDF
Segurança em Aplicações Web
porCassio Ramos
 
Java security
porarmeniocardoso
 
Engenharia de Software II - Teste de segurança de software
porJuliano Padilha
 
Dica 02 - Como mitigar os ataques de SQL Injection em aplicações WEB
porAlcyon Ferreira de Souza Junior, MSc
 
Segurança em Aplicações Web conforme OWASP
porFabiano Pereira
 
Minicurso de Segurança em Java EE 7
porHelder da Rocha
 
Palestra em parceria com o @cefet_rj – Auditoria Teste de Invasão em Aplicações
porClavis Segurança da Informação
 
Testes de Segurança de Software (tech-ed 2008)
porConviso Application Security
 
Jaas apresentado
porBruno Taboada
 
Aula 03 - Curso GRATUITO EAD de Desenvolvimento Seguro de Software com Alcyon...
porAlcyon Ferreira de Souza Junior, MSc
 
Testes de segurança em aplicações web
porSynergia - Engenharia de Software e Sistemas
 
PHP Seguro em 2013
porPatrick Kaminski
 
Aula 04 - Curso GRATUITO EAD de Desenvolvimento Seguro de Software com Alcyon...
porAlcyon Ferreira de Souza Junior, MSc
 
Tratando as vulnerabilidades do Top 10 com php
porConviso Application Security
 
Teste de segurança em aplicações web ( sites )
porPablo Ribeiro
 
Aprendendo a atacar (e proteger) aplicações web através de jogos de guerra
porClavis Segurança da Informação
 
Teste seguranca aplicacoes web security testing
porCristiano Caetano
 
TDC 2016 - Rodando JavaScript Server com Wildfly
porLeonardo Zanivan
 
Ameacas e Vulnerabilidades em Apps Web-2013
porKleitor Franklint Correa Araujo
 
Joomla!, SSL e um pouco sobre segurança
porFernando Soares
 
Segurança em Aplicações Web
porCassio Ramos
 

Destaque

PDF
Java EE 8 Web Frameworks: A Look at JSF vs MVC
porJosh Juneau
 
PDF
Java EE 8 Recipes
porJosh Juneau
 
PPT
Padrão Arquitetural MVC e suas aplicações para WEB
porRafael França
 
PDF
Gráficos Vetoriais na Web com SVG
porHelder da Rocha
 
PDF
HTML5 Media Elements
porJavier Antonio Humarán Peñuñuri
 
PDF
Model View Controller (MVC)
porJavier Antonio Humarán Peñuñuri
 
PDF
What is tackled in the Java EE Security API (Java EE 8)
porRudy De Busscher
 
PDF
Finally, EE Security API JSR 375
porAlex Kosowski
 
PDF
MVC 1.0 / JSR 371
porDavid Delabassee
 
PDF
Java EE 8 Adopt a JSR : JSON-P 1.1 & MVC 1.0
porDavid Delabassee
 
PDF
New MVC 1.0 JavaEE 8 API
porTrayan Iliev
 
PPTX
Casperjs-tdc-2016.ppt
porRodrigo Freitas
 
PDF
Java EE 8 - February 2017 update
porDavid Delabassee
 
PDF
Apresentando meteor! Join Community - Goiânia
porFrederico Maia Arantes
 
PDF
Java 8 - Afinal onde usamos no dia a dia? GOJava 15 anos!
porFrederico Maia Arantes
 
PDF
Java 8 - Afinal onde usamos no dia a dia? TDC 2015 - Porto Alegre
porFrederico Maia Arantes
 
Java EE 8 Web Frameworks: A Look at JSF vs MVC
porJosh Juneau
 
Java EE 8 Recipes
porJosh Juneau
 
Padrão Arquitetural MVC e suas aplicações para WEB
porRafael França
 
Gráficos Vetoriais na Web com SVG
porHelder da Rocha
 
HTML5 Media Elements
porJavier Antonio Humarán Peñuñuri
 
Model View Controller (MVC)
porJavier Antonio Humarán Peñuñuri
 
What is tackled in the Java EE Security API (Java EE 8)
porRudy De Busscher
 
Finally, EE Security API JSR 375
porAlex Kosowski
 
MVC 1.0 / JSR 371
porDavid Delabassee
 
Java EE 8 Adopt a JSR : JSON-P 1.1 & MVC 1.0
porDavid Delabassee
 
New MVC 1.0 JavaEE 8 API
porTrayan Iliev
 
Casperjs-tdc-2016.ppt
porRodrigo Freitas
 
Java EE 8 - February 2017 update
porDavid Delabassee
 
Apresentando meteor! Join Community - Goiânia
porFrederico Maia Arantes
 
Java 8 - Afinal onde usamos no dia a dia? GOJava 15 anos!
porFrederico Maia Arantes
 
Java 8 - Afinal onde usamos no dia a dia? TDC 2015 - Porto Alegre
porFrederico Maia Arantes
 

Semelhante a JSR 375 Segurança em Java EE 8

PDF
API de segurança do Java EE 8
porHelder da Rocha
 
PPS
Segurança J2EE
porRodrigo Cândido da Silva
 
PDF
OWASP Top 10 2010 para JavaEE (pt-BR)
porMagno Logan
 
PPTX
O Spring está morto! Viva o Spring!
porJosenaldo de Oliveira Matos Filho
 
PDF
Java OO Middleware - JEE / EJB / RMI
porYitzhak Stone
 
PDF
Autenticação e Controle de Acesso
porDenis L Presciliano
 
PDF
GUJavaSC - Protegendo Microservices em Java
porRodrigo Cândido da Silva
 
PPT
Java v1.1
porWaldir R. Pires Jr
 
PDF
Novidades de Java EE 7
porpt_programar
 
PPTX
JEE6 - Introdução
porRonaldo Oliveira
 
PDF
Java Platform, Enterprise Edition
porDaniel Arndt Alves
 
KEY
Java No Mundo Real
porSaulo Arruda
 
PDF
Aspectos segurança javaee
porWalter Mourão
 
API de segurança do Java EE 8
porHelder da Rocha
 
Segurança J2EE
porRodrigo Cândido da Silva
 
OWASP Top 10 2010 para JavaEE (pt-BR)
porMagno Logan
 
O Spring está morto! Viva o Spring!
porJosenaldo de Oliveira Matos Filho
 
Java OO Middleware - JEE / EJB / RMI
porYitzhak Stone
 
Autenticação e Controle de Acesso
porDenis L Presciliano
 
GUJavaSC - Protegendo Microservices em Java
porRodrigo Cândido da Silva
 
Java v1.1
porWaldir R. Pires Jr
 
Novidades de Java EE 7
porpt_programar
 
JEE6 - Introdução
porRonaldo Oliveira
 
Java Platform, Enterprise Edition
porDaniel Arndt Alves
 
Java No Mundo Real
porSaulo Arruda
 
Aspectos segurança javaee
porWalter Mourão
 

Mais de Helder da Rocha

PDF
Curso de WebServlets (Java EE 7)
porHelder da Rocha
 
PDF
Curso de Java Persistence API (JPA) (Java EE 7)
porHelder da Rocha
 
PDF
Curso de RESTful WebServices em Java com JAX-RS (Java EE 7)
porHelder da Rocha
 
PDF
Curso de Enterprise JavaBeans (EJB) (JavaEE 7)
porHelder da Rocha
 
PDF
Palestra: Ficou mais fácil programar no Java 25
porHelder da Rocha
 
PDF
Introdução a JPA (2010)
porHelder da Rocha
 
PDF
Padrões essenciais de mensageria para integração de sistemas
porHelder da Rocha
 
PDF
Transforming public data into thematic maps (TDC2019 presentation)
porHelder da Rocha
 
PDF
Threads 07: Sincronizadores
porHelder da Rocha
 
PDF
Atualização Java 8 (2014)
porHelder da Rocha
 
PDF
Como criar um mapa temático interativo com dados abertos e D3.js
porHelder da Rocha
 
PDF
Introdução à Visualização de Dados (2015)
porHelder da Rocha
 
PDF
Eletrônica Criativa: criando circuitos com materiais alternativos
porHelder da Rocha
 
PDF
Curso de Java: Threads
porHelder da Rocha
 
PDF
Threads 09: Paralelismo
porHelder da Rocha
 
PDF
Curso de Java: Introdução a lambda e Streams
porHelder da Rocha
 
PDF
Java 9, 10, 11
porHelder da Rocha
 
PDF
Threads 08: Executores e Futures
porHelder da Rocha
 
PDF
TDC 2019: transformando 
dados
públicos
em mapas interativos
porHelder da Rocha
 
PDF
Visualização de dados e a Web
porHelder da Rocha
 
Curso de WebServlets (Java EE 7)
porHelder da Rocha
 
Curso de Java Persistence API (JPA) (Java EE 7)
porHelder da Rocha
 
Curso de RESTful WebServices em Java com JAX-RS (Java EE 7)
porHelder da Rocha
 
Curso de Enterprise JavaBeans (EJB) (JavaEE 7)
porHelder da Rocha
 
Palestra: Ficou mais fácil programar no Java 25
porHelder da Rocha
 
Introdução a JPA (2010)
porHelder da Rocha
 
Padrões essenciais de mensageria para integração de sistemas
porHelder da Rocha
 
Transforming public data into thematic maps (TDC2019 presentation)
porHelder da Rocha
 
Threads 07: Sincronizadores
porHelder da Rocha
 
Atualização Java 8 (2014)
porHelder da Rocha
 
Como criar um mapa temático interativo com dados abertos e D3.js
porHelder da Rocha
 
Introdução à Visualização de Dados (2015)
porHelder da Rocha
 
Eletrônica Criativa: criando circuitos com materiais alternativos
porHelder da Rocha
 
Curso de Java: Threads
porHelder da Rocha
 
Threads 09: Paralelismo
porHelder da Rocha
 
Curso de Java: Introdução a lambda e Streams
porHelder da Rocha
 
Java 9, 10, 11
porHelder da Rocha
 
Threads 08: Executores e Futures
porHelder da Rocha
 
TDC 2019: transformando 
dados
públicos
em mapas interativos
porHelder da Rocha
 
Visualização de dados e a Web
porHelder da Rocha
 

Último

PDF
Dev In The Loop - Quando e Como o Desenvolvedor Atua no Ciclo de Desenvolvime...
porDouglas Siviotti
 
PDF
Um projeto de redes para fins educacionais
porLorran17
 
PPTX
pt-BR_Google Cloud Computing Foundations M9_ You Have the Data but What Are Y...
porArlimar Jacinto
 
PPTX
API e Endpoints para Google Cloud para IA
porArlimar Jacinto
 
PPT
redes_Ind_topologias estrutura de dados.ppt
porbacasandro2024
 
PPTX
SEQUENCIA DE PARTIDA DE QUEIMADORES INDUSTRIAIS
porantonskyrda
 
PPTX
Impacto das micotoxinas na alimentação de bovinos
pordavifrancisco9
 
PDF
Gerenciamento-de-Portfolio-de-Projetos.pdf
porAragon Salvador
 
PPTX
IA, Machine Learning e Deep Learning.pptx
porArlimar Jacinto
 
PDF
Global_Innovation_Tour_in_Silicon_Valley_&_RSA_2026
porOBr.global
 
PDF
FISIOLOGIA E FENOLOGIA DO MILHO - FELIPE CRUVINEL E CAIRO
porGETA - UFG
 
PDF
COLHEITA, ARMAZENAMENTO, COMERCIALIZAÇÃO E INDUSTRIALIZAÇÃO DO MILHO – JULIA ...
porGETA - UFG
 
PDF
COLHEITA, ARMAZENAMENTO, COMERCIALIZAÇÃO E INDUSTRIALIZAÇÃO DA SOJA - FELIPE ...
porGETA - UFG
 
PDF
MODOS DE AÇÃO DOS FUNGICIDAS - JÚLIA E DIEGO
porGETA - UFG
 
Dev In The Loop - Quando e Como o Desenvolvedor Atua no Ciclo de Desenvolvime...
porDouglas Siviotti
 
Um projeto de redes para fins educacionais
porLorran17
 
pt-BR_Google Cloud Computing Foundations M9_ You Have the Data but What Are Y...
porArlimar Jacinto
 
API e Endpoints para Google Cloud para IA
porArlimar Jacinto
 
redes_Ind_topologias estrutura de dados.ppt
porbacasandro2024
 
SEQUENCIA DE PARTIDA DE QUEIMADORES INDUSTRIAIS
porantonskyrda
 
Impacto das micotoxinas na alimentação de bovinos
pordavifrancisco9
 
Gerenciamento-de-Portfolio-de-Projetos.pdf
porAragon Salvador
 
IA, Machine Learning e Deep Learning.pptx
porArlimar Jacinto
 
Global_Innovation_Tour_in_Silicon_Valley_&_RSA_2026
porOBr.global
 
FISIOLOGIA E FENOLOGIA DO MILHO - FELIPE CRUVINEL E CAIRO
porGETA - UFG
 
COLHEITA, ARMAZENAMENTO, COMERCIALIZAÇÃO E INDUSTRIALIZAÇÃO DO MILHO – JULIA ...
porGETA - UFG
 
COLHEITA, ARMAZENAMENTO, COMERCIALIZAÇÃO E INDUSTRIALIZAÇÃO DA SOJA - FELIPE ...
porGETA - UFG
 
MODOS DE AÇÃO DOS FUNGICIDAS - JÚLIA E DIEGO
porGETA - UFG
 

JSR 375 Segurança em Java EE 8

  • 1.
  • 2.
    Objetivos Discutir os problemasque existem na API padrão de segurança do Java EE atual Apresentar as idéias que estão sendo discutidas sobre o JSR-375: API de Segurança do Java EE 8
  • 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.
    A API padrãode segurança do 
 Java EE 
 é muito complexa?
  • 5.
    Java EE 8Community Survey O que deve ser priorizado? Fonte: Java EE 8 Community Survey
  • 6.
    Java EE 8Community Survey O que deve ser priorizado? 2˚ Fonte: Java EE 8 Community Survey
  • 7.
    Java EE 8Community Survey O que deve ser priorizado? 2˚ Security Simplification 11.1% Fonte: Java EE 8 Community Survey
  • 8.
    Quais são osproblemas? • É complexa, confusa, difícil de usar • Redundância desnecessária • Volta aos tempos do J2EE • Precisa ser modernizada • Não suporta OpenID Connect, OAuth, etc • Difícil de usar na nuvem e PaaS
  • 9.
    Como mapear usuáriosno
 Tutorial Java EE 7 Glass
 fish É possível implementar uma solução completa de segurança em Java EE que não dependa de APIs ou configurações proprietárias ou frameworks de terceiros?
  • 10.
    Quais são osproblemas? • É complexa, confusa, difícil de usar • Redundância desnecessária • Volta aos tempos do J2EE • Precisa ser modernizada • Não suporta OpenID Connect, OAuth, etc • Difícil de usar na nuvem e PaaS • Não existe API padrão Java EE para segurança! • Vendor lock-in com solução do fabricante • Desenvolvedores abandonam Java EE em busca de soluções de terceiros (Spring, Shiro, etc.)
  • 11.
    Problemas da segurançaJava EE • Necessidade de usar configurações proprietárias • Em ambiente de nuvem/PaaS é problema: desenvolvedores não tem acesso a recursos proprietários - não se adapta ao paradigma do desenvolvedor de apps para a nuvem • API não é portável, é confusa, antiquada • Desenvolvedores migram para frameworks de terceiros já que o padrão não existe
  • 12.
    Wild Fly Segurança padrão noJava EE • Vendor lock-in: escolha a sua prisão Web
 Sphere Glass
 fish ?
  • 13.
    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
  • 14.
    Mensagem Mensagem Role Principal Role userid pass / cert CamadadeAplicações CamadadeAplicações Camadade 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
  • 15.
  • 16.
    O que faltaem 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?
  • 17.
  • 18.
    O que fazer •Resolver problemas de portabilidade • Facilitar a vida do desenvolvedor • Usar defaults e não precisar XML • Configuração independente de servidor • Modernizar • Atender demandas atuais de segurança • Inspiração em frameworks existentes OmniSecurity + ...
  • 19.
    Objetivos da JSR-375 "Thegoal of this JSR is to improve the Java EE platform by ensuring the Security API aspect is useful in the modern cloud/PaaS application paradigm." "This promotes self-contained application portability across all Java EE servers, and promotes use of modern programming concepts such as expression language, and contexts and dependency injection." "This JSR will holistically attempt to simplify, standardize, and modernize the Security API across the platform in areas identified by the community via survey results and submitted JIRA issues."
  • 20.
    JSR 375 -Linha do tempo Q3 2014 Expert Group formed NÓS ESTAMOS AQUI (Jul/2015) Q4 2015 Early Draft Q1 2016 Public Review Q3 2016 Proposed Final Draft H1 2017 Final Release
  • 21.
    • Baseadas nosresultados finais do Java EE 8 Community Survey • Password aliases Quais as prioridades? Fonte: Java EE 8 Community Survey
  • 22.
    • Baseadas nosresultados finais do Java EE 8 Community Survey • Password aliases • API de Autenticação (simplificação do JASPIC) Quais as prioridades? Fonte: Java EE 8 Community Survey
  • 23.
    • Baseadas nosresultados finais do Java EE 8 Community Survey • Password aliases • API de autenticação (simplificação do JASPIC) • API para atribuir roles e permissões Quais as prioridades? Fonte: Java EE 8 Community Survey
  • 24.
    Fonte: Java EE 8Community Survey Quais as prioridades? • Baseadas nos resultados finais do Java EE 8 Community Survey • Password aliases • API de autenticação (simplificação do JASPIC) • API para atribuir roles e permissões • Interceptadores de autorização
  • 25.
    Quais as prioridades? •Baseadas nos resultados finais do Java EE 8 Community Survey • Password aliases • API de autenticação (simplificação do JASPIC) • API para atribuir roles e permissões • Interceptadores de autorização • API para Identity Store Fonte: Java EE 8 Community Survey
  • 26.
    Quais as prioridades? •Resultados finais do Java EE 8 Community Survey • Password aliases • API de autenticação (simplificação do JASPIC) • API para atribuir roles e permissões • Interceptadores de autorização • API para Identity Store • + Simplificar a API • Introduzir um contexto de segurança unificado • Unificar a terminologia
  • 27.
    Principais idéias doJSR 375 • Terminologia unificada • API de autenticação • API de identity store • API de password aliasing • API de atribuição de roles e permissões • API de interceptadores de autorização • API de contexto de segurança Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 28.
    Relacionamentos entre aspropostas Identity Store Mecanismo de Autenticação Contexto de Segurança Atribuição de Permissões / Roles Interceptadores de Autorização Aliasing de Senhas Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 29.
  • 30.
  • 31.
    Terminologia • Como sechama a entidade que se autentica? get????Principal() get????InRole()
  • 32.
    Terminologia • Como sechama a entidade que se autentica? getUserPrincipal() getUserInRole()
  • 33.
    Terminologia • Como sechama a entidade que se autentica? getCallerPrincipal() getCallerInRole()
  • 34.
    Terminologia • O queé um grupo? Conjunto de usuários? Uma permissão? ??????
  • 35.
    Discussão sobre terminologia •Epic (JIRA) sobre terminologia da API • https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-21 • + em SPECs 1, 2, 3 e 28 • Nas discussões a preferência tem sido maior para "Caller" em vez de "User" para usuário logado (SPEC-2) Fonte: https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-2
  • 36.
    Terminologia • Como sechama a coisa que guarda identidades? zone domain region security provider login module identity manager provider authenticator identity provider auth store repository identity store realm authentication repository auth provider
  • 37.
  • 38.
    Mecanismo de autenticação •Situação: desenvolvedor tem uma aplicação que • Gerencia seus próprios usuários e grupos • Precisa autenticar usuários para atribuir roles • Quer autenticar usando modelos do domínio da aplicação • Precisa usar método não suportado (ex: OpenID Connect) • Solução simples • Vendor lock-in com o fabricante do servidor de aplicações • Framework de terceiros (Spring, Shiro, etc.) • Solução Java EE: ?
  • 39.
    Autenticação em JavaEE • Java EE oferece duas alternativas (excludentes) de configuração • API declarativa na camada Web para selecionar 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
  • 40.
    JAAS Principal != Java EEPrincipal • O foco é diferente em Java SE e Java EE • Java SE (JAAS): um Subject representa um usuário, que pode ter uma coleção de identidades (Principal) • Java EE: um Principal representa um usuário
 que pode ter uma coleção de permissões (Roles)
  • 41.
    JASPIC SAM public interfaceServerAuthModule { public void initialize(...) throws AuthException; public AuthStatus validateRequest(...); public Class<?>[] getSupportedMessageTypes(); public AuthStatus secureResponse(...); public void cleanSubject(...); }
  • 42.
    JASPIC javax.security.auth.message.module
 ServerAuthModule javax.servlet
 ServletContextListener javax.security.auth.message.config
 AuthConfigFactory javax.security.auth.message.config
 AuthConfigProvider contextInitialized() javax.security.auth.message.config
 ServerAuthConfig javax.security.auth.message.config
 ServerAuthContext «create» «create» «create»«create»javax.security.auth.message.callback
 CallbackHandler javax.security.auth.message.callback
 CallerPrincipalCallback javax.security.auth.message.callback
 GroupPrincipalCallback validateRequest() handle() Web Container authenticate AuthService JSR 196 «create» «create» initialize() validateRequest() registerConfigProvider() «create» HTTP
 request Register Principal and Groups * * * * * * * Must create implementations of these classes/interfaces
  • 43.
    Proposta JSR-375: JASPIC •Por que ninguém usa JASPIC? • Complexo! Tem que programar 6 classes • Ideia: reduzir 5 classes a uma (SAM) • Registrar no ServletContextListener e/ou anotações @Authenticator("org.acme.TokenAuthModule") @WebServlet("/SimpleServlet") @ServletSecurity(@HttpConstraint(rolesAllowed = {"manager"})) public class SimpleServlet extends HttpServlet { • Em vez de implementar toda a interface, usar um Profile • ex: MySAM extends HttpServerAuthModule {} Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 44.
    Proposta JSR-375: JASPIC •Fornecer autenticadores padrão • Lançar eventos CDI • @PreAuthenticate, @PostAuthenticate
 @PreLogout, @PostLogout • Para contar usuários logados, • Rastrear tentativas de login mal-sucedidas • Criar usuário local depois de autenticação remota • Preferências do usuário, etc. @Authenticator("javax.security.authenticator.OpenIDConnect") @WebServlet("/SimpleServlet") @ServletSecurity(@HttpConstraint(rolesAllowed = {"manager"})) public class SimpleServlet extends HttpServlet { Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 45.
  • 46.
    Gerência de usuários:hoje • Atualmente não existe suporte padrão para gerenciar usuários em Java EE • Aplicações não tem como criar, remover, atualizar e agrupar usuários em Java EE • Dependência de soluções 
 proprietárias (vendor-lock-in), 
 frameworks de terceiros 
 ou soluções in-house Realm
  • 47.
    Proposta JSR-375: IdentityStore • Serviço padrão para criar, atualizar, remover, e agrupar usuários • Usa um recurso de usuários • Escopo pode ser limitado à aplicação e/ou compartilhado por outras aplicações • LDAP, arquivos, datasource, embedded, servidor • Poder ser ntercambiável: recurso diferente para desenvolvimento, teste, produção • API poderia informar quais os serviços disponíveis em determinado recurso de usuários.
  • 48.
    Primeiro esboço: APIde Identity Store public interface IdentityStore { Identity loadIdentityByName(String name); void changePassword(char[] oldPassword, char[] newPassword); void createIdentity(Identity user); void deleteIdentity(String name); void updateIdentity(Identity identity); boolean identityExists(String name); void createGroup(String group); void deleteGroup(String group); void addIdentityToGroup(String name, String group); void removeIdentityFromGroup(String name, String group); boolean isIdentityInGroup(String name, String group); List<String> getIdentityGroups(String name); } public interface Identity { String getUsername(); char[] getPassword(); boolean isAccountExpired(); boolean isAccountLocked(); boolean isPasswordExpired(); boolean isEnabled(); IdentityAttributeValue getAttribute(String name); } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 49.
    Proposta + recentepara Identity Store public interface IdentityStore { // Callers and Groups Caller loadCaller(String loginName); boolean callerExists(String loginName); List<Caller> getCallers(String regEx); boolean groupExists(String name); List<String> getGroups(String regEx); boolean isCallerInGroup(String callerLoginName, String groupName); List<Caller> getCallersInGroup(String group); List<String> getCallerGroups(String callerLoginName); List<String> getCallerGroups(Caller caller); // Credentials CredentialValidationResult validateCredentials(Credentials credentials); // Role Mapping boolean roleExists(String name); enum RoleSetSelector {ALL, ASSIGNED, UNASSIGNED} List<String> getRoles(String regEx, RoleSetSelector roleSet); // Roles mapped to Caller // boolean callerHasRole(String loginName, String role); boolean callerHasRole(Caller caller, String role); List<Caller> getCallersWithRole(String role); List<String> getRolesForCaller(String loginName); List<String> getRolesForCaller(Caller caller); // Roles mapped to Group // boolean groupHasRole(String groupName, String role); List<String> getGroupsWithRole(String role); List<String> getRolesForGroup(String groupName); } public class Caller { private String loginName; public String getLoginName() { return loginName; } public void setLoginName(String loginName) { this.loginName = loginName; } } Fonte: 
 https://github.com/javaee-security-spec/javaee-security-proposals
 Jun 08 2015 Baseada em PicketLink (picketlink.org)
  • 50.
    Identity Store: implementação Fonte: Palestrade Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015 Identity IdentityStore LDAP BD Arquivo Servidor Embedded
  • 51.
    Identity store: idéiasde como usar • Como embutir um Identity Store na própria aplicação @EmbeddedIdentityStore(name="java:app/devIdentityStore",
 {
 @Identity(username="ray", password="secret", groups="admin"),
 @Identity(username="jo", password="secret", groups="user"),
 @Identity(username="sam", password="secret", groups="user")
 }) • Identity Store em banco de dados relacional @DatabaseIdentityStore(
 name="java:app/testIdentityStore",
 lookup="somedatabase",
 userQuery="SELECT passwd FROM principals WHERE userid=?",
 groupQuery="SELECT group FROM groups where username=?", ...) Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 52.
  • 53.
    Password Aliasing • Atualmentenão há suporte padrão para referenciar e guardar uma senha (para acessar recursos) de forma segura em Java EE • Aplicações precisam de uma senha assim, por exemplo, para acessar recursos de bancos de dados, em um persistence.xml • Soluções são in-house ou usando ferramentas de terceiros
  • 54.
    Proposta JSR-375: PasswordAliasing • Sintaxe padrão para indicar um alias de senha, e um meio para resolver o alias para um valor de senha • Repositório seguro que poderia ser mantido com a aplicação <data-source> <name>java:app/env/testDS</name> <user>APP</user> <password>${ALIAS=token}</password> ... </data-source> @DataSourceDefinition( name="java:app/jdbc/test", user="root", password="${ALIAS=token}", ...) Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015 ${ALIAS=a#6W@+2&3_} "senha"
  • 55.
  • 56.
    java.security
 Permission Autorização em JavaEE 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() {}
  • 57.
    Role Mapping emJava EE • Atualmente não há suporte padrão a mapeamento de roles em Java EE • Soluções implicam em vendor lock-in ou uso de APIs de terceiros <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>
  • 58.
    Proposta JSR-375: RoleMapping • Serviço de roles padronizado que permite que a aplicação realize operações de mapeamento de roles • granting, pesquisa, para roles de usuários e grupos • Serviço manipularia mapeamentos de um role mapper (pode ser embedded, JDBC, LDAP, etc.) @EmbeddedRoleMapper( users={ @RoleMap(user=“foo”,roles=“admin”), @RoleMap(group=“admin”,roles={“admin”,”manager”}) } ) public class MyServlet { } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 59.
    Role Mapper dinâmico publicinterface RoleMapper { void grantRoleToUser(String username, String role); void revokeRoleFromUser(String username, String role); boolean hasRoleForUser(String username, String role, boolean includeGroups); List<String> getRolesForUser(String username, boolean includeGroups); List<String> getUsersWithRole(String role, boolean includeGroups); void grantRoleToGroup(String group, String role); void revokeRoleFromGroup(String group, String role); boolean hasRoleForGroup(String group, String role); List<String> getRolesForGroup(String group); List<String> getGroupsWithRole(String role); } @Inject RoleMapper roleMapper; roleMapper.grantRoleToGroup("Manager", "EDIT_ACCOUNTS"); boolean has = roleMapper.hasRoleForGroup("Manager", "CLOSE_ACCT"); List<String> roles = roleMapper.getRolesForGroup("Manager"); List<String> groups = roleMapper.getGroupsWithRole("VIEW_ACCOUNTS"); Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 60.
    Limitações da autorização •Atualmente Java EE apenas suporta autorização por permissões (roles) • Não há suporte padrão para incluir regras do domínio da aplicação na decisão de autorização • Soluções são in-house ou proprietárias
  • 61.
    Proposta JSR-375: interceptadores •Anotação padrão de interceptador para métodos, capaz de incluir regras que seriam usadas na autorização • Seria chamada se forma similar a @AroundInvoke • As regras teriam acesso ao contexto atual • Regras poderiam ser baseadas em texto (como Java EL) • Suporte a eventos CDI como parte do processo de decisão @LdapAuthorizationRules ( name="java:app/accountAuthRules", ldapUrl="ldap://blah", ldapUser="ElDap", ldapPassword=“mysecret” )
 public class MyBean { 
 @ EvaluateSecured(ruleSourceName="java:app/accountAuthRules", 
 rule="transferFunds")
 void transferFunds() {..}; } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 62.
  • 63.
    Como obter principalse 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
  • 64.
    Proposta JSR-375: 
 contextode segurança • Deveria haver apenas um contexto de segurança que pudesse ser obtido por qualquer componente Java EE public class MyFutureCdiBean { @Inject private SecurityContext securityContext; public String sayHello() { if (securityContext.isUserInRole("admin")) { return "Hello World!"; } throw new SecurityException("User is unauthorized."); } } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 65.
    Exemplo (idéia) public interfaceSecurityContext { String getUserPrincipal(); boolean isUserInRole(String role); List<String> getAllUsersRoles(); boolean isAuthenticated(); boolean isUserInAnyRole(List<String> roles); boolean isUserInAllRoles(List<String> roles); void login(Object request, Object response); void login(Map map); void logout(); void runAs(String role); boolean hasAccessToResource(); boolean hasAccessToBeanMethod(); } Fonte: Palestra de Alex Kowolski Finally, Security API JSR 375
 Devoxx France Apr 08 2015
  • 66.
    Conclusões • Java EEnão tem uma API de segurança padrão independente de plataforma, moderna e fácil de usar • Java EE 8 pode ser que tenha - essa é a meta do JSR-375 • Se você tem interesse, envolva-se! • Como se envolver • Página do projeto: 
 https://java.net/projects/javaee-security-spec • Lista de discussões:
 users@javaee-security-spec.java.net • Playground no GitHub (faça fork e explore):
 https://github.com/javaee-security-spec/javaee-security-proposals
  • 67.
    Referências • Página daJSR-375 • https://www.jcp.org/en/jsr/detail?id=375 • Discussões do JIRA do JSR-375 e listas de e-mail • https://java.net/jira/browse/JAVAEE_SECURITY_SPEC • https://java.net/projects/javaee-security-spec/lists • Artigos de Arjan Tijms sobre JASPIC e JAAC • arjan-tijms.omnifaces.org • Palestra do spec lead Alex Kosowski no DevoXX France (Abril 2015)
  • 68.