O workshop aborda conceitos de segurança JEE, demonstrações de implementações declarativas e programáticas de segurança em EJB e web, e integração com soluções de mercado como Tivoli Access Manager para autorização e gerenciamento centralizado de políticas de acesso.

1. Workshop
Segurança JEE

2. Agenda
 Apresentação
 Conceitos segurança JEE
 Desenvolvendo: RAD
 Implementação, testes
 Demo
 Java Authorization Contract for Containers JACC
 Demo
 Infraestrutura
 Introdução a segurança de serviços web

3. Apresentação

4. 3o pilar da Qualidade da Aplicação
 Funcionalidade
 Performance
 Segurança

5. Problemas
 Os aplicativos Web são o alvo n° 1 dos hackers que
buscam explorar vulnerabilidades
 Os aplicativos são implantados com vulnerabilidades
 Configurações de baixa segurança expõem as empresas
à perdas de negócios
 Os requisitos regulatórios de PCI exigem a segurança de
aplicativo
 80% dos custos de desenvolvimento são gastos na
identificação e correção de defeitos

6. Benefícios
 Reduz o risco de interrupção, desfiguração ou roubo de
dados associados com aplicativos Web
 Assessora e monitora conformidade da política de
segurança em toda a empresa
 Melhora a conformidade com as normas do setor e
exigências regulatórias (por exemplo PCI)
 Melhora a capacidade de integrar aplicativos críticos
do negócio
 Teste e controle automatizados durante todo o ciclo de
vida do desenvolvimento, reduzindo os custos de
segurança a longo prazo.

7. Motivações e objetivos
 Controle de acesso incorporado nas aplicações pode falhar
 Impacto no ciclo de desenvolvimento da aplicação
 Limitação dos componentes desenvolvido internamente
 Custo e prazo de atualização dos componentes
 Modelo de autorização relativamente complicado
 Falta de auditoria
 Usar solução de mercado
 Velocidade na colocação de novas aplicações
 Aumentar controle de acesso – Diminuir falhas
 Transparente para as aplicações
 Auditoria de acesso
 Gerenciamento unificado das políticas

8. Ciclo de vida da aplicação
Configuração
RAD - LDAP
Desenvolvimento -TAM
Local - WAS7
- Portal
Publicação em Replicação Publicação
homologação/
configurações em teste
produção

9. Arquitetura lógica
WebSEAL Web
Container
Autorização
Servidor
Políticas
EJB
Container

10. Conceitos de Segurança JEE

11. Modelo de segurança JEE
 A segurança das aplicações JEE é implementada usando
papeis de segurança (Role)
 Os papeis de segurança são aplicados nos componentes
Web e EJB
– métodos EJB ou URIs Web
 A Segurança pode ser especificada de 2 maneiras:
– Declarativa em tempo de configuração, através dos
‘deployment descriptors’
– Programática utilizando as APIS padrões em tempo de
desenvolvimento
 A associação dos usuários e dos grupos com os papeis JEE
é geralmente feito no momento da instalação da
aplicação (deploy)

12. Processo
Bob Ligação Papel-Permissão Método
EJB
Método
EJB
Administrador
Ana Método
EJB
Enterprise
Java Bean
Solicitante
Servlet
Corretores
jsp
Atendente gif,
css
Segurados
Role Segurança Componentes
Usuários/Grupos JEE Web

13. Modelo de autorização
baseado em papel
Quais papeis são permitidos? Acesso
-EJB: roles necessários dos autorizado
métodos
- Servlet/jsp: roles necessários
SIM
nas security constraints
Requisição Algum
autenticada igual?
Quais papeis são atribuídos?
- Obter nome do NÃO
usuário/grupo nos credenciais
- Obter os roles atribuídos a Acesso
esse usuário/grupo negado

14. Mapeamento
Grupo  Mapeamento Application Deployment Descriptor
usuários
Usuário Recurso  Mapeamento Role
Usuário
Usuário
Usuário
Usuário
Metodo EJB
Role
Role
Grupo URI Web
Grupo
Usuário
Role  Mapeamento
Principal Definido pelo
programador da aplicação
Definido pelo
instalador da aplicação

15. Mapeamento Processos
(antigo-novo)
Cadastrar
papelRU
2
ETrust Papel RU Papel RA Permissão
Associar 6 5 4
Cadastrar
usuário 1 Papel RU ao Cadastrar permissão
usuário Associar papel Cadastrar papel RA e com descritor da
3 RA e papel RU associar permissão aplicação
Usuário
sincronização
GerenciadorLDAP
Colocar
usuário no
grupo Deploy-script RAD-Security Editor
Grupo RU Role JEE Recurso JEE

16. Implementando a Segurança JEE

17. Segurança EJB declarativa
 Implementação de segurança declarativa com Annotation
– Lista de annotations EJB
• @DeclareRoles
• @DenyAll
• @PermitAll
• @RolesAllowed
• @RunAs

18. Segurança EJB declarativa
 Implementação de segurança declarativa com Annotation
– Restrigir acesso ao EJB de sessão Donate
import javax.annotation.security.DeclareRoles;
import javax.annotation.security.RolesAllowed;
....
@DeclareRoles( { "DMANAGERS_ROLE", "DUSERS_ROLE" })
public class DonateBean implements DonateBeanInterface, ...... {
@RolesAllowed( { "DMANAGERS_ROLE","DUSERS_ROLE" })
public void donateToFund(Employee employee, Fund fund, int hours) ...
......
@RolesAllowed( { "DMANAGERS_ROLE","DUSERS_ROLE" })
public String donateToFund(int employeeId, String fundName, int hours) {

19. Deployment descriptor EJB
ejb-jar.xml (diretório DonateEJB/ejbModule/META-INF) imediatamente antes do tag
</ejb-jar.xml>
<assembly-descriptor>
<security-role>
<role-name>DMANAGERS_ROLE</role-name>
</security-role>
<security-role>
<role-name>DUSERS_ROLE</role-name>
</security-role>
<method-permission>
<role-name>DUSERS_ROLE</role-name>
<role-name>DMANAGERS_ROLE</role-name>
<method>
<ejb-name>DonateBean</ejb-name>
<method-name>donateToFund</method-name>
</method>
</method-permission>
</assembly-descriptor>
 Utilizar o editor de Segurança do RAD para auxilio

20. Segurança Web declarativa
 Implementação de segurança declarativa com Annotation
– Lista de annotations Web
• @DeclareRoles
• @RunAs

21. Segurança WEB
Editor de segurança do RAD:
Restringir o acesso a páginas Web com segurança declarativa

22. Informações de segurança
O editor de segurança insere as seguintes informações no
arquivo web.xml:
A restrição de segurança <security-constraint> é o
elemento base que contém:
 O elemento <web-resource-collection> define os
privilegios de acesso a um conjunto de recursos. Este
elemento pode especificar padrões de URL e métodos
HTTP.
 O elemento <auth-constraint> define quais são os
roles necessários para acessar esse conjunto de recursos
Web.
 O elemento <security-role> declare os nomes dos
roles utilizados nos elementos security-constraint.

23. <security-constraint>
<display-name>ALLAUTHENTICATED_ROLEConstraint</display-name>
<web-resource-collection>
<web-resource-name>ALLAUTHENTICATED_ROLECollection</web-resource-name>
<url-pattern>/faces/FindEmployee.jsp</url-pattern>
<url-pattern>/FindEmployee.faces</url-pattern>
<url-pattern>/FindEmployee.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>PUT</http-method>
<http-method>HEAD</http-method>
<http-method>TRACE</http-method>
<http-method>POST</http-method>
<http-method>DELETE</http-method> web.xml
<http-method>OPTIONS</http-method>
</web-resource-collection>
<auth-constraint>
<description>Auto generated Authorization Constraint</description>
<role-name>ALLAUTHENTICATED_ROLE</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description>
</description>
<role-name>DUSERS_ROLE</role-name>
</security-role>

24. Configurar roles do EAR e
mapeamento de roles - 1
Próximo slide

25. Configurar roles do EAR e
mapeamento de roles - 2

26. Teste da segurança declarativa EJB
com JUnit

27. Código para segurança
System.setProperty("com.ibm.SSL.ConfigURL", propDir +"ssl.client.props");
System.setProperty("java.security.auth.login.config", propDir +"wsjaas_client.conf");
System.setProperty("com.ibm.CORBA.ConfigURL",propDir +"sas.client.props");
Definir SSL, JAAS e SAS (Secure Authentication Services)
Propriedades necessárias para acessar o servidor
ctx.lookup("");
Conectar ao Contexto inicial para carregar o Realm default e
carregar as informações necessárias ao Security Server
LoginContext lc = new LoginContext("WSLogin",
new WSCallbackHandlerImpl("DNARMSTRONG", "xxxxxxxx")); o contexto do login,
Criar
lc.login(); fazer o login, e colocar o
final Subject subject = lc.getSubject(); usuário autenticado como
System.out.println("subject=" + subject.toString()); o usuário default para
WSSubject.setRunAsSubject(subject); este thread de execução

28. Teste de segurança
em EJB

29. Teste a segurança declarativa EJB
com Universal Test Client (UTC)

30. Teste da segurança declarativa Web
Mapeamento

31. Teste da segurança declarativa Web
com o usuário DGADAMS

32. Testar o acesso com o usuário
DNARMSTRONG

33. Implementar segurança
programática numa página Web
<h:outputText value="ROLES: " />
<h:outputText value="EDITOR"
rendered="#{rich:isUserInRole('EDITOR')}"/>
<h:outputText value="LEITOR"
rendered="#{rich:isUserInRole('LEITOR')}"/>
<h:outputText value="DIRETOR"
rendered="#{rich:isUserInRole('DIRETOR')}"/>
<h:outputText value="GERENTE"
rendered="#{rich:isUserInRole('GERENTE')}"/>

34. DEMO

35. Java Authorization Contract for Containers
JACC

36. Introdução a JACC
 JACC permite aos servidores de aplicação interagir
com fornecedores de autorização externos
usando interfaces padronizadas para tomar as
decisões de autorização
 JACC define as classes de permissão para os
Containers EJB e Web
 JACC não específica como atribuir roles aos
principais (grupos e usuários)

37. Java Authorization Contract
for Containers (JACC)
Administrador
Aplicação WebSphere Application Server: Container J2EE Usuário
Administração Aplicação
Controle de acesso
(deploy, undeploy)
Gerencia recursos, Acesso permitido?
roles, mapeamentos
Configuração Políticas Decisão de acesso
Tivoli Access Manager: Provedor JACC
Repositório provedor

38. Adição WebSphere
• WebSphere suporta 2 “principals” especiais para o
mapeamento Role  Principal:
– All Authenticated – role mapeado para All
Authenticated é atribuido a qualquer usuário
autenticado
– Everyone – role mapeado para Everyone é atribuido a
qualquer requisitante

39. Integração TAM com WAS
 Os componentes do cliente TAM são embutidos
no WebSphere Application Server
 TAM é o provedor default JACC para WebSphere
 O cliente TAM pode ser configurado usando
scripts ou a console de administração
 O servidor TAM pode fornecer função de
autenticação

40. Provedor TAM JACC
Configuração - 1
Próximo slide

41. Provedor TAM JACC
Configuração - 2
Aceitar Próximo slide
todos os
Defaults

42. Provedor TAM JACC
Configuração - 3
Servidor
Politicas
Servidor
Porta usado para Autorização
escutar as atualizações
da base de Politicas
Criado durante a
configuração da
Segurança WAS

43. Provedor TAM JACC
Mapeamento Role para Principal

44. Habilitar a segurança
das aplicações Java EE

45. DEMO

46. Infraestrutura

47. Integração com Portal
LDAP
Portal Legado
App-Legado
WebSEAL Vignette
App-Arq3.0
TAM

48. Modelo antigo-novo
Usuário PapelRA
F0104158 RARHUFuncionario
RUPSGFuncionario prhucontroleponto
RUPSGColaborador prhuconsultahol
PapelRU Permissão
RUPSGFuncionario prhucontroleponto
RARHUFuncionario prhuregistrarponto
RASYSFuncionario prhuiniciarweb
RUPSGFuncionario ROLE_RHUPontoApp
Mesma
F0104158 /rhuapp/registrarponto.do
F3400321 /rhuapp/consultalista.do URL
Grupo
RUPSGColaborador ROLE_RHUPontoApp RoleJEE
F0104158 RUPSGFuncionario
F3400321 RUPSGColaborador

49. Configuração TAM: grupo
Referência para
grupo LDAP

50. Configuração TAM: user
Referência para
usuário LDAP

51. Nomenclatura
 Sintaxe
– Papel: RUXXXColaborador, RAYYYAdministrador
• XXX: empresa, diretória, área de negócio
• YYY: identificação do sistema
– Role J2EE: ROLE_YYYAdministrador
– Grupo: RUXXXColaborador

52. Configuração servidores
li412 li450 li413
TAM TAM
Web SEAL Web SEAL
Authorization Server Authorization Server D
m
Catalog Server WAS-Cluster Catalog Server
g
Session Manager WAS-Cluster Session Manager r
Policy Server RHEL-luci Policy Server
TSPM TSPM
TSPM WAS-Cluster TSPM D
m
DB2 DB2-Cluster DB2
g
TIP TIP r

53. Introdução a Segurança Web Services

54. Motivos para DataPower
 XML é a linguagem de web services e SOA
 XML é onipresente – Em alguns anos, XML estará em qualquer aplicação,
equipamento e documento presente nas redes das empresas.
 Desafios do XML
– XML é muito ‘falante’
• XML precisa de muito banda.
• Tem um impacto direito sobre a performance do servidor de aplicação.
• O processamento XML precisa de um número significativos de ciclos de
processador e de recursos de memória.
– XML é um texto efetivamente legível por humano
• Não tem mecanismo nativo de segurança.
• Fácil de entender e vulnerável a intercepção.
• A segurança pode ser implementada no servidor de aplicação, mas é um
processamento adicional e aumenta o problema de performance.
– SOA não é somente Web Services e XML
• Empresas precisam integrar sistemas legados, formatos de mensagens e
protocolos numa arquitetura SOA.
• Necessidade de uma habilidade para transformar sistemas legados em
formato XML.

55. O que o DataPower endereça ?
 Performance XML
– Como? – transferindo o processamento do XML do servidor de
aplicação para o hardware otimizado do DataPower.
– Por conseqüência, reduzindo o número necessário de
servidores de aplicação
 Segurança XML
– Como? – transferindo a segurança XML para o DataPower
– Fornece a segurança padronizada – WS Security
 Integração XML e sistemas legados
– Como ? – usando DataPower para transformar XML em
formato e protocolo legados de mensagem:
• XML -> HMTL (renderiza conteúdo HTML para Portal)
• XML <-> Mensagem MQ
 Tudo é feito a velocidade de rede

56. Arquitetura com DataPower
Internet DMZ Intranet
Cliente
Applicações
• Ameaças XML • Transformação
• Controle Acesso • Integração
• SLA • Roteamento
Cliente

57. Exposição seletiva

58. WebSphere DataPower XI50
Crypto XSLT Processor
2 x 160 GB XG3 or XG4
4GB RAM Processor HDD 512MB Flash Memory
Serial Port
4 x 10/100/1000 Ethernet Ports

59. Referência
Portonet: Home > Departamentos > Informática -
Arquitetura de TI > Arquitetura de Software > Documentos
Padrão de Arquitetura de Segurança Java.pdf
Contatos:
jose.cardoso@escalainfo.com.br
philippe.guillaume@portoseguro.com.br

60. Obrigado