Workshop05

  • 307 views
Uploaded on

 

More in: Technology , Design
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
307
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Workshop Segurança JEE
  • 2. Agenda
    • Apresentação
    • 3. Conceitos segurança JEE
    • 4. Desenvolvendo: RAD
    • 5. Implementação, testes
    • 6. Demo
    • 7. Java Authorization Contract for Containers JACC
    • 8. Demo
    • 9. Infraestrutura
    • 10. Introdução a segurança de serviços web
  • Apresentação
  • 11. 3o pilar da Qualidade da Aplicação
  • Problemas
    • Os aplicativos Web são o alvo n° 1 dos hackers que buscam explorar vulnerabilidades
    • 14. Os aplicativos são implantados com vulnerabilidades
    • 15. Configurações de baixa segurança expõem as empresas à perdas de negócios
    • 16. Os requisitos regulatórios de PCI exigem a segurança de aplicativo
    • 17. 80% dos custos de desenvolvimento são gastos na identificação e correção de defeitos
  • Benefícios
    • Reduz o risco de interrupção, desfiguração ou roubo de dados associados com aplicativos Web
    • 18. Assessora e monitora conformidade da política de segurança em toda a empresa
    • 19. Melhora a conformidade com as normas do setor e exigências regulatórias (por exemplo PCI)
    • 20. Melhora a capacidade de integrar aplicativos críticos do negócio
    • 21. Teste e controle automatizados durante todo o ciclo de vida do desenvolvimento, reduzindo os custos de segurança a longo prazo.
  • Motivações e objetivos
    • Controle de acesso incorporado nas aplicações pode falhar
    • 22. Impacto no ciclo de desenvolvimento da aplicação
    • 23. Limitação dos componentes desenvolvido internamente
    • 24. Custo e prazo de atualização dos componentes
    • 25. Modelo de autorização relativamente complicado
    • 26. Falta de auditoria
    • 27. Usar solução de mercado
    • 28. Velocidade na colocação de novas aplicações
    • 29. Aumentar controle de acesso – Diminuir falhas
    • 30. Transparente para as aplicações
    • 31. Auditoria de acesso
    • 32. Gerenciamento unificado das políticas
  • Ciclo de vida da aplicação
  • 33. Arquitetura lógica
    Web Container
    WebSEAL
    Autorização
    Servidor Políticas
    EJB
    Container
  • 34. Conceitos de Segurança JEE
  • 35. Modelo de segurança JEE
    • A segurança das aplicações JEE é implementada usando papeis de segurança (Role)
    • 36. 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)
  • Processo
    Método
    EJB
    Bob
    Papel-Permissão
    Ligação
    Método
    EJB
    Administrador
    Ana
    Método
    EJB
    Enterprise Java Bean
    Solicitante
    Servlet
    Corretores
    jsp
    gif,
    css
    Atendente
    Segurados
    Componentes
    Web
    Role Segurança JEE
    Usuários/Grupos
  • 37. Modelo de autorização baseado em papel
    Quais papeis são permitidos?
    • EJB: roles necessários dos métodos
    • 38. Servlet/jsp: roles necessários nas security constraints
    Acesso
    autorizado
    Lista de papeis
    SIM
    Algum igual?
    Requisição
    autenticada
    Quais papeis são atribuídos?
    • Obter nome do usuário/grupo nos credenciais
    • 39. Obter os roles atribuídos a esse usuário/grupo
    NÃO
    Lista de papeis
    Acesso
    negado
  • 40. Mapeamento
    Application Deployment Descriptor
    Grupo  Mapeamento
    usuários
    Usuário
    Recurso  Mapeamento Role
    Usuário
    Usuário
    Usuário
    Usuário
    Role
    Metodo EJB
    Role
    Grupo
    URI Web
    Grupo
    Usuário
    Role  Mapeamento Principal
    Definido pelo programador da aplicação
    Definido pelo instalador da aplicação
  • 41. Mapeamento Processos (antigo-novo)
    Cadastrar
    papelRU
    2
    ETrust
    Papel RA
    Permissão
    Papel RU
    4
    5
    6
    Cadastrar usuário
    Associar Papel RU ao usuário
    1
    Cadastrar permissão com descritor da aplicação
    Cadastrar papel RA e associar permissão
    Associar papel RA e papel RU
    3
    Usuário
    GerenciadorLDAP
    sincronização
    Colocar usuário no grupo
    RAD-Security Editor
    Deploy-script
    Role JEE
    Recurso JEE
    Grupo RU
  • 42. Implementando a Segurança JEE
  • 43. Segurança EJB declarativa
    • Implementação de segurança declarativa com Annotation
    Lista de annotations EJB
    @DeclareRoles
    @DenyAll
    @PermitAll
    @RolesAllowed
    @RunAs
  • 44. 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) {
  • 45. 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
  • Segurança Web declarativa
    • Implementação de segurança declarativa com Annotation
    Lista de annotations Web
    @DeclareRoles
    @RunAs
  • 46. Segurança WEB
    Editor de segurança do RAD:
    Restringir o acesso a páginas Web com segurança declarativa
  • 47. 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.
    • 48. O elemento <auth-constraint> define quais são os roles necessários para acessar esse conjunto de recursos Web.
    • 49. O elemento <security-role> declare os nomes dos roles utilizados nos elementos security-constraint.
  • <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>
    <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>
    web.xml
  • 50. Configurar roles do EAR e mapeamento de roles - 1
    Próximo slide
  • 51. Configurar roles do EAR e mapeamento de roles - 2
  • 52. Teste da segurança declarativa EJB com JUnit
  • 53. 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"));
    lc.login();
    final Subject subject = lc.getSubject();
    System.out.println("subject=" + subject.toString());
    WSSubject.setRunAsSubject(subject);
    Criar o contexto do login, fazer o login, e colocar o usuário autenticado como o usuário default para este thread de execução
  • 54. Teste de segurançaem EJB
  • 55. Teste a segurança declarativa EJB com Universal Test Client (UTC)
  • 56. Teste da segurança declarativa Web
    Mapeamento
  • 57. Teste da segurança declarativa Webcom o usuário DGADAMS
  • 58. Testar o acesso com o usuário DNARMSTRONG
  • 59. Implementar segurança programática numa página Web
    <h:outputTextvalue="ROLES: "/>
    <h:outputTextvalue="EDITOR"rendered="#{rich:isUserInRole('EDITOR')}"/>
    <h:outputTextvalue="LEITOR"rendered="#{rich:isUserInRole('LEITOR')}"/>
    <h:outputTextvalue="DIRETOR"rendered="#{rich:isUserInRole('DIRETOR')}"/>
    <h:outputTextvalue="GERENTE"rendered="#{rich:isUserInRole('GERENTE')}"/>
  • 60. DEMO
  • 61. Java Authorization Contract for Containers
    JACC
  • 62. 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
    • 63. JACC define as classes de permissão para os ContainersEJB e Web
    • 64. JACC não específica como atribuir roles aos principais (grupos e usuários)
  • Java Authorization Contract for Containers (JACC)
    Administrador
    Aplicação
    WebSphere Application Server: Container J2EE
    Usuário
    Administração Aplicação(deploy, undeploy)
    Controle de acesso
    Gerencia recursos, roles, mapeamentos
    Acesso permitido?
    Tivoli Access Manager: Provedor JACC
    Configuração Políticas
    Decisão de acesso
    Repositório provedor
  • 65. Adição WebSphere
    • WebSphere suporta 2 “principals” especiais para o mapeamento Role  Principal:
    • 66. All Authenticated – role mapeado para All Authenticatedé atribuido a qualquer usuário autenticado
    • 67. Everyone – role mapeado para Everyone é atribuido a qualquer requisitante
  • Integração TAM com WAS
    • Os componentes do cliente TAM são embutidos no WebSphere Application Server
    • 68. TAM é o provedor default JACC para WebSphere
    • 69. O cliente TAM pode ser configurado usando scripts ou a console de administração
    • 70. O servidor TAM pode fornecer função de autenticação
  • Provedor TAM JACCConfiguração - 1
    Próximo slide
  • 71. Provedor TAM JACCConfiguração - 2
    Aceitartodos osDefaults
    Próximo slide
  • 72. Provedor TAM JACCConfiguração - 3
    Servidor
    Politicas
    Servidor
    Autorização
    Porta usado para escutar as atualizações da base de Politicas
    Criado durante a configuração da Segurança WAS
  • 73. Provedor TAM JACCMapeamento Role para Principal
  • 74. Habilitar a segurança das aplicações Java EE
  • 75. DEMO
  • 76. Infraestrutura
  • 77. Integração com Portal
    LDAP
    Portal Legado
    App-Legado
    WebSEAL
    Vignette
    App-Arq3.0
    TAM
  • 78. Modelo antigo-novo
    Usuário
    PapelRA
    F0104158
    RARHUFuncionario
    prhucontroleponto
    prhuconsultahol
    RUPSGFuncionario
    RUPSGColaborador
    PapelRU
    Permissão
    RUPSGFuncionario
    prhucontroleponto
    RARHUFuncionario
    RASYSFuncionario
    prhuregistrarponto
    prhuiniciarweb
    RUPSGFuncionario
    ROLE_RHUPontoApp
    Mesma
    URL
    F0104158
    F3400321
    /rhuapp/registrarponto.do
    /rhuapp/consultalista.do
    Grupo
    RUPSGColaborador
    ROLE_RHUPontoApp
    RoleJEE
    F0104158
    F3400321
    RUPSGFuncionario
    RUPSGColaborador
  • 79. Configuração TAM: grupo
    Referência para grupo LDAP
  • 80. Configuração TAM: user
    Referência para usuário LDAP
  • 81. Nomenclatura
    • Sintaxe
    Papel: RUXXXColaborador, RAYYYAdministrador
    XXX: empresa, diretória, área de negócio
    YYY: identificação do sistema
    Role J2EE: ROLE_YYYAdministrador
    Grupo: RUXXXColaborador
  • 82. Configuração servidores
    li450
    li413
    li412
    TAM
    TAM
    Web SEAL
    Web SEAL
    Dmgr
    Authorization Server
    Authorization Server
    Catalog Server
    Catalog Server
    WAS-Cluster
    Session Manager
    Session Manager
    WAS-Cluster
    Policy Server
    Policy Server
    RHEL-luci
    TSPM
    TSPM
    Dmgr
    TSPM
    TSPM
    WAS-Cluster
    DB2
    DB2
    DB2-Cluster
    TIP
    TIP
  • 83. Introdução a Segurança Web Services
  • 84. Motivos para DataPower
    • XML é a linguagem de web services e SOA
    • 85. XML é onipresente – Em alguns anos, XML estará em qualquer aplicação, equipamento e documento presente nas redes das empresas.
    • 86. Desafios do XML
    • 87. XML é muito ‘falante’
    • 88. XML precisa de muito banda.
    • 89. Tem um impacto direito sobre a performance do servidor de aplicação.
    • 90. O processamento XML precisa de um número significativos de ciclos de processador e de recursos de memória.
    • 91. XML é um texto efetivamente legível por humano
    • 92. Não tem mecanismo nativo de segurança.
    • 93. Fácil de entender e vulnerável a intercepção.
    • 94. A segurança pode ser implementada no servidor de aplicação, mas é um processamento adicional e aumenta o problema de performance.
    • 95. SOA não é somente Web Services e XML
    • 96. Empresas precisam integrar sistemas legados, formatos de mensagens e protocolos numa arquitetura SOA.
    • 97. Necessidade de uma habilidade para transformar sistemas legados em formato XML.
  • O que o DataPower endereça ?
    • Performance XML
    • 98. Como? – transferindo o processamento do XML do servidor de aplicação para o hardware otimizado do DataPower.
    • 99. Por conseqüência, reduzindo o número necessário de servidores de aplicação
    • 100. Segurança XML
    • 101. Como? – transferindo a segurança XML para o DataPower
    • 102. Fornece a segurança padronizada – WS Security
    • 103. Integração XML e sistemas legados
    • 104. Como ? – usando DataPower para transformar XML em formato e protocolo legados de mensagem:
    • 105. XML -> HMTL (renderiza conteúdo HTML para Portal)
    • 106. XML <-> Mensagem MQ
    • 107. Tudo é feito a velocidade de rede
  • Arquitetura com DataPower
    Internet
    Intranet
    DMZ
    Cliente
    Applicações
    Cliente
  • 113. Exposição seletiva
  • 114. XSLT Processor
    XG3 or XG4
    WebSphere DataPower XI50
    Crypto
    Processor
    2 x 160 GB
    HDD
    4GB RAM
    512MB Flash Memory
    512MB Flash Memory
    Serial Port
    4 x 10/100/1000 Ethernet Ports
  • 115. Referência
    Portonet: Home > Departamentos > Informática - Arquitetura de TI > Arquitetura de Software > DocumentosPadrão de Arquitetura de Segurança Java.pdf
    Contatos:
    jose.cardoso@escalainfo.com.br
    philippe.guillaume@portoseguro.com.br
  • 116. Obrigado