Workshop05

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

3o pilar da Qualidade da Aplicação

 Funcionalidade

 Performance

 Segurança

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

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.

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
- Portal

Publicação em Replicação Publicação
homologação/
configurações em teste
produção

Arquitetura lógica

WebSEAL Web
Container

Autorização
Servidor
Políticas
EJB
Container

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)

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

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

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

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

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
– 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 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>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

– Lista de annotations Web
• @DeclareRoles
• @RunAs

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

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.

<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>
</security-role>

Configurar roles do EAR e
mapeamento de roles - 1

Próximo slide

Configurar roles do EAR e
mapeamento de roles - 2

Teste da segurança declarativa EJB
com JUnit

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

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')}"/>

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)

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

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 - 2

Aceitar Próximo slide
todos os
Defaults

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

Provedor TAM JACC
Mapeamento Role para Principal

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

Integração com Portal

LDAP

Portal Legado

App-Legado

WebSEAL Vignette

App-Arq3.0
TAM

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

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 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

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 DataPower

Internet DMZ Intranet

Cliente

Applicações

• Ameaças XML • Transformação
• Controle Acesso • Integração
• SLA • Roteamento
Cliente

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

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

Workshop05

Mais conteúdo relacionado

Destaque (20)

Semelhante a Workshop05 (20)

Último (8)

Workshop05