Workshop05
Upcoming SlideShare
Loading in...5
×
 

Workshop05

on

  • 460 views

 

Statistics

Views

Total Views
460
Views on SlideShare
460
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Workshop05 Workshop05 Presentation Transcript

  • WorkshopSegurança JEE
  • 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
  • Apresentação
  • 3o pilar da Qualidade da Aplicação Funcionalidade Performance Segurança
  • Problemas Os aplicativos Web são o alvo n° 1 dos hackers quebuscam 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 deaplicativo 80% dos custos de desenvolvimento são gastos naidentificação e correção de defeitos
  • Benefícios Reduz o risco de interrupção, desfiguração ou roubo dedados associados com aplicativos Web Assessora e monitora conformidade da política desegurança em toda a empresa Melhora a conformidade com as normas do setor eexigências regulatórias (por exemplo PCI) Melhora a capacidade de integrar aplicativos críticosdo negócio Teste e controle automatizados durante todo o ciclo devida do desenvolvimento, reduzindo os custos desegurança a longo prazo.
  • 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
  • Ciclo de vida da aplicação Configuração RAD - LDAP Desenvolvimento -TAM Local - WAS7 - PortalPublicação em Replicação Publicaçãohomologação/ configurações em teste produção
  • Arquitetura lógicaWebSEAL Web Container AutorizaçãoServidorPolíticas EJB Container
  • Conceitos de Segurança JEE
  • 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)
  • ProcessoBob Ligação Papel-Permissão Método EJB Método EJB AdministradorAna Método EJB Enterprise Java Bean Solicitante Servlet Corretores jsp Atendente gif, css Segurados Role Segurança ComponentesUsuários/Grupos JEE Web
  • 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 constraintsRequisição Algumautenticada 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
  • 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árioRole  Mapeamento Principal Definido pelo programador da aplicação Definido pelo instalador da aplicação
  • Mapeamento Processos (antigo-novo) Cadastrar papelRU 2 ETrust Papel RU Papel RA Permissão Associar 6 5 4Cadastrar 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
  • Implementando a Segurança JEE
  • Segurança EJB declarativa Implementação de segurança declarativa com Annotation – Lista de annotations EJB • @DeclareRoles • @DenyAll • @PermitAll • @RolesAllowed • @RunAs
  • 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) {
  • Deployment descriptor EJBejb-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
  • Segurança WEBEditor de segurança do RAD: Restringir o acesso a páginas Web com segurança declarativa
  • Informações de segurançaO 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.
  • <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>
  • Configurar roles do EAR emapeamento de roles - 1 Próximo slide
  • Configurar roles do EAR emapeamento de roles - 2
  • Teste da segurança declarativa EJB com JUnit
  • Código para segurançaSystem.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
  • Teste de segurança em EJB
  • Teste a segurança declarativa EJB com Universal Test Client (UTC)
  • Teste da segurança declarativa Web Mapeamento
  • Teste da segurança declarativa Web com o usuário DGADAMS
  • Testar o acesso com o usuário DNARMSTRONG
  • 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)}"/>
  • DEMO
  • Java Authorization Contract for Containers JACC
  • 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)
  • Java Authorization Contract for Containers (JACC)AdministradorAplicaçã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
  • 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
  • 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
  • Provedor TAM JACC Configuração - 1 Próximo slide
  • Provedor TAM JACC Configuração - 2Aceitar Próximo slidetodos osDefaults
  • Provedor TAM JACC Configuração - 3 Servidor Politicas Servidor Porta usado para Autorização escutar as atualizações da base de PoliticasCriado durante aconfiguração daSegurança WAS
  • Provedor TAM JACCMapeamento Role para Principal
  • Habilitar a segurançadas aplicações Java EE
  • DEMO
  • Infraestrutura
  • Integração com Portal LDAP Portal Legado App-Legado WebSEAL Vignette App-Arq3.0 TAM
  • Modelo antigo-novo Usuário PapelRA F0104158 RARHUFuncionarioRUPSGFuncionario prhucontrolepontoRUPSGColaborador 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
  • Configuração TAM: grupo Referência para grupo LDAP
  • Configuração TAM: user Referência para usuário LDAP
  • Nomenclatura Sintaxe – Papel: RUXXXColaborador, RAYYYAdministrador • XXX: empresa, diretória, área de negócio • YYY: identificação do sistema – Role J2EE: ROLE_YYYAdministrador – Grupo: RUXXXColaborador
  • Configuração servidores li412 li450 li413 TAM TAM Web SEAL Web SEALAuthorization 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
  • Introdução a Segurança Web Services
  • 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.
  • 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
  • Arquitetura com DataPowerInternet DMZ Intranet Cliente Applicações • Ameaças XML • Transformação • Controle Acesso • Integração • SLA • Roteamento Cliente
  • Exposição seletiva
  • WebSphere DataPower XI50 Crypto XSLT Processor 2 x 160 GB XG3 or XG44GB RAM Processor HDD 512MB Flash Memory Serial Port 4 x 10/100/1000 Ethernet Ports
  • 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
  • Obrigado