Federação CAFe: Provedores de Serviços de Aplicações Federadas

e Pesquisa qualificada como
uma Organizao Social (OS),

sendo ligada ao Ministrio da
Cincia, Tecnologia e Inovao
(MCTI)
responsvel
pelo
Programa Interministerial RNP,
LIVRO DE APOIO AO CURSO
Ldia Aparecida O. Alixandrina

Bacharel em Sistemas de Informao
pela PUC Minas. Atualmente Analista
de Sistemas na UFMG trabalhando na
implantao de diretrios federados
no projeto CAFe. Trabalhou tambm
no desenvolvimento da ferramenta
EID (Export Import Directory). Experincia em autenticao
federativa com Shibboleth, LDAP, Apache Tomcat, Banco de
Dados e Java para Web.
A RNP Rede Nacional de Ensino
O curso foi desenvolvido para auxiliar as instituies

no processo de implantao de um provedor de servios para a Federao Acadmica Federada (CAFe). Tem
como objetivo demonstrar o funcionamento de uma
infraestrutura de autenticao e autorizao federada,
com nfase na autorizao ao uso dos servios pelos
membros da federao. Para isso so apresentadas as
ferramentas de software disponveis para a construo
desta infraestrutura, e o modo de integrao de uma
instituio acadmica ou de pesquisa federao CAFe
como provedor de Servios.
Federao CAFe: Provedores de Servios e Aplicaes Federadas
Edr Quinto Moreira Bacharel e

Mestre em Cincia da Computao
pela Universidade Federal de Minas
Gerais. Entre 2000 e 2003 participou
da implantao do diretrio corporativo da UFMG. Possui grande experincia em autenticao federativa com
protocolo SAML, tendo atuado como assistente 1 no Grupo
de Trabalho Middleware da RNP de 2003 a 2005. Possui
grande experincia com a plataforma JEE, tendo se certificado em programao Java em 2001. Em 2009 participou do
projeto que deu origem Federao CAFe. Participou da
elaborao e desenvolvimento do sistema EID. Atualmente
membro do Comit Tcnico da Federao CAFe. tambm
arquiteto de software no Departamento de Cincia da Computao da UFMG.
que conta com a participao dos
Federao CAFe:
Provedores de
Servios de
Aplicaes
Federadas
ministrios da Educao (MEC), da

Sade (MS) e da Cultura (MinC).
Pioneira no acesso Internet no
Brasil, a RNP planeja e mantm a
rede Ip, a rede ptica nacional
acadmica de alto desempenho.
Com Pontos de Presena nas
27 unidades da federao, a rede
tem mais de 800 instituies
conectadas. So aproximadamente
3,5 milhes de usurios usufruindo
de uma infraestrutura de redes
avanadas para comunicao,
Edr Quinto Moreira

computao e experimentao,
que contribui para a integrao
entre o sistema de Cincia e
Tecnologia, Educao Superior,
Sade e Cultura.
Ministrio da
Cultura
Ministrio da
Sade
Ministrio da
Educao
ISBN 978-85-63630-39-1
Ministrio da
Cincia, Tecnologia
e Inovao
9 788563 630391
A RNP Rede Nacional de Ensino

e Pesquisa qualificada como
uma Organizao Social (OS),
sendo ligada ao Ministrio da
Cincia, Tecnologia e Inovao
(MCTI)
responsvel
pelo
Programa Interministerial RNP,

que conta com a participao dos
ministrios da Educao (MEC), da
Sade (MS) e da Cultura (MinC).
Pioneira no acesso Internet no
Brasil, a RNP planeja e mantm a
rede Ip, a rede ptica nacional
acadmica de alto desempenho.
Com Pontos de Presena nas
27 unidades da federao, a rede
tem mais de 800 instituies
conectadas. So aproximadamente
3,5 milhes de usurios usufruindo
de uma infraestrutura de redes
avanadas para comunicao,
computao e experimentao,
que contribui para a integrao
entre o sistema de Cincia e
Tecnologia, Educao Superior,
Sade e Cultura.
Ministrio da
Cultura
Ministrio da
Sade
Ministrio da
Educao
Ministrio da
Cincia, Tecnologia
e Inovao
Federao CAFe:
Provedores de
Servios de
Aplicaes
Federadas
Edr Quinto Moreira
Federao CAFe:
Provedores de
Servios de
Aplicaes
Federadas
Edr Quinto Moreira
Rio de Janeiro
Escola Superior de Redes
2014
Copyright 2013 Rede Nacional de Ensino e Pesquisa RNP

Rua Lauro Mller, 116 sala 1103
22290-906 Rio de Janeiro, RJ
Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho

Coordenao
Luiz Coelho
Edio
Lincoln da Mata
Coordenao Acadmica de Gesto de Identidade
Renato Duarte Rocha
Equipe ESR (em ordem alfabtica)
Adriana Pierro, Celia Maciel, Cristiane Oliveira, Derlina Miranda, Edson Kowask, Elimria
Barbosa, Evellyn Feitosa. Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos
Lobato e Yve Abel Marcial.
Capa, projeto visual e diagramao
Tecnodesign
Verso
1.0.1
Este material didtico foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dvida com relao ao material ou seu uso seja enviado para a equipe de elaborao de
contedo da Escola Superior de Redes, no e-mail info@esr.rnp.br. A Rede Nacional de Ensino e
Pesquisa e os autores no assumem qualquer responsabilidade por eventuais danos ou perdas, a
pessoas ou bens, originados do uso deste material.
As marcas registradas mencionadas neste material pertencem aos respectivos titulares.
Distribuio
Rua Lauro Mller, 116 sala 1103

22290-906 Rio de Janeiro, RJ
http://esr.rnp.br
info@esr.rnp.br
Dados Internacionais de Catalogao na Publicao (CIP)

F293
Federao caf: Provedores de Servios de Aplicaes Federadas / Edr Quinto

Moreira, Ldia Aparecida O. Alixandrina Rio de Janeiro: RNP/ESR, 2014.

88 p. : il. ; 20,5x27,5 cm.

ISBN 978-85-63630-39-1

1. Provedor de servio. 2. Servio de descoberta. 3. Criptografia de dados (computao).

4. Redes de computadores medidas de segurana. I. Rosseto, Silvana. II. Titulo.
CDD 004.6
Sumrio
A metodologia da ESRvii
Sobre o curso viii
A quem se destinaix
Convenes utilizadas neste livroix
Permisses de usoix
Sobre o autorx
1. Introduo autenticao e autorizao federadas

Contas vinculadas a servios2
Contas desvinculadas dos servios2
Autenticao multi-institucional4
Infraestrutura de autenticao e autorizao federada4
Elementos de uma federao6
Componente adicional de uma federao7
Metadados da federao8
Provedores de Identidade10
Provedores de servio10
Interao entre os elementos de uma federao11
SAML 2.011
Componentes SAML12
Motivao/Vantagens14
SAML 2.0 Web Browser SSO Profile14
iii
Single Sign-On15
Single Logout16
Provedores de servio16
Exemplos de federaes acadmicas19
A Federao CAFe19
Estatsticas Provedores de Servios da CAFe21
Estatsticas Provedores de Identidade da CAFe:21
2. Instalao do Shibboleth SP e do Discovery Service

Shibboleth SP23
Viso geral sobre instalao23
Discovery Service25
Implementaes do Discovery Service25
Discovery Service embarcado26
Discovery Service Centralizado29
3. Configurao do Shibboleth SP 2.4

Certificados31
Arquivo shibboleth2.xml33
Configuraes realizadas no shibboleth2.xml33
Estrutura do arquivo shibboleth2.xml34
Sessions37
SessionInitiator38
Elementos filhos39
Principais configuraes43
Arquivo attribute-map.xml44
Elemento filho45
Arquivo attribute-policy.xml46
Diretivas de log48
Configurao do Apache HTTPD49
Configurao do Apache49
Configurao do Apache Certificados50
iv
4. Configurao de autenticao Shibboleth

Utilizao de autenticao Shibboleth51
Front e back channels52
Autenticao/autorizao via servidor web52
Autorizao via Shibboleth53
Utilizao de autenticao Shibboleth54
Estudo de caso: Moodle54
Pr-requisitos55
Configuraes no Apache55
Configuraes no Moodle55
Group Management Tool (GTM)59
5. Aplicaes Federadas
Mdulo mod_shib61
Opes do mod_shib 62
Protegendo aplicaes62
Formas de proteger aplicaes63
Protegendo toda a aplicao63
Protegendo parte da aplicao64
Lazy sessions 64
Proxy reverso 65
Atributos e mapeamentos65
Autorizao via aplicao66
Configurao para containers JEE68
Configurao para PHP69
Configurao para outras linguagens69
Implementao da autorizao70
6. Configuraes Avanadas do Shibboleth SP

SPs Lgicos e Fsicos71
Razes vlidas pra adicionar um SP lgico71
Quando no h necessidade72
Configurando um SP Lgico72
Configuraes necessrias73
ApplicationOverride73
RequestMapper74
v
vi

A Escola Superior de Redes (ESR) a unidade da Rede Nacional de Ensino e Pesquisa (RNP)
responsvel pela disseminao do conhecimento em Tecnologias da Informao e Comunicao (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competncias
em TIC para o corpo tcnico-administrativo das universidades federais, escolas tcnicas e
unidades federais de pesquisa. Sua misso fundamental realizar a capacitao tcnica do
corpo funcional das organizaes usurias da RNP, para o exerccio de competncias aplicveis ao uso eficaz e eficiente das TIC.
A ESR oferece dezenas de cursos distribudos nas reas temticas: Administrao e Projeto
de Redes, Administrao de Sistemas, Segurana, Mdias de Suporte Colaborao Digital e
Governana de TI.
A ESR tambm participa de diversos projetos de interesse pblico, como a elaborao e
execuo de planos de capacitao para formao de multiplicadores para projetos educacionais como: formao no uso da conferncia web para a Universidade Aberta do Brasil
(UAB), formao do suporte tcnico de laboratrios do Proinfo e criao de um conjunto de
cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).
A metodologia da ESR
A filosofia pedaggica e a metodologia que orientam os cursos da ESR so baseadas na
aprendizagem como construo do conhecimento por meio da resoluo de problemas tpicos da realidade do profissional em formao. Os resultados obtidos nos cursos de natureza
terico-prtica so otimizados, pois o instrutor, auxiliado pelo material didtico, atua no
apenas como expositor de conceitos e informaes, mas principalmente como orientador do
aluno na execuo de atividades contextualizadas nas situaes do cotidiano profissional.
A aprendizagem entendida como a resposta do aluno ao desafio de situaes-problema
semelhantes s encontradas na prtica profissional, que so superadas por meio de anlise,
sntese, julgamento, pensamento crtico e construo de hipteses para a resoluo do problema, em abordagem orientada ao desenvolvimento de competncias.
Dessa forma, o instrutor tem participao ativa e dialgica como orientador do aluno para as
atividades em laboratrio. At mesmo a apresentao da teoria no incio da sesso de aprendizagem no considerada uma simples exposio de conceitos e informaes. O instrutor
busca incentivar a participao dos alunos continuamente.
vii
As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

atividades prticas tm formato presencial e essencialmente prtico, utilizando tcnicas de
estudo dirigido individual, trabalho em equipe e prticas orientadas para o contexto de atuao do futuro especialista que se pretende formar.
As sesses de aprendizagem desenvolvem-se em trs etapas, com predominncia de tempo
para as atividades prticas, conforme descrio a seguir:
Primeira etapa: apresentao da teoria e esclarecimento de dvidas (de 60 a 90 minutos).
O instrutor apresenta, de maneira sinttica, os conceitos tericos correspondentes ao tema
da sesso de aprendizagem, com auxlio de slides em formato PowerPoint. O instrutor levanta
questes sobre o contedo dos slides em vez de apenas apresent-los, convidando a turma
reflexo e participao. Isso evita que as apresentaes sejam montonas e que o aluno se
coloque em posio de passividade, o que reduziria a aprendizagem.
Segunda etapa: atividades prticas de aprendizagem (de 120 a 150 minutos).
Esta etapa a essncia dos cursos da ESR. A maioria das atividades dos cursos assncrona e
realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no
livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dvidas e oferecer
explicaes complementares.
Terceira etapa: discusso das atividades realizadas (30 minutos).
O instrutor comenta cada atividade, apresentando uma das solues possveis para resolv-la,
devendo ater-se quelas que geram maior dificuldade e polmica. Os alunos so convidados a
comentar as solues encontradas e o instrutor retoma tpicos que tenham gerado dvidas,
estimulando a participao dos alunos. O instrutor sempre estimula os alunos a encontrarem
solues alternativas s sugeridas por ele e pelos colegas e, caso existam, a coment-las.
Sobre o curso
O curso foi desenvolvido para auxiliar as instituies no processo de implantao de um
provedor de servios para a Federao Acadmica Federada (CAFe). Tem como objetivo
demonstrar o funcionamento de uma infraestrutura de autenticao e autorizao federada,
com nfase na autorizao ao uso dos servios pelos membros da federao. Para isso so
apresentadas as ferramentas de software disponveis para a construo desta infraestrutura, e o modo de integrao de uma instituio acadmica ou de pesquisa federao CAFe
como provedor de Servios.
Este curso est organizado em 6 captulos.
O captulo 1 apresenta uma viso geral sobre a motivao para o uso de servios federados e
uma introduo ao SAML e plataforma Shibboleth.
O Captulo 2 detalha a instalao do Shibboleth SP e do Discovery Service centralizado
e embarcado.
O Captulo 3 apresenta detalhes de configurao do Shibboleth SP e do servidor Apache HTTPD.
O Captulo 4 detalha como configurar a autenticao e autorizao para acesso s aplicaes e
apresenta a ferramenta Group Management Tool, que pode ser usada para facilitar esse controle.
O Captulo 5 explica como construir uma aplicao que usufrua da autenticao federada,
com exemplos em Java e PHP.
Por fim, o Captulo 6 explica como configurar mais de um Shibboleth SP em uma mesma instalao do software.
viii
A quem se destina
O curso se destina aos tcnicos das instituies que pretendem oferecer servios federados
para seus usurios atravs da integrao destes servios Federao CAFe e tambm aos
interessados em saber mais sobre autenticao federada e a Plataforma Shibboleth.
Convenes utilizadas neste livro

As seguintes convenes tipogrficas so usadas neste livro:
Itlico
Indica nomes de arquivos e referncias bibliogrficas relacionadas ao longo do texto.
Largura constante
Indica comandos e suas opes, variveis e atributos, contedo de arquivos e resultado da sada
de comandos. Comandos que sero digitados pelo usurio so grifados em negrito e possuem
o prefixo do ambiente em uso (no Linux normalmente # ou $, enquanto no Windows C:\).
Contedo de slide q
Indica o contedo dos slides referentes ao curso apresentados em sala de aula.
Smbolo w
Indica referncia complementar disponvel em site ou pgina na internet.
Smbolo d
Indica um documento como referncia complementar.
Smbolo v
Indica um vdeo como referncia complementar.
Smbolo s
Indica um arquivo de adio como referncia complementar.
Smbolo !
Indica um aviso ou precauo a ser considerada.
Smbolo p
Indica questionamentos que estimulam a reflexo ou apresenta contedo de apoio ao
entendimento do tema em questo.
Smbolo l
Indica notas e informaes complementares como dicas, sugestes de leitura adicional ou
mesmo uma observao.
Permisses de uso
Todos os direitos reservados RNP.
Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra.
Exemplo de citao: MOREIRA, Edr Quinto et al. Federao CAFe: Implantao do Provedor de
Identidade. Rio de Janeiro: Escola Superior de Redes, RNP, 2014.
ix
Comentrios e perguntas
Para enviar comentrios e perguntas sobre esta publicao:
Escola Superior de Redes RNP
Endereo: Av. Lauro Mller 116 sala 1103 Botafogo
Rio de Janeiro RJ 22290-906
E-mail: info@esr.rnp.br
Sobre o autor
Edr Quinto Moreira Bacharel e Mestre em Cincia da Computao pela Universidade
Federal de Minas Gerais. Entre 2000 e 2003 participou da implantao do diretrio corporativo da UFMG. Possui grande experincia em autenticao federativa com protocolo SAML,
tendo atuado como assistente 1 no Grupo de Trabalho Middleware da RNP de 2003 a 2005.
Possui grande experincia com a plataforma JEE, tendo se certificado em programao Java
em 2001. Em 2009 participou do projeto que deu origem Federao CAFe. Participou da
elaborao e desenvolvimento do sistema EID. Atualmente membro do Comit Tcnico da
Federao CAFe. tambm arquiteto de software no Departamento de Cincia da Computao da UFMG.
Ldia Aparecida O. Alixandrina Bacharel em Sistemas de Informao pela PUC Minas.
Atualmente Analista de Sistemas na UFMG trabalhando na implantao de diretrios federados no projeto CAFe. Trabalhou tambm no desenvolvimento da ferramenta EID (Export
Import Directory). Experincia em autenticao federativa com Shibboleth, LDAP, Apache
Tomcat, Banco de Dados e Java para Web.
1
Introduo autenticao e
autorizao federadas
e autorizao interinstitucional; Entender o conceito de federao, seus elementos

principais e sua arquitetura bsica; Conhecer o conceito de federao, seus elementos
principais e sua arquitetura bsica; Saber o que SAML, Single Login e Logout;
Saber de que forma est sendo projetada a federao acadmica brasileira CAFe.
Interao entre os elementos de uma federao; SAML 2.0; Single Sign-On;

Sigle Logout; Provedores de Servios- Handles; Exemplos de federaes acadmicas;
conceitos
Infraestrutura de autenticao e autorizao federada; Elementos de uma federao;
Federao CAFe.
Infraestrutura de autenticao e autorizao federada

Motivao:
11 Disseminao de tecnologias e ferramentas que estimulam o compartilhamento de
recursos, informaes e servios interinstitucionais.
Desafio para as instituies:
11 Desenvolver ambientes seguros e escalveis para permitir que a colaborao visionada acontea de fato.
Exemplos de servios internos:
11 Cadastro de projetos, matrcula de alunos, registro de notas, compartilhamento de
documentos etc.
Exemplos de servios externos:
11 Acesso a bibliotecas digitais, compartilhamento de recursos (ciclos de CPU, espao de
armazenamento), ensino a distncia etc.
11 Uma federao oferece para as instituies a infraestrutura de autenticao e autorizao
necessria para interconectar pessoas e compartilhar recursos, informaes e servios.
q
Captulo 1 - Introduo autenticao e autorizao federadas
objetivos
Aprender sobre demandas para a implantao de uma infraestrutura de autenticao
lUma federao
Este curso foi desenvolvido no escopo do projeto e-AA: Infraestrutura de Autenticao e

Autorizao Eletrnica, idealizado e coordenado pela RNP (Rede Nacional de Ensino e Pesquisa), com a colaborao das instituies: Cefet-MG, Universidade Federal do Cear (UFC),
Universidade Federal Fluminense (UFF), Universidade Federal de Minas Gerais (UFMG) e
Universidade Federal do Rio Grande do Sul (UFRGS). O projeto teve incio em julho de 2007
e sua meta principal criar as condies necessrias para a implantao de uma Federao
Acadmica no Brasil.
A finalidade deste curso capacitar o pessoal de TI das instituies de ensino e pesquisa no
Brasil para implantar e gerenciar em suas instituies um Provedor de Servio.
Uma infraestrutura de autenticao e autorizao federada traz ganhos tanto internos quanto
externos. Os servios disponibilizados internamente pelas instituies exclusivamente para
seus membros podem se aproveitar de um ponto central para autenticao. No contexto
externo, servios compartilhados como Bibliotecas Digitais, servios governamentais etc.
podem utilizar autenticadores j existentes e conhecidos pelos membros das instituies.
A federao oferece os meios necessrios para que essa colaborao, principalmente
externa, seja possvel.
Contas vinculadas a servios

Cada usurio:
11 Mltiplas senhas.
11 Mltiplas contas.
11 Dificuldade de lembrar usurio ou senha.
11 Facilita o roubo de senhas.
Cada servio permite manter sua prpria base de usurios, e gerncia de mltiplas contas
trabalhosa no s para o administrador do servio que dever gerenciar, muitas vezes,
milhes de contas de usurios, manter servios de recuperao de senha e atendimento a
usurios, mas tambm para o usurio que deve recordar vrias senhas e acaba se perdendo
Federao CAFe : Provedores de Servios e Aplicaes Federadas
com tantas contas para diversos servios. Isso se agrava nos casos dos servios que so uti-
lizados raramente. Alm da questo da experincia do usurio, o cadastro de vrias contas

em locais diferentes pode facilitar o roubo de credenciais diminuindo a confiabilidade.
Contas desvinculadas dos servios

Autenticao centralizada.
11 Autenticao fica como recurso administrado por um nico local.
11 Servios tomam conhecimento das senhas.
Autenticao distribuda:
11 Autenticao distribuda entre vrios domnios, formando um crculo de confiana.
11 Servio no toma conhecimento do usurio e senha.
22 Vantagens da autenticao distribuda:
33 Credencial nica compartilhada entre as instituies.
33 Credencial nica para vrios servios.
33 Diminui a carga na administrao de contas externas.
33 Menos senhas a serem recordadas pelos usurios.
acadmica envolve
instituies de ensino
e pesquisa, permitindo
que as pessoas
vinculadas a essas
instituies compartilhem informaes e
recursos, e tenham
acesso a servios
restritos, usando o
vnculo institucional
como critrio bsico
para esse compartilhamento.
Servios
Operador de
Identidade
Servios
Figura 1.1
Autenticao
centralizada.
Servios
Servios
Na figura 1.1, os vrios servios utilizam um ponto central para a gerncia de usurios. Isso
minimiza os problemas citados anteriormente, j que apenas um servio de recuperao
necessrio e o usurio no precisa se recordar de vrias senhas.
Uma questo relevante nesse modelo que os servios tomam conhecimento do usurio e
da senha dos usurios, tornando a arquitetura mais vulnervel a ataques.
Provedor de
Identidade
Servio 1
Servio 2
Provedor de
Identidade
Provedor de
Identidade
A autenticao distribuda transfere todo o esforo da administrao de usurios para os

provedores de identidades. Dessa forma, o servio deve se preocupar apenas em atender
bem suas regras de negcio. Por outro lado, cada provedor de identidade deve se preocupar
em garantir os requisitos de segurana em apenas um ponto.
O fato de o servio no tomar conhecimento das credenciais, usurio e senha, minimiza
possibilidades de ataques.
Na autenticao distribuda, vrios servios localizados em diferentes domnios podem ser
acessados com as mesmas credenciais usando os atributos dos usurios fornecidos pelos
autenticadores nos quais ele confia, permitindo que o administrador do servio no se preocupe com a gerncia de usurios, se dedicando apenas em estabelecer regras pra que os
provedores de identidade possam acessar o servio.
Outra vantagem da autenticao distribuda a escalabilidade, permitindo que outros
servios se juntem rede, aproveitando os autenticadores disponveis, assim como novos
autenticadores podem se juntar rede permitindo que mais usurios tenham acesso aos
servios. Tudo isso com baixssimo custo.
Figura 1.2
Autenticao
distribuda.
Provedor de
Identidade
Autenticao multi-institucional
11 Instituies possuem diretrios independentes para satisfazer necessidades internas.
11 Aplicaes internas podem usar esses diretrios para autenticao.

22 Evita a criao de mais um cadastro de usurios.
11 Federaes se aproveitam das autenticaes locais j implementadas.
As instituies j possuem (ou deveriam possuir) diretrios internos para autenticar usurios para seus diversos servios (modelo de autenticao centralizada). A ideia central da
federao a de se aproveitar dessas autenticaes, extrapolando o domnio da instituio,
sem comprometer a segurana dos servios.
A experincia do usurio tambm melhorada, uma vez que conveniente para ele a
memorizao de apenas uma forma de autenticao, alm de se autenticarem sempre em
uma interface conhecida e familiar.
Infraestrutura de autenticao e autorizao federada

O que uma Federao?
11 Tipo de rede de confiana que permite facilitar contratos bilaterais entre usurios e
provedores de servios.
11 Implementa o princpio de identidade federada:
22 Instituies implementam mtodos distintos de autenticao, mantendo
a interoperabilidade.
O crescente avano das tecnologias de redes de computadores (em particular da internet)
e o uso dessas tecnologias para a construo de aplicaes que permitem o acesso remoto
(e em tempo real) a diferentes servios trouxe a necessidade de se criar e manter bases de
dados com informaes sobre as pessoas que podem acessar esses servios e definir o nvel
de privilgio. Essa demanda de reconhecimento e validao de acesso dos usurios aos servios pode ser sintetizada em duas etapas denominadas autenticao e autorizao.
O cumprimento das etapas de autenticao e autorizao como etapas fundamentais para
a disponibilizao de um servio implica, normalmente, na necessidade de manuteno de

bases de dados com registros sobre os possveis usurios do servio. A demanda do lado
de quem disponibiliza um servio a necessidade de criar e manter suas prprias bases de
dados de usurios. Do outro lado, para quem usa os diferentes servios disponibilizados, a
demanda a necessidade de criar e manter contas (ou cadastros) para cada servio a que se
deseja ter acesso.
O conceito de federao acadmica visa minimizar as demandas dos provedores e dos usurios de servios disponibilizados por instituies de ensino e pesquisa no que diz respeito
manuteno de informaes usadas para autenticao e autorizao de acesso a esses servios.
A ideia bsica consiste no seguinte: as informaes sobre uma pessoa so mantidas em uma
nica base, gerida por sua instituio de vnculo, cabendo a cada instituio estabelecer seu
modelo de gesto de identidade, isto , de que forma informaes sobre pessoas so mantidas e atualizadas e quais mtodos de autenticao so usados. Os provedores de servio
confiam no modelo de gesto de identidade das instituies e disponibilizam seus servios para
os usurios vinculados a essas instituies, criando assim o princpio de identidade federada.
Universidade A
I/S
Correio eletrnico
I/S
Cluster de servidores
I/S
Biblioteca
I/S
Biblioteca Digital
I/S
I/S
Universidade B
Administrao
I/S
EaD
I/S
I/S
Administrao
e autenticao
do usurio
I/S
Credenciais
Autorizao
Recurso/Servio
As figuras 1.3. e 1.4 ilustram a diferena entre um modelo usual, onde cada servio deve
manter informaes sobre seus possveis usurios, e um modelo onde as informaes sobre
os usurios so concentradas e mantidas em um nico local.
No primeiro caso, a implementao de cada servio deve prever um mdulo adicional para
tratar o registro dos usurios que podem acess-lo, e cada pessoa precisa ter um cadastro
(usurio/senha) para cada servio que deseje acessar. No segundo caso, as informaes
sobre as pessoas so mantidas em um nico local, tipicamente a instituio com a qual
a pessoa mantm seu vnculo principal, e cada pessoa precisa ter apenas um registro
(usurio/senha); nesse caso, a implementao dos servios oferecidos no requer o mdulo
de registro de usurios.
Figura 1.3
Modelo usual de
autenticao.
Sist. Arq. Dist.
Universidade A
Correio eletrnico
I/S
Cluster de servidores
Biblioteca
Biblioteca Digital
Universidade B
Administrao
EaD
I/S
Sist. Arq. Dist.
Administrao
e autenticao
do usurio
I/S
Credenciais
Autorizao
Recurso/Servio
Elementos de uma federao

Uma federao inclui dois elementos:
11 Provedor de Identidade (IdP).

11 Provedor de Servio (SP).
Atores em uma federao:
11 Usurio: deseja usar um recurso protegido.
11 Provedor do recurso: aplicao com um SP instalado.
11 Instituio do usurio: possui um IdP e um processo interno de autenticao.
Uma federao constituda por dois componentes principais:

11 Provedores de identidade: armazenam e gerenciam as informaes sobre pessoas;
11 Provedores de servio: oferecem servios restritos para grupos de usurios.
H ainda um elemento secundrio, chamado servio de descoberta (ou discovery service), que
pode ser usado para facilitar a identificao do provedor de identidades por um usurio no
momento de sua autenticao. Esse elemento est mais ligado ao servio e pode existir ou
no no contexto federado.
Figura 1.4
Modelo de
autenticao
federada.
SP
SP
IdP
IdP
SP
SP
SP
SP
IdP
SP
SP
SP
SP
A figura 1.5 apresenta os principais componentes de uma federao e as associaes entre

eles. Podemos observar que dentro de uma federao possvel definir subgrupos com um
provedor de identidade e um ou mais provedores de servios associados. Essa configurao
pode ser usada para os seguintes casos:
11 Servios internos da instituio, como matrcula de alunos, e-mail, registro de notas,
cadastro de projetos, entre outros exemplos;
11 Servios externos instituio, como o caso de bibliotecas digitais, ensino a distncia,
armazenamento distribudo, entre outros exemplos, podendo ser oferecidos a usurios
ligados a diferentes provedores de identidade.
Componente adicional de uma federao

Where Are You From (WAYF)/Discovery Service (DS).
11 Elemento que centraliza as informaes sobre provedores de identidade de uma

federao.
Como um provedor de servio em uma federao normalmente permite o acesso de
usurios de diferentes instituies, um componente adicional includo na federao para
auxiliar no redirecionamento dos usurios para os seus respectivos provedores de identidade. Esse componente, denominado Where Are You From (WAYF) ou Discovey Service (DS), a
partir do SAML 2, centraliza as informaes sobre os provedores de identidade da federao
e suas localizaes. Ao ser redirecionado para o DS, o usurio seleciona a sua instituio de
origem e, em seguida, passa a interagir com o seu provedor de identidade para fornecer as
suas credenciais.
Figura 1.5
Principais
componentes de
uma federao.
IdP
Metadados da federao
Metadados:
11 Disponibilizado pela federao.

11 Informaes relevantes sobre os IdPs e SPs.
22 Confiana:
33 Certificados.
33 Chaves pblicas.
22 Comunicao:
33 IDs.
33 URLs.
33 Protocolos.
33 Dados de contato para exibio no Discovery Service.
Os metadados estabelecem a confiana entre as partes e so, tecnicamente falando, o
corao da federao. Neles esto descritos endpoints, protocolos e certificados digitais para
conversao entre as partes.
<md:EntityDescriptor entityID=https://service.example.org/
shibboleth validUntil=2010-01-01T00:00:00Z>
<md:SPSSODescriptor protocolSupportEnumeration=urn:oasis:names:t
c:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0
:protocol>
<md:KeyDescriptor>
<ds:KeyInfo xmlns:ds=http://www.w3.org/2000/09/xmldsig#>
<ds:X509Data>
<ds:X509Certificate>
... base64-encoded certificate elided ...
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Location=https://service.example.org/
Shibboleth.sso/SLO/SOAP
Binding=urn:oasis:names:tc:SAML:2.0:bindings:SOAP/>
Shibboleth.sso/SLO/Redirect
Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect/>
Shibboleth.sso/SLO/POST
8
lA federao geralmente mantm

atualizado e distribui
um conjunto de
informaes para
todos os seus
membros. Essas
informaes so
assinadas digitalmente
para garantir a
procedncia e
integridade.
Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST/>
Shibboleth.sso/SLO/Artifact
Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact/>
.
</md:SPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang=en>Example Organization, Ltd.</
md:OrganizationName>
<md:OrganizationDisplayName xml:lang=en>Example Organization</
md:OrganizationDisplayName>
<md:OrganizationURL xml:lang=en>https://service.example.org/</
md:OrganizationURL>
</md:Organization>
</md:EntityDescriptor>
Ficheiro de Metadados
da Federao
Info. IdP
Info. SP
IdP
Info. SP
IdP
SP
Info. IdP
Info. SP
SP
SP
SP
IdP
Info. SP
Info. IdP
SP
IdP
IdP
SP
SP
Info. SP
Info. SP
Info. SP
SP
SP
Info. SP
SP
Info. IdP
SP
SP
SP
Info. SP
Info. SP
Info. IdP
Federao
Identity Provider
IdP
Organizao
Service Provider
SP
Info. SP
Info. SP
Info. SP
Figura 1.6
Ficheiro de
Metadados da
Federao.
Os membros podem aplicar filtros a esse conjunto, reconhecendo apenas as partes com
quem realmente deseja interar. Isso porque a federao facilita o mecanismo de compartilhamento, mas no, necessariamente, fora o relacionamento bilateral entre todas as partes.
Provedores de Identidade
Implementam a poltica interna de gesto de identidade de uma instituio.
11 Atributos dos usurios:

22 Nome, data do vnculo, cargo ocupado, matrcula etc.
11 Mtodo de autenticao:
22 Login/senha, certificados etc.
11 Identificador nico para cada pessoa vinculada instituio.
Os provedores de identidade so responsveis por manter as informaes sobre as
pessoas vinculadas a uma instituio, incluindo dados pessoais (nome, data de nascimento,
CPF, nomes dos pais, sexo, data de nascimento etc.) e vnculos internos (data de admisso,
cargo ocupado, nmero de matrcula, nmero VoIP etc.). O provedor de identidade estabelece seu mtodo de autenticao interno e deve garantir que cada pessoa da instituio
tenha um identificador nico.
Provedores de servio
Implementam servios que devem ser disponibilizados para pessoas vinculadas s insti-
tuies. Requerem:
11 Autenticao:
22 Identificao dos usurios do servio.
11 Autorizao:
22 Atributos adicionais do usurio que garantem certos privilgios de acesso.
Foco na implementao do servio, e no na manuteno dos registros dos usurios.
Os provedores de servio oferecem servios de acesso restrito, podendo requisitar ainda
privilgios de acesso baseados em informaes adicionais sobre os usurios (por exemplo,
10
aluno matriculado em determinado curso, professor coordenador de curso etc.). Na implementao do servio so definidos os privilgios de acesso e as informaes adicionais que
sero solicitadas. No cabe ao provedor de servio manter essas informaes, mas apenas
solicit-las aos provedores de identidade e tomar a deciso de autorizao ou no.
Interao entre os elementos de uma federao

WAYF/DS
4
3
2
5
Credenciais
Instituio
do usurio
Handle
Handle
Recurso
Atributos
Figura 1.7
Interao entre
elementos da
federao
(IdP, SP, DS).
Requisio/Resposta HTTP
Redirecionamento HTTP
Conexo servidor/servidor
A interao entre os elementos (atores) de uma federao mostrada na figura 1.7:
11 Passo 1: usurio acessa provedor de servio (SP);
11 Passo 2: o servio apresenta escolhas fornecidas pelo repositrio centralizado Discovery
Service (DS), que lista todos os Provedores de Identidade disponveis para autenticao
na federao;
11 Passo 3: o usurio seleciona o Provedor de Identidade da sua instituio de origem;
11 Passo 4: o usurio redirecionado para o seu provedor de identidade (IdP);
11 Passo 5: o IdP autentica o usurio com o mtodo escolhido pela instituio;
11 Passo 6: o SP recebe garantia de autenticao do usurio pelo IdP;
garantir a privacidade do usurio, apenas so disponibilizados atributos previamente

acordados entre o IdP e o SP;
11 Passo 8: o provedor de servio decide sobre as autorizaes e disponibiliza o servio
para o usurio.
SAML 2.0
Definio:
11 Security Assertion Markup Language SAML.
22 Padro definido pela Organization for the Advancement of Structured Information
Standards (OASIS), baseado em XML para a troca de autenticao e autorizao de
dados entre um provedor de identidade (IdP) e um provedor de servios (SP).
Histrico:
11 V1.0 se tornou um padro OASIS em novembro de 2002.
11 V1.1 surgiu em setembro de 2003.
11 V2.0 foi anunciado em maro de 2005.
11 Passo 7: se necessrio, o SP requisita atributos adicionais desse usurio ao IdP; para
11
Security Assertion Markup Language SAML 2.0, permite cenrios de autenticao e autorizao baseados na web, incluindo cross-domain single sign-on (SSO), que ajuda a reduzir a
sobrecarga administrativa de distribuir vrios tokens de autenticao para o usurio.
Componentes SAML
O SAML possui os seguintes componentes:
Assertions
11 um pacote de informaes que fornece uma ou mais declaraes feitas por uma autoridade SAML.
11 A Assertion (b07b804c-7c29-EA16-7300-4f3d6f7928ac) foi emitida no tempo 2004-1205T09: 22:05 Z pelo provedor de identidade (https://idp.example.org/SAML2) a respeito
de assunto (3f7b3dcf -1674-4ecd-92c8-1544f346baf8) exclusivamente para o provedor de
servios (https://sp.example.com/SAML2).
11 Exemplo:
<saml:Assertion
xmlns:saml=urn:oasis:names:tc:SAML:2.0:assertion
xmlns:xs=http://www.w3.org/2001/XMLSchema
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
ID=b07b804c-7c29-EA16-7300-4f3d6f7928ac
Version=2.0
IssueInstant=2004-12-05T09:22:05>
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<ds:Signature
xmlns:ds=https://www.w3.org/2000/09/xmldsig#>...</ds:Signature>
12
<saml:Subject>
<saml:NameID
Format=urn:oasis:names:tc:SAML:2.0:nameid-format:transient>

3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:NameID>
<saml:SubjectConfirmation
Method=:oasis:names:tc:SAML:2.0:cm:bearer>
<saml:SubjectConfirmation

InResponseTo=aaf23196-1773-2113-47a-fe114412ab72
Recipient=https://sp.example.com/SAML2/SSO/POST
NotOnOrAfter=2004-12-05T09:2705/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore=2004-12-05T09:17:05
NotOnAfter=2004-12-05T09:27:05>
<saml:Audiencerestriction>
Protocols
So elementos de pedidos/respostas que empacotam as assertions.
O SAML possui vrios protocolos, e o mais importante o Authentication Request Protocol.
No SAML 2.0, o fluxo comea no prestador de servios que emite uma solicitao de autenticao explcita ao provedor de identidade. Um elemento <samlp:AuthnRequest> transmitido para o provedor de identidade pelo SP. O provedor de identidade autentica o usurio
(se necessrio) e emite uma resposta de autenticao, que transmitida de volta para o SP
(atravs do browser).
Artifact Resolution Protocols

A mensagem SAML transmitida por valor ou por referncia. Uma referncia a uma mensagem SAML chamado de um artefato, onde o receptor de um artefato resolve a referncia
atravs do envio de um pedido <samlp:ArtifactResolve> diretamente para o emissor do
artefato, que, em seguida, responde com a mensagem real referenciada pelo artefato.
Bindings
Definem como as mensagens do protocolo SAML so usadas dentro de protocolos de
transporte.
Para Web Browser SSO, o HTTP Redirect Binding e o HTTP POST Binding so comumente
usados. O SP pode usar HTTP Redirect para enviar um pedido, enquanto o provedor de
so frequentemente enviadas diretamente na URL de uma solicitao HTTP GET.
O HTTP Redirect adequado para mensagens curtas, como <samlp:AuthnRequest>, j
que o tamanho de uma URL limitado. As mensagens mais longas (exemplo: aqueles que
contm assinaturas de asseres SAML) devem ser transmitidas atravs de outros bindings,
como o HTTP POST.
Exemplo de formulrio XHTML enviado pelo SP via HTTP POST Binding:
<form method=post action=https://idp.example.org/SAML2/SSO/POST

...>
<input type=hidden name=SAMLRequest value=request />
... other input parameter....
<input type=submit value=Submit />
</form>
identidade usa HTTP POST para transmitir a resposta. As mensagens do protocolo SAML
13
Profiles
Como combinar os bindings, protocols e assertions SAML para casos de uso especficos.
Motivao/Vantagens
11 Neutralidade da plataforma.
11 Fraco acoplamento de diretrios.

11 Melhor experincia on-line para usurios finais.
11 Reduo de custos administrativos para o SP.
11 Transferncia de riscos.
Ao utilizar o protocolo SAML 2.0, podemos destacar a interoperabilidade: o protocolo
totalmente neutro e funciona em qualquer plataforma, permitindo que o provedor de identidade fique livre para escolher qual tecnologia usar, sendo indiferente para o provedor de
servios essa escolha. Dessa forma, um mesmo servio poder ter diversos tipos de autenticao (usurio/senha, certificados etc.), j que cada provedor de identidade pode optar pela
tecnologia de autenticao.
O provedor de servios por sua vez no dever se preocupar em administrar a base de
potenciais usurios para seus servios, transferindo todo esse custo administrativo para o
provedor de identidade.
O usurio final do servio tambm ser beneficiado com o uso de uma nica credencial e
ambiente de autenticao familiar, onde poder ter acesso a diversos servios providos
pela federao.
Implementaes de SAML 2:
11 Shibboleth 2.0.
11 Google Apps APIs.
11 Oracle Identity Management.
11 Simple SAML php.
14
11 Python SAML2.
11 ...
O protocolo SAML2 possui diversas implementaes. Entre as mais conhecidas est
o Shibboleth e o Simple SAML php.
SAML 2.0 Web Browser SSO Profile

O diagrama ilustra a sequncia de funcionamento do SSO na autenticao de um usurio
via federao. Como atores, temos o provedor de servio, o usurio que acessa o servio e o
provedor de identidade que autenticar o usurio que requisita acesso ao servio.
Service Provider
User Agent
Identity Provider
Request target resource

Discover the IdP
Redirect to SSO Service

Request SSO Service
3
4
Request Artifact Resolution Service
Request with SAML Authn Request

(Identify the user)
Redirection to Assertion Consumer Service
6
7
Figura 1.8
Diagrama
Web Browser
SSO Profile.
Request Assertion Consumer Service
Request Artifact Resolution Service
Request with SAML Authn Request
10
Redirection to target resource
11
Request target resource
12
Respond with requested resource
Single Sign-On
A autenticao Single Sign-On (SSO) permite que um usurio se autentique apenas uma
vez em seu domnio de origem e use essa autenticao nos demais domnios de um
sistema distribudo.
Identity Provider
Ser
reconhecido
Figura 1.9
Single Sign-On.
Service Provider
O Single Sign-On permite que o usurio, logando-se apenas uma vez em seu provedor de
identidade, seja reconhecido como autenticado por outro servio que solicite a autenticao
no mesmo IdP; isso vlido para a mesma seo do navegador web.
O servio recebe o mesmo handle criado durante a autenticao, necessitando apenas solicitar os atributos e decidir pela liberao de acesso ou no. Para o usurio, isso transparente, j que no precisa informar novamente seus dados para autenticao.
Login
15
Single Logout
11 Logout de todas as aplicaes iniciadas pelo usurio.
11 Problemas:
22 Ao acionar o logout, nem todas as aplicaes so encerradas.
22 Problema com experincia do usurio.
22 Falta de segurana.
22 Acesso malicioso a servios.
O SSO oferece uma melhoria significativa de usabilidade. Por outro lado, introduz um
grande problema, que o single logout (ou SLO). Dado que as aplicaes esto em domnios
diferentes, como determinar se o usurio deseja fazer o logout apenas daquela aplicao
ou de todas? Como ter certeza de que o logout foi realmente feito em todas as aplicaes
(o protocolo SAML2 fornece pouca informao)? Essas e outras questes sempre recaem
em um mesmo direcionamento ao usurio que devem encerrar o navegador web para que
todas as informaes atreladas sua sesso sejam limpas.
Provedores de servio
Handles disponveis no Shibboleth SP:
11 So configurados no arquivo shibboleth2.xml.
11 Podem ser acessados via navegador.
11 Auxiliam em testes e debugs do SP.
Handles disponveis no Shibboleth SP.
11 Metadata Generation Handler:
22 Gera metadados de amostra com base na configurao do SP.
22 Type=MetadataGenerator.
22 URL para acesso: https://SERVIDOR/Shibboleth.sso/Metadata.
22 Entre os atributos disponveis para configurao, vamos destacar o https (boolean).
22 Fora ou desativa a gerao de parmetros de protocolo usando o esquema https,
16
independentemente de qual esquema usado ao acessar o manipulador.

11 Handles disponveis no Shibboleth SP:
22 Status Handler.
22 Gera um xml sobre o estado operacional do SP e algumas informaes
de configurao.
22 Type= Status.
22 URL para acesso: https://SERVIDOR/Shibboleth.sso/Status.
22 Informaes retornadas podem ser consideradas confidenciais por alguns implantadores (verso do SP e S.O.).
22 Um atributo importante o ACL para impedir acesso indevido a esse Handler,
atravs desse atributo, possvel restringir o acesso por IPs.
O elemento <Handler> usado para configurar manipuladores genricos do SP que
oferecem funcionalidades diversas que no se enquadram nas categorias abrangidas por
outros elementos pr-definidos.
O arquivo de Metadados fornecido por esse Handler pode ser gerado atravs da utilizao de
um arquivo modelo, e suporta assinatura. O metadata gerado por esse handler no recomendado para uso em ambientes de produo por no ser to completo. A ideia que seja
usado na gerao de exemplos teis para compreenso de como produzir metadados reais.
Implementaes maduras, muitas vezes, necessitam de contedo de metadados que

vo alm do que o manipulador pode gerar.
Access Control List (ACL) responsvel por listar os endereos IP permitindo restringir o
acesso a um determinado grupo a sua configurao padro permitir o acesso. A partir de
V2.5, o uso de Classless Inter-Domain Routing (CIDR) e endereos IPv6 passou a ser suportado.
A seguir um exemplo do uso do atributo ACL para limitar o acesso apenas para o servidor local:


<Handler type=Status Location=/Status acl=127.0.0.1/>
11 Session Handler.
11 Exibe informaes da sesso de um usurio especfico para auxiliar no debug.
11 Type= Session.
11 URL para acesso: https://SERVIDOR/Shibboleth.sso/Session.
11 Um atributo importante showAttributeValues (boolean). O padro false, que indica
se os valores dos atributos sero exibidos.
11 O Atributo ACL para limitar acesso tambm est disponvel, mas apenas informaes
do prprio usurio so exibidas, ento no relevante seu uso.
Exemplo de configurao do Handler no arquivo Shibboleth2.xml:

showAttributeValues=false/>
Outro atributo disponvel o contentType no formato string, que seleciona o tipo de contedo da resposta, afetando o formato de sada. O padro, como nas verses mais antigas,
uma pgina HTML simples.
Para uso em programao, o valor application / json suportado, fazendo com que o resultado seja uma estrutura JSON.
11 Discovery Feed Handler (A partir da verso 2.4).
22 Exibe informaes dos IdPs disponveis nos Metadados em uma estrutura JSON.
22 Type=DiscoveryFeed.
22 URL para acesso: https://SERVIDOR/Shibboleth.sso/DiscoFeed.
22 Discovery Service Embarcado utiliza-se desse Handler.
<Handler type=Session Location=/Session
17
11 Attribute Checker Handler (A partir da verso 2.5).

22 Valida a sesso de um usurio com uma lista de atributos obrigatrios (e, opcionalmente, seus valores), pode retornar o usurio para completar o processo de login
ou exibir uma pgina de erros personalizada.
22 type=AttributeChecker.
22 URL acesso: https://SERVIDOR/Shibboleth.sso/AttributeChecker.
22 Esse manipulador projetado para complementar a configurao sessionHook,
aproveitando para verificar os atributos necessrios.
Atravs do arquivo gerado pelo DiscoFeed, algumas aplicaes, como o Discovery Service
embarcado, obtm a lista de IdPs disponveis para autenticao no servio.
Os atributos validados podem ser especificados de duas maneiras:
Uma lista de IDs de atributos esperados pelo SP:
<Handler type=AttributeChecker Location=/AttrChecker

template=attrChecker.html
attributes=eppn displayName flushSession=true/>
Pela incorporao de uma poltica de controle de acesso vlido dentro do elemento:
<Handler type=AttributeChecker Location=/AttrChecker

template=attrChecker.html
flushSession=true>
<AND>
<Rule require=eppn/>
<Rule require=displayName/>
</AND>
18
</Handler>
A ltima opo permite a verificao da sesso com combinaes booleanas de atributos e
valores. Por exemplo, em vez de exigir que todos os atributos de um conjunto devem estar
presente, uma opo <OR> pode ser utilizada.
Atributos:
11 Template (caminho local): especifica o caminho para um template para a pgina de
erros que deve ser usada no caso de a verificao falhar. Os atributos da sesso esto
disponveis e podem ser usados atravs de tags <shibmlp attrID />;
11 flushSession (boolean): por padro, est atribudo o parmetro false; se for true, a
sesso do usurio finalizada fora se a validao falhar;
11 attributes (lista delimitada por espaos em branco de IDs de atributos): especifica
uma lista de atributos para procurar. Se a sesso no contm pelo menos um valor para
cada atributo designado, a validao falha.
sessionHook:
attributo da tag
<RelyingParty> que
especifica um local para
enviar o cliente depois
que uma sesso foi
criada (ou seja, aps
o login), mas antes de
transferir o cliente para
o eventual recurso final.
Um exemplo comum a
verificao de atributos
necessrios. uApprove
por exemplo um
aplicativo que faz essa
verificao.
11 External Authentication Handler (a partir da verso 2.5).

22 Implementa uma interface REST loopback para a criao de sesses de usurio
com base na lgica de autenticao externa.
22 Type=ExternalAuth.
22 URL acesso: https://SERVIDOR/Shibboleth.sso/ExternalAuth;
22 Por motivo de segurana, no deve ser exposto a qualquer interface de rede.
22 Permite que qualquer interlocutor confivel crie sesses de usurio.
O External Authentication Handler um manipulador que no deve ser exposto a qualquer
interface de rede no confivel. Sua utilizao inadequada pode expor a segurana do
sistema. Ele permite que qualquer interlocutor confivel crie sesses de usurio com base
nas informaes apresentadas.
Possui o atributo ACL, que limita o acesso por IPs, onde o padro liberado apenas para o
servidor local.
Exemplo de configurao do Handler no arquivo Shibboleth2.xml:
<Handler type=ExternalAuth Location=/ExternalAuth />
Exemplos de federaes acadmicas

InCommon:
11 Federao nos EUA, 107 instituies, 2 milhes de usurios.

Feide:
11 Federao na Noruega.
Switch:
11 Federao na Sua.
SDSS:
Federaes acadmicas j so implementadas e mantidas em outros pases. Alguns exemplos: InCommon, Feide, Switch e SDSS. Uma tendncia natural para o futuro ser a juno
de federaes em confederaes, ampliando o escopo de servios disponibilizados aos
usurios e o nmero de possveis usurios de um servio para alm dos limites geogrficos dos pases.
A Federao CAFe
Iniciativa da RNP para criar uma Federao Acadmica no Brasil.
11 Surgiu a partir do Projeto E-AA, iniciado em julho de 2007, envolvendo cinco instituies: UFC, UFMG, UFF, UFRGS e Cefet-MG.
Metodologia adotada:
11 Integrar padres e solues de software utilizados por outras federaes.
11 Desenvolver ferramentas auxiliares e definir polticas para a federao.
11 Federao no Reino Unido.
19
No Brasil, os primeiros esforos para a construo de uma federao acadmica resultaram

na criao da Federao CAFe (Comunidade Acadmica Federada), cuja meta prover uma
infraestrutura de autenticao e autorizao para as universidades e instituies de pesquisa brasileiras. A metodologia adotada para a construo da infraestrutura bsica da federao consiste na utilizao de padres e solues de software j disponveis e adotados por
outras federaes, e na implementao e experimentao de ferramentas auxiliares para
apoiar a implantao dos provedores de identidade e de servio. Faz parte, tambm, do
escopo da Federao CAFe o estudo, a proposio, a anlise e a validao de polticas para
regular o seu funcionamento (requisitos mnimos que provedores de identidade e de servio
devero cumprir).
Metadado
RNP
Diretrio LDAP
Recomendao para
obteno de atributos
(e certicados para
autenticao)
Provedor de servio
(membro ou parceiro
externo)
Figura 1.10
Estrutura
Federao
CAFe.
A figura 1.10 mostra a arquitetura bsica utilizada pela Federao CAFe. O componente
WAYF centralizado e mantido pela RNP, mas os provedores de servio tambm podem usar
20
uma aplicao prpria para localizao da instituio de origem dos usurios. Os provedores de servio podero ser implantados nas instituies que j compem a federao,
como provedores de identidade (universidades e instituies de pesquisa) ou podero ser
implantados por membros externos (os quais atuam apenas como provedores de servio).
As polticas definidas para a operao da Federao CAFe estabelecem os critrios para a
incluso de um membro na federao e as obrigaes dos provedores de identidade e de
servio, bem como garantem a preservao dos requisitos bsicos de privacidade. A recomendao para os provedores de identidade a utilizao de servio de diretrios para a
organizao das informaes sobre as pessoas vinculadas instituio.
11 Provedores de Servios da CAFe:
22 Microsoft Dreamspark.
22 Atlases.
22 Gisela Science Gateway.
11 Portal de Peridicos da CAPES.

11 Portal de vdeo digital.
11 JEMS.
11 PADBR.
11 Readex.
11 GENI.
11 Portal RedCLARA.
11 eduGain (Vrios provedores de servios Internacionais).
Estatsticas Provedores de Servios da CAFe

20
[un.]
15
Figura 1.11
Estatstica
Provedores de
Servio.
18
13
13
14
14
18
18
18
19
19
19
14
10
5
0
jul13 ago13
set13 out13 nov13 dez13
jan14
fev14 mar14 abr14 mai14
jun14
Provedores de Identidade da CAFe:

11 Em junho de 2014, existiam 72 Provedores de Identidade integrados federao
CAFe. A listagem dos IdPs pode ser vista em:
http://portal.rnp.br/web/servicos/instituicoes-clientes.
Estatsticas Provedores de Identidade da CAFe:

75
71
65
65
60
57
57
65
72
65
60
[un.]
55
50
45
Figura 1.12
Estatstica
Provedores de
Identidade.
45
45
48
49
40
35
30
jul13 ago13
set13 out13 nov13 dez13
jan14
fev14 mar14 abr14 mai14
Como aderir Federao CAFe:

11 Como Provedor de Identidade:
http://portal.rnp.br/web/servicos/adesao-a-cafe-como-provedor-de-identidade
11 Como Provedor de Servios:
http://portal.rnp.br/web/servicos/adesao-a-cafe-como-provedor-de-servico
jun14
70
21
22
2
Aprender sobre a instalao do Shibboleth SP e do Discovery Service centralizado
e embarcado.
Implementaes do Discovery Service; Instalao do Discovery Service Embarcado

e Centralizado.
Shibboleth SP
Shibboleth Service Provider:
conceitos
Arquitetura Shibboleth SP; Viso Geral da Instalao do Shibboleth SP;
11 Implementa o protocolo SAML 2.

11 Independente de linguagem de implementao.
11 Mdulo de autenticao para Apache ou IIS.
No insere dependncias nas aplicaes.
O Shibboleth Service Provider (Shibboleth SP) permite que as aplicaes web escritas em
qualquer linguagem de programao ou framework sejam federadas. Integra-se nativamente com servidores web populares, como o Apache e Internet Information Server (IIS).
A estratgia de integrao flexvel e permite a troca de atributos e outros recursos de
valor agregado. Muitas vezes, exige pouca alterao no cdigo da aplicao ou uso de
interfaces proprietrias.
Viso geral sobre instalao

11 Cdigo aberto sob Licena Apache 2.
11 Pode ser compilado para diversas plataformas.
11 Binrios disponveis para algumas plataformas.
22 Instalador para Windows.
22 Instalador RPM.
Captulo 2 - Instalao do Shibboleth SP e do Discovery Service
objetivos
Instalao do Shibboleth SP
e do Discovery Service
23
11 Shibboleth Service Provider.

22 mod_shib.
33 Mdulo do Apache.
22 shibd.
33 Daemon.
Desenvolvido sob a licena Apache 2, o Shibboleth SP implementado em C++ e pode ser
compilado para diversas plataformas. Existem distribuies binrias oficiais para Windows
que utilizam o Apache HTTPD ou IIS, bem como pacotes RPM, para utilizao com Apache
HTTPD em sistemas Linux.
Servios que suportam o Shibboleth SP:
11 Linux;
11 Mac OS X;
lInformaes publicadas
11 Solaris;
11 Windows;
na wiki.shibboleth.net
em janeiro de 2014.
11 Java Servlets.
Recurso
Handle
mod_shib
Apache
Handle
shibd
Atributos
BD
Shibboleth SP
Figura 2.1
Arquitetura
Shibboleth SP.
O shibboleth SP pode ser visto basicamente como dois componentes:

11 mod_shib: um mdulo de autenticao que pode ser facilmente carregado pelo
Apache. Esse componente responsvel por iniciar o protocolo de autenticao;
11 shibd: um deamon responsvel por resolver artefatos como, por exemplo, requisitar
atributos do usurio autenticado.
Pr-requisitos para a instalao

Verificar os pr-requisitos:
1 Sistema Operacional.
1 Base de pacotes de dependncia.
1 Verso do Apache.
1 Verso OpenSSL.
Antes de iniciar a instalao do servio, fundamental verificar todos os pr-requisitos de
sistema. Para a instalao do sistema Shibboleth Service Provider, necessria a instalao

prvia do Apache HTTPD e OpenSSL. Um requisito fundamental para todos os servios
efetuar a configurao do servio de sincronizao de tempo (NTP), evitando problemas de
horrio na comunicao com o Provedor de Identidade.
24
Instalao via pacotes

Com o comando apt-get podemos facilmente instalar as dependncias, uma vez que todos
os pacotes esto disponveis nos repositrios distribudos por padro no Ubuntu.
#apt-get update
#apt-get -y install apache2 libapache2-mod-php5
libapache2-mod-shib2
O mdulo PHP do Apache no necessrio para o funcionamento do Shibboleth.
Faremos aqui a instalao para utilizarmos essa linguagem em outros exemplos
mais adiante.
Discovery Service
Viso Geral:
11 DS (Discovery Service) Verso 2.x.

11 WAYF (Where Are You From) Verso 1.x.
22 Protocolo diferente.
11 Permite a escolha do provedor de identidades para autenticao.
11 Normalmente passa por intermedirio para listagem das possibilidades.
11 Pode tambm redirecionar diretamente para o autenticador.
Como um provedor de servio em uma federao normalmente permite o acesso de usurios de diferentes instituies, um componente adicional includo na federao para auxiliar no redirecionamento dos usurios para os seus respectivos provedores de identidade.
Esse componente, denominado Discovey Service (DS) a partir do Shibboleth 2.x, centraliza as
informaes sobre os provedores de identidade da federao e suas localizaes, obtendo
essas informaes do arquivo de Metadados da Federao. Ao ser redirecionado para o DS,
o usurio seleciona a sua instituio de origem e, em seguida, passa a interagir com o seu
provedor de identidade para fornecer as suas credenciais.
autenticao ao IdP o provedor de servios (SP), e no o intermedirio. Como esse protocolo implementado pelo SP Shibboleth, vivel construir URL que solicita autenticao
diretamente a um IdP.
Implementaes do Discovery Service

Discovery Service Embarcado:
11 Dentro do portal do prprio servio exibida a lista de instituies para escolha
do usurio.
11 Usurio no redirecionado para outra pgina.
11 Melhora a experincia do usurio.
11 Discovery Service Centralizado:
11 Usurio redirecionado para fora da aplicao para escolha do IdP quando login
necessrio.
O protocolo do DS diferencia-se do protocolo do WAYF principalmente porque quem solicita
25
Existem duas abordagens para se implementar o Discovery Service. O modelo embarcado

criado dentro do portal do servio, exibindo uma lista de instituies para escolha do
usurio, fazendo com que o usurio no seja redirecionado para outra pgina, permitindo
melhor experincia. J o modelo centralizado pode ser compartilhado e usado por diferentes aplicaes. Nesse modelo, o usurio redirecionado para fora da aplicao para
escolha do IdP, quando o login necessrio.
Discovery Service embarcado

A figura 2.2 exibe um exemplo de Discovery Service embarcado, usado no site do Provedor
de Servios CAPES. Dentro do prprio portal de peridicos, exibida a lista de instituies
usurias do servio (IdPs). Esse modelo indicado quando se deseja melhor experincia de
uso (evita redirecionamentos excessivos) e apenas um (ou poucos sistemas) no domnio do
SP ser federado, dado que em cenrio oposto cada um dos sistemas necessitaria implementar sua prpria interface, dificultando a manuteno. Por ser proprietrio, possibilita
uma filtragem dos IdPs de interesse do servio.
Figura 2.2
Exemplo de
Discovery Service
embarcado CAPES.
vivel a implementao de uma interface proprietria para atender ao protocolo. Entretanto, existem pacotes disponveis que facilitam a utilizao. Esses pacotes so geralmente
APIs em javascript, que podem ser facilmente usadas pelas aplicaes.
Algumas implementaes de referncia:
11 DiscoJuice;
11 Shibboleth Embedded DS;
11 SWITCH Embedded Discovery Service/WAYF.
11 EDS Embedded Discovery Service Shibboleth:
22 Implementao baseada em Json (Parser).
22 Necessita da verso 2.4 ou superior do Shibboleth SP.
33 Usa DiscoFeed fornecido pelo SP para recuperar a lista de IdPs.
22 Uso de Java Script e Cookies do navegador.
26
Exemplo arquivo DiscoFeed

[
{
entityID: https://idp.curso.rnp/idp/shibboleth,
DisplayNames: [
{
value: IdP Teste - Curso IdP,
lang: en
}
]
},
{
entityID: https://IP_SERVIDOR_SP/idp/shibboleth
}
]
A lista de IdPs exibida no Discovery Service lida no arquivo fornecido pelo Disco Feed do
Shibboleth. O Disco Feed, por sua vez, obtm essas informaes do arquivo de Metadados
da federao configurado no Shibboleth SP. Para visualizar o arquivo do Disco Feed, acesse
a URL https://IP_SERVIDOR_SP/Shibboleth.sso/DiscoFeed. Essa a URL padro em servidor
configurado com Shibboleth SP 2.X.
Arquivos do EDS Shibboleth:
11 index.html
11 idpselect_config.js
11 idpselect.css
O Shibboleth Embedded Discovery Service (EDS) formado pelos arquivos index.html, que
mostram como incorporar o EDS em uma pgina padro pelo arquivo idpselect.js, que
responsvel pelas fontes. Recomendamos que esse arquivo no seja alterado pelo arquivo
idpselect_config.js, responsvel pela configurao (deve ser alterado de acordo com a documentao do sistema), e pelo arquivo idpselect.css cascading style sheets (CSS) para o EDS.
Os arquivos de leiaute, disponveis na instalao padro, podem ser customizados de
acordo com a necessidade da instituio para serem embutidos no site do servio que
estar federado.
11 idpselect.js
27
Exemplo de pgina
<!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EM
http://www.w3.org/TR/html4/loose.dtd>
<html>
<head>
<title>IDP select test bed</title>
<meta http-equiv=Content-Type content=text/html;
charset=iso-8859-5 />
<link rel=stylesheet type=text/css href=idpselect.css />
</head>
<body>
<div id=idpSelect></div>
<script src=idpselect_config.js type=text/javascript
language=javascript></script>
<script src=idpselect.js type=text/javascript
language=javascript></script>
</body>
</html>
Passos para Instalao Shibboleth Discovery Service Embarcado:
11 Baixar arquivos.
11 Descompactar e copiar para o apache.
11 Configurar SSO para usar a url do DSE shibboleth2.xml.
28
<SSO discoveryProtocol=SAMLDS discoveryURL=https://sp.curso.

rnp/embedded-ds/>
SAML2 SAML1
</SSO>
11 Verificar se Shibboleth possui servio DiscoFeed.


<Handler type=DiscoveryFeed Location=/DiscoFeed/>
11 Alterar a pgina do servio inserindo o cdigo do EDS ou testar a partir da pgina de
teste do EDS index.html.
A configurao do WAYF embarcado bastante simples. Basta copiar os arquivos de configurao para o Apache. Porm, necessrio tambm que o provedor de servios esteja
instalado e configurado para utilizar o Discovery Embarcado. A configurao no DE feita no
arquivo Shibboleth2.xml informando a url da pgina principal do servio.
Para usar a verso do Shibboleth DS embarcado, necessrio que a verso do provedor de serhandle:
usado para configurar
manipuladores
genricos do provedor
de Servio que
oferecem funcionalidades diversas que no
se enquadram nas
categorias abrangidas
por outros elementos
pr-definidos.
vios usado tenha suporte ao DiscoFeed, que um handle disponvel nas verses mais recentes
do software que lista todos os IDPs habilitados no arquivo de metadados configurado.
Para navegadores que no suportam JavaScript:
11 Gerar hiperlinks para cada IdP que ser ser exibido no DS.
11 Dados necessrios:
22 URL: a URL base do DS que voc usa.
22 EI: o Entity ID do IdP.
22 RET: seu endereo de retorno para o servio aps o login no IdP.
<href=URL?EntityID=EI&retorno=RET/>
11 Exemplo de hiperlinks para cada IdP
<noscript>
Your Browser does not support javascript. Please use
<a
href=http://federation.org/DS/DS?entityID=https%3A%2F%-
2FyourentityId.edu.edu%2Fshibboleth&return=https%3A%2F%2Fyourreturn.edu%2FShibboleth.sso%2FDS%3FSAMLDS%3D1%26target%3Dhttps%3A%2F%2Fyourreturn.edu%2F>this link</a>.
</noscript>
Discovery Service Centralizado

O DS Centralizado pode ser usado por diferentes servios, evitando que cada um faa sua
implementao. Nesse modelo, interessante quando o servio disponibilizado para
todas as instituies participantes da federao ou se deseja poupar esforos mantendo
interface proprietria. Um exemplo de implementao de DS centralizado o Shibboleth
Discovery Service. A figura 2.3 exibe a pgina de Discovery Service da Federao caf. Esse
Figura 2.3
Exemplo de
Discovery Service
Centralizado
Federao CAFe.
um exemplo de aplicao do Discovery Service Centralizado.
29
Instalao do Discovery Service Centralizado
Requisitos:
11 JDK 1.6 +
11 Tomcat 6.x
Instalao:
1. Download do Discovery Service.
2. Descompactar em algum diretrio.
3. Entrar no diretrio descompactado.
4. Copiar as bibliotecas (Endorse Xerces e Xalan que esto dentro do diretrio
endorsed) para o tomcat ($TOMCAT_ROOT\common\endorsed).
5. Executar o install.sh com usurio root.
6. Configurar o shib-ds para apontar para os metadados de onde carregar a lista de IdPs.
7. Fazer o deploy do Discovery Service.
Ao executar o script install.sh, por padro criada a pasta /opt/shibboleth-ds. A esto
localizados os arquivos de configurao, como o wayfconfig.xml, utilizado para especificar os

arquivos de metadados. Para instalar o servio, necessrio copiar o arquivo discovery.war,
gerado na subpasta war, para a pasta webapps do Tomcat.
Configurao do Discovery Service Centralizado
Apontar para o arquivo de Metadata:

11 Configurao feita em /opt/shibboleth-ds/conf/ wayfconfig.xml
<MetadataProvider displayName=Federation Name

FirstSite
identifier=
url=file:///etc/shibboleth/metadata.
xml/>
Configurar SP para redirecionar para DS
Arquivo Shibboleth2.xml:
<SSO discoveryProtocol=SAMLDS discoveryURL=http://IP_OU_NOME_SER-
30
VIDOR:8080/discovery/WAYF>
SAML2 SAML1
</SSO>
Dentro do arquivo de configurao do Discovery Service, necessrio especificar o caminho

para o arquivo de metadados da Federao. a partir desse arquivo que o servio montar
a lista de provedores de identidade que ser exibida no WAYF. importante ressaltar que
o arquivo de metadados utilizado pelo Discovery Service deve conter, alm dos metadados
dos IdPs, o metadado do SP para uso do Discovery Service. O prximo passo a configurao da tag <SSO > no arquivo shibboleth2.xml.
O Atributo discoveryURL dessa tag dever conter o endereo da pgina do Discovery Service
que ser usado.
3
Conhecer as configuraes bsicas necessrias para a execuo do Provedor
de Servios Shibboleth.
conceitos
objetivos
Configurao do Shibboleth SP 2.4
Configurao do Shibboleth SP, desde a configurao do Apache HTTPD at

a configurao dos arquivos bsicos do Shibboleth Service Provider.
Certificados
11 Objetiva certificar que uma entidade quem diz ser.

11 Baseado em chaves assimtricas.
O objetivo dos certificados garantir a confiabilidade na comunicao entre IdP e SP. No h

a necessidade de que todos os certificados utilizados estejam subordinados a uma autoridade certificadora, tanto para certificados usados para reconhecimento das partes quanto
para os certificados utilizados na configurao do SP.
SSL com Browser
CERTIFICADO
Resource
CERTIFICADO
Webserver
CERTIFICADO
Shibboleth
Service
Provider
SSL com IdP

3
Metadado
Figura 3.1
Certificados
de Instalao
Shibboleth SP.
Federao
Assinatura
CERTIFICADO
CERTIFICADO
Webserver
Shibboleth
Service
Provider
Captulo 3 - Configurao do Shibboleth SP 2.4
Home
Organization
31
O SP usa, basicamente, dois pares de chaves em sua configurao. O primeiro par indicado
no contexto da comunicao do SP com o IdP no momento da troca do handle de autenticao. Nesse ponto, interessante que seu valor no seja interceptado por terceiros, para
evitar ataques. Para tanto, importante que essa comunicao utilize SSL/TLS.
Como a autenticao se d via redirecionamento do SP para o IdP e vice-versa, o endereo
de retorno deve ser protegido por canal seguro. Esse certificado deve ser aceito pelos
navegadores para a efetivao da troca de mensagens. Para evitar mensagens indesejadas
que os navegadores costumam disparar quando a autoridade certificadora emissora do
certificado no reconhecida, interessante que esse certificado seja assinado por uma AC
com raiz reconhecida.
O segundo par utilizado para estabelecer um canal seguro de comunicao do SP diretamente com o IdP, bem como para assinatura de mensagens trocadas entre essas partes.
Como essa comunicao no passa pelo navegador web do usurio, no necessrio que o
certificado seja assinado por alguma AC.
Um terceiro caso de uso de certificados para assinatura dos metadados, de forma que sua
integridade possa ser verificada. Esse, no entanto, decidido pela federao e no pelo SP.
Na Federao CAFe existem requisitos mnimos para a aceitao do par chave/certificado:
11 Nome distinto: o campo Common Name (CN) deve estar preenchido com o nome completo de domnio (FQDN) do servidor;
11 O certificado deve estar vlido (no expirado) e o intervalo de tempo entre os campos
notBefore e notAfter deve ser no mximo igual a 4 anos;
11 Deve ser usado o algoritmo SHA1 com encriptao RSA;
11 Deve ser utilizada uma chave RSA de no mnimo 1024 bits recomenda-se 2048;
11 Deve possuir as extenses digitalSignature e keyEncipherment, acertadas como verdadeiro;
11 O certificado no deve possuir a restrio bsica CA acertada como verdadeiro.
Gerao de certificado com parmetros pr-configurados (openssl.cnf).
11 Gerao da chave:
#openssl genrsa 2048 -config openssl.cnf > `nomekey`.key
32
11 Gerao de certificado autoassinado:
#openssl req -new -x509 -nodes -days 1095 -sha1 -key `nomekey`.
key -set_serial 00 config openssl.cnf > `nomeCert`.crt
O arquivo openssl.cnf j possui as configuraes necessrias para que os certificados

gerados a partir dele cumpram todos os requisitos para aceitao do par chave/certificado
pela Federao CAFe.
Arquivo shibboleth2.xml
11 Define a maioria das configuraes do SP.
11 Foi renomeado para enfatizar a incompatibilidade com o arquivo shibboleth.xml da

verso 1.3
11 Localizao padro:
/etc/shibboleth/shibboleth2.xml
11 Muitos atributos referenciam outros elementos definidos dentro do arquivo.
11 Algumas configuraes realizadas nesse arquivo:
22 Indicao do caminho para arquivos de logs (tags OutOfProcess, InProcess).
22 Identificao do SP (entityID).
22 Indicao dos Metadados dos parceiros (MetadataProvider).
22 Configuraes de Virtual Hosts (RequestMapper).
22 Indicao do caminho da chave e certificado para assinatura e SSL.
O arquivo shibboleth2.xml o principal arquivo de configurao do Shibboleth Service
Provider (SP). Na verso 1.3 do shibboleth, esse arquivo era chamado shibboleth.xml, e foi
renomeado para enfatizar a incompatibilidade entre as duas verses. A maioria das alteraes
nesse arquivo exige o reincio do deamon shibd para que o arquivo shibboleth.xml seja lido.
Muitas vezes so utilizados identificadores para os elementos XML do arquivo, e esses so
referenciados em outras partes. Isso simplifica a configurao por facilitar a pr-configurao de cenrios diferentes e uso desses cenrios em situaes distintas (por exemplo,
uso de pares de chaves distintos para comunicar com diferentes IdPs). Uma das principais
configuraes realizadas nesse arquivo a definio do entityID, que o nome pelo qual o
SP reconhecido pelas entidades federadas.
Configuraes realizadas no shibboleth2.xml

11 Personalizao de pginas de erros.
11 Mapeamento de requisies e suas configuraes.

11 Configuraes especficas para aplicaes.
11 Indicao do IdP para autenticao (WAYF,DS, ou IdP diretamente).
11 Caminho para arquivo de mapeamento de atributos (Attribute-map.xml).
Personalizao de pginas de erros

Alguns problemas comuns na configurao do SP geram erros no acesso aos servios. possvel personalizar a pgina exibida para o usurio com mensagens de erros mais esclarecedoras para auxiliar a resolver o problema.
Mapeamento de requisies e suas configuraes

possvel mapear nesse arquivo as configuraes para as requisies de incio e fim de
sesso, como por exemplo timeout, uso de https etc.
11 Caminho para arquivo de poltica de filtro de atributos (Attribute-policy.xml).
33
Configuraes especficas para aplicaes

Nesse arquivo tambm possvel personalizar as configuraes de incio de sesso para
cada uma das aplicaes protegidas.
Indicao do IdP para autenticao (WAYF,DS, ou IdP diretamente)

possvel definir para aonde o usurio ser redirecionado no momento em que solicitar
acesso ao servio federado: as opes so ir para um Discovery Service que centraliza as
informaes dos Provedores de Identidade parceiros da federao ou ainda ir diretamente
para um provedor de identidade especfico.
Caminho para arquivo de mapeamento de atributos (Attribute-map.xml)

Especifica-se o caminho para o arquivo de mapeamento de atributos recebidos do IdP para
o nome que estar disponvel na aplicao/servio.
Caminho para arquivo de poltica de filtro de atributos (Attribute-policy.xml)

Especifica-se o caminho do arquivo que define a poltica para aceitao dos atributos fornecidos pelos provedores de identidade.
Metadados indicam quais IdPs so reconhecidos

Nos Metadados so listados todos os IdPs que esto disponveis para autenticar usurios via
federao e seus dados.
Pares de chaves podem variar em funo do IdP contatado

possvel definir um par de chave/certificado diferente para a comunicao com determinado Provedor de Identidade.
Estrutura do arquivo shibboleth2.xml

O arquivo shibboleth2.xml, como a prpria extenso sugere, um arquivo que deve seguir
a sintaxe XML. A estrutura do arquivo definida de forma rgida, sendo validada contra um
esquema XML quando carregado. Qualquer erro de validao impede que o servio se inicie.
<SPConfig xmlns=urn:mace:shibboleth:sp:config:2.0
xmlns:conf=urn:mace:shibboleth:sp:config:2.0
xmlns:md=urn:oasis:names:tc:SAML:2.0:metadata
logger=shibboleth/syslog.logger clockSkew=180>
<Extensions/>
<OutOfProcess logger=shibboleth/shibd.logger/>
<InProcess logger=shibboleth/native.logger/>
<Listener/>
<StorageService/>
<SessionCache/>
<ReplayCache/>
<ArtifactMap/>
34
<RequestMapper/>
<ApplicationDefaults id=default policyId=default

entityID=https://sp.example.org/shibboleth
homeURL=https://sp.example.org/index.html/>
<SecurityPolicies/>
</SPConfig>
RequestMapper
11 Define as pginas que sero protegidas pelo shibboleth.
22 Equivalente ao recurso <Location> do Apache.

11 Permite ao SP isolar-se das diferenas de servidores.
11 Mapeia cada requisio s configuraes especficas de cada aplicao
(Atributo applicationId).
11 Elemento filho: RequestMap.
O RequestMapper define quais sero as pginas protegidas pelo shibboleth e sua funo
equivalente ao recurso Location do Apache. Ele permite que o SP se isole das diferenas de
servidores, fazendo com que a configurao seja portvel e funcione tanto em servidores
Apache quanto ISS e outros. feito o mapeamento de cada requisio s suas configuraes
especficas para cada aplicao usando o atributo applicationId. Possui uma funo importante para proteger aplicaes no Internet Information Services (IIS).
O Apache HTTPD tambm pode ser utilizado, porm existe um conjunto de diretivas
necessrias nos arquivos de configurao deste ltimo.
RequestMap
Atributos:
11 Herda os atributos do elemento raiz RequestMapper.

11 Deve conter um atributo applicationId com o valor default.
Elementos filhos:
referncia para outro ApplicationDefaults.

11 AccessControl Controle de acesso:
22 <htaccess>
22 <AccessControlProvider>
22 <AccessControl>
O RequestMap possui o atributo applicationId, que mapeia o contexto da requisio e
identifica qual a configurao que se aplica a ele. Os elementos filhos Host e Path indicam
o contexto ao qual a configurao se aplica e o elemento filho AccessControl pode ser
usado para definir regras bsicas de autorizao baseadas em aplicao de regras sobre
os atributos do usurio.
11 <Host> configurao de virtual hosts, pode redefinir o atributo applicationId com
35
Essa seo do arquivo monitorada pelo deamon e pode ser alterada com o servio ligado,
aplicando as configuraes feitas.
O exemplo de configurao a seguir define o virtual host admin.example.org e protege
o contexto secure com o shibboleth. Alm disso, o elemento <AccessControl> define uma
regra para controle de acesso onde apenas usurios que possurem o atributo affiliation
igual a faculty@osu.edu ou student@osu.edu tero acesso ao contexto.
<RequestMap applicationId=default>
<Host name=www.example.org>
<Path name=secure authType=shibboleth requireSession=true/>
</Host>
<Host name=admin.example.org applicationId=admin
authType=shibboleth requireSession=true>
<AccessControl>

<Rule require=affiliation>
faculty@osu.edu
student@osu.edu

</Rule>
</AccessControl>
</Host>
</RequestMap>
ApplicationDefaults
Id:
11 String obrigatrio.
36
11 Identificador nico do ApplicationDefaults, deve ter o valor default.

entityID:
11 URI obrigatrio.
11 o identificador nico SAML para nomear o SP.
PolicyId:
11 String obrigatrio.
11 Referncia para o elemento Policy definido dentro do elemento <SecurityPolicies>.
O container ApplicationDefaults abriga as configuraes de um SP, especificando o comportamento padro e atuando como um recipiente para quaisquer outros elementos <ApplicationOverride> (que ser visto mais adiante). Deve conter pelo menos um desses elementos
no arquivo shibbioleth2.xml, com o valor do atributo id sendo default.
O elemento raiz ApplicationDefaults deve definir o entityID indicando o nome com o qual
o SP se apresentar para os pares. A definio do entityID feita da seguinte forma no
arquivo shibboleth2.xml:

entityID=https://MEU_SP/shibboleth-sp
REMOTE_USER=eppn persistent-id targeted-id
signing=false encryption=false>
O valor do atributo entityID pode ser definido como string, e deve ser nico no conjunto
de todos os SPs e IdPs. comum utilizar o formato de URL para garantir a unicidade, por
exemplo, https://< MEU_SP >/shibboleth-sp.
Um mesmo SP pode identificar-se de formas variadas em diferentes contextos, o que pode
ser feito com elementos ApplicationOverride.
REMOTE_USER:
11 Atributo que ser mapeado como cabealho REMOTE_USER.

11 Lista de strings delimitada por espaos.
11 Atributos listados em ordem de precedncia.
Signing:
22 true, false, front ou back (default false).
11 Controle de assinatura de envio de mensagens XML.
Encryption:
11 true, false, front ou back (default false).
11 Controles de criptografia de envio de mensagens XML.
Outro atributo interessante aqui presente o REMOTE_USER, que indica quais atributos
recebidos pelo SP sero mapeados no cabealho da requisio HTTP. Dada a lista de possibilidades, o primeiro atributo no vazio encontrado mapeado dessa forma. Muitos servios
usam esse atributo em seus mecanismos de identificao do usurio (uPortal um exemplo).
O atributo signing indica se a assinatura de mensagens XML requerida ou no, ou se
requerida em um caso particular (front channel ou back channel). J o atributo encryption
Sessions
<Sessions lifetime=28800 timeout=3600 checkAddress=false
handlerURL=/Shibboleth.sso handlerSSL=false
exportLocation=http://localhost/Shibboleth.sso/GetAssertion
exportACL=127.0.0.1 idpHistory=false idpHistoryDays=7>
<SessionInitiator/>
<md:AssertionConsumerService/>
<LogoutInitiator/>
<md:SingleLogoutService/>
<md:ManageNameIDService/>
semelhante, e possui a funo de controlar a encripo de mensagens.
37
<md:ArtifactResolutionService/>
<Handler/>
</Sessions>
O elemento Sessions tipicamente discrimina uma srie de handlers, usados para prover
as funcionalidades-chave do SAML. Esse elemento responsvel pelo comportamento do
Shibboleth SSO. Destacamos alguns atributos desse elemento:
11 handlerURL: indica qual a URL base para acionamento dos handlers do lado do SP;
11 checkAddress: apesar de aumentar a segurana, esse atributo deve ser utilizado com
cautela, pois pode ser fonte de erros quando o usurio utiliza proxy ou NAT. Isso porque
o IdP adiciona a informao do endereo IP do cliente autenticado na assero. Quando
definido como true, o endereo informado pelo IdP confrontado com aquele apresentado pelo cliente, acusando erro caso no coincidam;
11 exportLocation e exportaACL: so usados em conjunto para possibilitar o acesso
assero SAML associada sesso.
A partir da verso 2.4, esses elementos foram reagrupados em trs grandes grupos <SSO>,
<Logout> e <NamIDMgmt>. Essa organizao permite uma melhor diviso por tipo de servio.
SessionInitiator
Exemplo padro baseado nas verses anteriores 2.4, direcionado para IdPs especficos,
SAML2 sobre Shib1.
<SessionInitiator
type=Chaining Location=/Login isDefault=true id=Intranet
relayState=cookie entityID=https://idp.curso/idp/>
<SessionInitiator
type=SAML2 defaultACSIndex=1 template=template.html/>
<SessionInitiator
type=Shib1 defaultACSIndex=5/>
38
</SessionInitiator>
Exemplo usando o estilo antigo do WAYF, onde o Shib 1 utiliza uma nica entityID.
<SessionInitiator
type=Chaining Location=/WAYF id=WAYF relayState=cookie>
<SessionInitiator
type=SAML2 defaultACSIndex=1 template=template.html/>
<SessionInitiator
type=Shib1 defaultACSIndex=5/>
<SessionInitiator
type=WAYF defaultACSIndex=5 URL=https://wayf.org/WAYF/>
</SessionInitiator>
O elemento SessionInitiator indica como ocorrer o incio da sesso. O parmetro Location
indica o handler responsvel por atender ao pedido de login e est associado aos handlers
habilitados para o elemento Sessions.
Vrios desses elementos podem ser definidos para uso em cenrios diferentes:
11 Em um contexto federado, interessante passar por um Discovery Service, o que configurado em um iniciador de sesso;
11 Em uma intranet, o mesmo servio pode remeter o usurio diretamente ao IdP. Isso
tambm uma configurao de iniciador de sesso.
Uma forma de indicar qual SessionInitiator ser utilizado definir o atributo
ShibRequireSessionWith nas configuraes do Apache HTTPD ao proteger uma aplicao
com autenticao Shibboleth.
Elementos filhos
<SSO> (Verso 2.4 e superiores).
11 Substitui o elemento < SessionInitiator> usando em verses anteriores.

Um exemplo bsico utilizando suporte ao protocol SAML:
<SSO
entityID=https://idp.example.org/idp/shibboleth>
SAML2
SAML1
</SSO>
Um exemplo usando um SAML Discovery Service:
<SSO
discoveryProtocol=SAMLDS
discoveryURL=https://examplefederation.org/DS>
SAML2 SAML1
</SSO>
Na verso 2.4 e superiores do Shibboleth SP, o elemento Session Initiator foi substitudo por
com seus valores padro.
<Errors>
11 Configuraes de manipulaes de erros ocorridos na aplicao.
<Errors
session=sessionError.html
metadata=metadataError.html
access=accessError.html
ssl=sslError.html
localLogout=localLogout.html
globalLogout=globalLogout.html
<SSO>. Alguns atributos foram ocultos, mas continuam sendo definidos na configurao
39
supportContact=root@localhost
logoLocation=/shibboleth-sp/logo.jpg
styleSheet=/shibboleth-sp/main.css/>
O Elemento Errors pode ser usado tanto para definir padres de pginas que sero apresentadas em caso de erro, quanto para redirecionar o usurio para outros locais que faro um
tratamento especial para cada tipo de erro.
<RelyingParty>
11 Sobrescreve definies personalizando o comportamento relacionado com a comunicao para provedores de identidade ou grupos especficos de provedores.
<RelyingParty
Name=SpecialFederation
keyName=SpecialKey
authtype=basic
signing=true
encryption=true
timeout=3600
signedAssertions=true/>
O elemento <RelyingParty> permite ao SP personalizar seu comportamento quando
interage com um provedor de identidades particular ou com um grupo de provedores
de identidade. Por padro, vrias propriedades so definidas globalmente no elemento
ApplicationDefaults. Esse elemento possibilita que sejam sobrescritas seletivamente.
Se o elemento Name estiver presente, o processo de casamento para identificao do
RelyingParty a ser usado comea com o identificador do IdP e continua com o identificador
dos metadados ao qual pertence. O casamento mais interno vence.
40
Dessa forma, pode existir a configurao de um elemento desses para comunicao com
um IdP especfico, outro utilizado para qualquer IdP de uma federao e um terceiro para
utilizao com qualquer outro IdP.
Notify:
11 Configura notificao de logout da aplicao.
<Notify
Channel=front
Location=https://#YOUR_HOSTNAME#/#PATH_TO#/logout.php />
O elemento Notify pode ser usado para notificar operao de logout ou um evento de alterao no NameID enviado pelo IdP.
Um caso tpico de uso forar o logout em um IdP especfico quando a sesso terminada
no SP (possvel apenas quando se usa apenas um IdP para autenticao). Vale notar que isso
no o SLO, mas pode ser usado em uma intranet.
MetadataProvider.
11 Metadados dos provedores de identidade reconhecidos.
<MetadataProvider type=Chaining>

<MetadataProvider type=XML
uri= http://feder.org/federation-metadata.xml
backingFilePath=federation-metadata.xml reloadInterval=7200>
<MetadataFilter type=RequireValidUntil
maxValidityInterval=241920/>
<MetadataFilter type=Signature certificate=fedsigner.pem/>
</MetadataProvider>

<MetadataProvider type=XML file=idp-metadata.xml/>
</MetadataProvider>
O elemento MetadataProvider indica para o SP quais so os IdPs confiveis e permite que
os elementos possam ser definidos nesse arquivo, onde cada um carrega os metadados de
pontos distinto. Existem duas maneiras de definir um MetadataProvider:
11 Informando uma URL para baixar o arquivo de metadata;Referenciando o prprio
arquivo mantido localmente.
Os metadados podem ser assinados e permitir que suas assinaturas sejam verificadas
durante a recarga. possvel definir filtros nos metadados, tanto de black list (IdPs bloqueados) quanto de white list (IdPs aceitos).
TrustEngine.
11 Mecanismo utilizado pelo SP para autenticar as mensagens.
<TrustEngine type=ExplicitKey />

<TrustEngine type=PKIX />
</TrustEngine>
Esse elemento indica de onde sero extradas as informaes de chaves utilizadas, desde
SSL/TLS at verificao de assinaturas em XML. A ExplicitKey extrai as chaves para confiar
diretamente do metadado do par.
PKIX extrai os identificadores das chaves (nomes dos certificados) a confiar dos metadados
do par, mas tambm extrai conjuntos de ncoras confiveis de extenses especiais dos
metadados e aplica a validao do caminho de certificao.
<TrustEngine type=Chaining>
41
AttributeExtractor:
11 Como atributos SAML so decodificados e expostos para os aplicativos.

11 Referencia o arquivo attribute-map.xml.
<AttributeExtractor type=XML path=attribute-map.xml />

No arquivo attribute-map.xml feito o mapeamento do nome dos atributos recebidos do IdP
para o nome em que estaro disponveis no SP e na aplicao protegida.
O Shibboleth SP disponibiliza os atributos de duas formas: variveis de ambiente (padro
do Shibboleth por ser mais seguro) ou cabealhos HTTP (menos recomendado o uso).
Para receber os atributos via cabealhos http, necessrio habilitar essa opo no apache
usando a propriedade: ShibUseHeaders On.
CredentialResolver.
11 Configura a chave privada e o certificado usados pelo SP para identificar-se aos Provedores de Identidade.
<CredentialResolver type=File key=sp-key.pem

certificate=sp-cert.pem />
Ou
<CredentialResolver type=File>
<Key>
<Path>/etc/shibboleth/sp.key</Path>
</Key>
42
<Certificate>
<Path>/etc/shibboleth/sp.crt</Path>
</Certificate>
</CredentialResolver>
no elemento CredentialResolver que se referencia o par chave/certificado usado para
assinar as mensagens SAML enviadas pelo Shibboleth. Podem ser configuradas chaves e
certificados nos formatos PEM, DER ou PKCS12.
<ApplicationOverride>
11 Elementos <ApplicationOverride> herdam todas as configuraes do elemento
<ApplicationDefaults>, mas tambm podem substitu-los.
11 Configurar aplicaes com comportamento diferente do padro.
11 Alguns atributos do <ApplicationDefaults> se tornam opcionais para o
<ApplicationOverride>.
<ApplicationDefaults>
...
<ApplicationOverride id=other-app entityID=https://other.org/
shibboleth>
<Sessions lifetime=28800 timeout=3600
checkAddress=false
handlerURL=/otherapp/Shibboleth.sso
handlerSSL=false
exportLocation=http://localhost/Shibboleth.sso/
GetAssertion
idpHistory=false idpHistoryDays=7>
</ApplicationOverride>
...
</ApplicationDefaults>
Esse elemento possibilita vrias configuraes de SP em uma nica instalao do servio.
O elemento define, minimamente, o atributo entityId, que como o servio ser apresentado para a outra parte.
Principais configuraes
<RequestMapper type=Native>
<Host name=service.university.org
authType=shibboleth
requireSession=true/>
<Host name=other.university.org applicationId=otherapp authType=shibboleth
</RequestMapper>
entityID=https://service.university.org/shibboleth
homeURL=https://service.university.org/welcome/ REMOTE_USER=eppn
persistent-id targeted-id signing=false encryption=false>
[...]

<ApplicationOverride id=other-app
entityID=https://other.org/shibboleth/>
</ApplicationDefaults>
</RequestMap>
43
O ApplicationOverride permite que qualquer requisio recebida para o servidor virtual

other.university.org use as configuraes definidas pelo applicationId other-app. Nesse caso,
o SP se apresentar como https://other.org/shibboleth. A figura 3.2 apresenta como os elementos RequestMap, Host, ApplicationDefaults e ApplicationOverride se relacionam.
SHIBBOLETH2.XML
RequestMapper
RequestMap
ApplicationDefaults
Host
ApplicationOverride
Figura 3.2
Estrutura
do arquivo
Shibboleth2.xml.
Arquivo attribute-map.xml
11 Extrao e mapeamento de atributos das asseres SAML para as variveis de
ambiente ou cabealhos HTTP.

11 Tag Attribute.
22 Mapeia o atributo extrado em uma varivel ou cabealho HTTP.
22 Atributo name Corresponde ao nome SAML formal usado para o atributo no IdP,
geralmente um URI.
22 Atributo id nome abreviado, determina a varivel de ambiente ou cabealho
HTTP pelo qual o atributo ser disponibilizado para o aplicativo.
<Attribute name=urn:oid:2.5.4.42 id=givenName/>

<Attribute name=urn:mace:dir:attribute-def:givenName
id=givenName/>
O arquivo attribute-map.xml mapeia atributos que chegam na assero SAML em variveis
de ambiente ou headers HTTP nas requisies. Qual forma ser utilizada no regulada por
esse arquivo, mas em configurao do servidor HTTP.
Apache/cabealhos http:
11 Shibboleth 2 no recomenda o uso de cabealhos HTTP.
11 Variveis de ambiente o padro, por serem mais seguras.
11 Para ativar o uso de cabealhos HTTP, ativar a property.
Exemplo Apache:
<Location /homologa>
AuthType shibboleth
ShibRequereSession On
44
require valid-user
ShibUseHeaders On
</Location>
Para que atributos sejam passadas para atributos da requisio em aplicaes JEE utilizando
o protocolo AJP, importante ajustar o valor do atributo attributePrefix do elemento
ApplicationDefaults para AJP_, caso contrrio, os valores no so passados.
O uso de cabealhos desencorajado por poderem ser definidos diretamente no navegador
web do cliente; entretanto, alguns servios habilitados para shibboleth podem exigir que
os atributos estejam ali disponveis. Nesse caso, necessrio habilitar a passagem com a
diretiva ShibUseHeaders On.
Elemento filho
AttributeDecoder.
22 Tag opcional que indica o extrator que ser utilizado para realizar a extrao das
Asseres SAML.
22 Utilizados para extrair atributos mais complexos.
<Attribute name=urn:mace:dir:attributedef:eduPersonScopedAffiliation
id=affiliation>
<AttributeDecoder

xsi:type=ScopedAttributeDecoder
caseSensitive=false/>
</Attribute>
Para atributos que so simples strings, no necessrio usar esta tag, mas se os valores
do atributo so mais do que simples strings, um <AttributeDecoder> personalizado precisa
ser fornecido dentro do elemento <Attribute> para indicar como ser feita a extrao.
<Attributes xmlns=urn:mace:shibboleth:2.0:attribute-map
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
<Attribute name=urn:mace:dir:attribute-
<AttributeDecoder xsi:type=ScopedAttributeDecoder />

</Attribute>
<Attribute name=urn:oid:1.3.6.1.4.1.5923.1.1.1.6 id=eppn>
<AttributeDecoder xsi:type=ScopedAttributeDecoder />
</Attribute>
<Attribute name=urn:mace:dir:attributedef:eduPersonScopedAffiliation id=affiliation>
<AttributeDecoder xsi:type=ScopedAttributeDecoder
caseSensitive=false/>
def:eduPersonPrincipalName id=eppn>
45
</Attribute>
...
<Attribute name=urn:oid:2.5.4.42 id=givenName/>
<Attribute name=urn:mace:dir:attribute-def:givenName
id=givenName/>
</Atributes>
O trecho do arquivo de configurao exibe o mapeamento de alguns atributos. O atributo
name indica o nome do atributo como enviado pelo IdP, j id especifica o nome do atributo
ou header que ser passado para o servidor http. Nesse exemplo temos duas definies
para o atributo givenName: o motivo manter a compatibilidade com a verso 1.x do
SAML que utiliza o padro name=urn:mace:dir:attribute-def:NOME_ATTR. J a verso
SAML2 utiliza o padro name=urn:oid:x.x.x.x.x.
Arquivo attribute-policy.xml
11 Configurao da poltica de aceitao de atributos do SP com relao ao IdP.
11 Primeira parte do arquivo define regras para aceitao.
value=staff />
</afp:PermitValueRule>
11 Caso o valor da string case com um dos valores faculty, student ou staff,
a regra aceita.
<afp:PermitValueRule
id=eduPersonAffiliationValues xsi:type=OR>
<Rule xsi:type=AttributeValueString value=faculty />
<Rule xsi:type=AttributeValueString value=student />

<Rule xsi:type=AttributeValueString
O IdP pode definir quais atributos sero enviados e para quais SPs. Da mesma forma, o SP pode
definir regras de aceitao de atributos para cada Idp, validando inclusive, seus valores. No
arquivo attribute-policy.xml so definidas as regras de aceitao e validao. As regras podem ser
gerais sendo aplicadas as todos os IdPs, quanto podem ser especficas para um conjunto de IdPs.
Num primeiro momento devem-se definir as regras de aceitao de valores para os atributos.
Operadores em regras de aceitao:
11 ANY: sempre avalia para True.
11 AND: avalia como True se todas as regras so verdadeiras.
11 OR: avalia como True se qualquer regra contida verdadeira.
11 NOT: avalia como True se a regra contida avalia como falso.
11 AttributeRequesterRegex: avalia como True se o atributo ID da entidade requerente
satisfaz determinada expresso regular.
11 AttributeValueString: avalia como True se o valor de um determinado atributo corresponde a uma dada string.
46
Vrios operadores podem ser utilizados na definio das regras de aceitao para o valor
dos atributos. Em particular, a regra ANY usada para aceitao de qualquer valor fornecido
para o atributo, enquanto que a regra OR indica que o atributo ser aceito se o seu valor
pertencer a um conjunto indicado. A rejeio de atributos no causa erros no SP, sendo
nesse caso filtrados e no sero repassados para o servidor HTTP.
Segunda parte do arquivo mapeia a regra definida com um atributo especfico ou grupo
de atributos.
11 Atributo attributeID contm o nome do atributo ao qual a regra se aplica idntico ao
especificado no arquivo attribute-map.xml.
<afp:AttributeFilterPolicy>
<afp:PolicyRequirementRule xsi:type=ANY/>
<afp:AttributeRule attributeID=affiliation>
<afp:PermitValueRule xsi:type=AND>
<RuleReference ref=eduPersonAffiliationValues/>

<RuleReference ref=ScopingRules/>
</afp:AttributeRule>
<afp:AttributeRule attributeID=unscoped-affiliation>
<afp:PermitValueRuleReference ref=eduPersonAffiliationValues/>
</afp:AttributeFilterPolicy>
As regras definidas para aceitao de atributos individuais so amarradas em polticas de
aceitao, onde podem envolver o mtodo utilizado para autenticao.
<afp:AttributeFilterPolicyGroup xmlns=urn:mace:shibboleth:2.0:afp:
mf:basic xmlns:basic=urn:mace:shibboleth:2.0:afp:mf:basic xmlns:a
fp=urn:mace:shibboleth:2.0:afp xmlns:xsi=http://www.w3.org/2001/
...
<afp:PermitValueRule id=ScopingRules xsi:type=AND>
<Rule xsi:type=NOT>
<Rule xsi:type=AttributeValueRegex regex=@ />

</Rule>
<Rule xsi:type=saml:AttributeScopeMatchesShibMDScope
xmlns:saml=urn:mace:shibboleth:2.0:afp:mf:saml />
<afp:AttributeFilterPolicy>
XMLSchema-instance>
47
<afp:PolicyRequirementRule xsi:type=ANY/>
<afp:AttributeRule attributeID=affiliation>
<afp:PermitValueRule xsi:type=AND>
<RuleReference ref=ScopingRules />

<RuleReference ref=eduPersonAffiliationValues/>
<afp:AttributeRule attributeID=*>
<afp:PermitValueRule xsi:type=ANY />

</afp:AttributeFilterPolicy>
</afp:AttributeFilterPolicyGroup>
O trecho do arquivo attribute-policy.xml exibe a definio de regras para os atributos
affiliation e todos os outros (*).
Diretivas de log
Arquivos de Log do SP:
11 /var/log/shibboleth
22 shibd.log, shibd_warn.log
22 transaction.log
22 Signature.log
11 /var/log/apache2
22 access.log
22 error.log
48
Arquivos de configurao de Nveis de Logs

11 /etc/shibboleth
22 syslog.logger
22 shibd.logger,native.logger
As diretivas de log podem ser configuradas em sua maioria no arquivo shibd.logger. Os nveis
vo de TRACE (mais fino) a NONE (nenhum log).
O primeiro arquivo possibilita definio dos nveis de log para a comunicao SP/IdP,
possibilitando a anlise at a nvel de asseres SAML trocadas.
Logs gerais do SP so enviados para o arquivo shibd.log, bem como mensagens SAML. Esse
arquivo o que deve ser consultado primeiramente em caso de investigao de problemas.
O arquivo transactions.log apresenta transaes de atributos passados ao servidor HTTP
para cada sesso estabelecida.
Configurao do Apache HTTPD

11 Carregar mdulo mod_shib.
11 Proteger contextos com authType shibboleth.

11 Configurao de SSL normalmente necessrio.
As configuraes que devem ser feitas no Apache HTTPD so mnimas. Basicamente se restringem a carregar o mdulo de autenticao mod_shib e indicar os Location ou Directory
que sero protegidos pelo mdulo.
As configuraes de SSL so necessrias quando a aplicao protegida necessitar dessa
funcionalidade, porm o shibboleth tambm dever ser configurado para utilizar handles
seguros (atributo handlerSSL do elemento Sessions com o valor true).
Devemos ter ateno especial para esse ponto: caso seja configurado para utilizar
SSL, apenas requisies seguras sero tratadas, caso contrrio, apenas requisies
no seguras sero processadas.
Configurao do Apache
Exemplo de configurao de Virtual Host no apache:
<VirtualHost *>
ServerName
$HOSTNAME
ServerSignature Off
# Redirecionamento para SSL

RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [R,L]
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
</VirtualHost>
DocumentRoot /var/www/
49
Esse arquivo faz uso do mod Rewrite do apache para redirecionar todo acesso para a porta
443 com SSL.
Configurao do Apache Certificados

Exemplo de configurao de Virtual Host https:
NameVirtualHost *:443
<VirtualHost ENDEREO_IP:443>
ServerName
servidor.instituicao.br
SSLEngine
on
SSLCertificateFile /etc/shibboleth/nomeCertificado.crt
SSLCertificateKeyFile /etc/shibboleth/nomeChave.key
DocumentRoot /var/www-ssl/
<Location /secure>
AuthType shibboleth
ShibRequireSession On
require valid-user
Order allow,deny
allow from all
</Location>
</VirtualHost>
O certificado configurado no arquivo de virtual hosts o que ser exibido no browser para
o usurio no momento de acesso ao recurso protegido pelo Shibboleth. Aqui aconselhvel
usar um certificado assinado por uma CA reconhecida pelos navegadores para evitar a exi-
50
bio de mensagens de alerta.

Aps a criao dos arquivos de Virtual Host, necessrio habilitar os sites e mdulos:
# a2enmod shib2
# a2enmod ssl
# a2enmod rewrite
# a2ensite shibboleth-sp
4
Entender como feita a configurao da autenticao em aplicaes que j possuem
suporte nativo ao Shibboleth.
Autorizao/Autenticao via servidores web; Configurao de Autenticao Shibboleth

no Moodle; Mapeamento de Atributos do SP para a aplicao.
conceitos
objetivos
Configurao de autenticao
Shibboleth
Utilizao de autenticao Shibboleth

Arquitetura de autenticao Shibboleth:
Where are
3 Ask home server
to authenticate user
You From
(WAYF)
2 Ask user where

he is from
Shibboleth
Shibboleth
Identity Provider
(Idp) / University
Attribute Query
Handler
If not already
5 Request
further attributes
logged on logon
Assertion consumer
Service (ACS)
6 Allow
acess
Single Sign
On Handler
Au
Service Provider (SP) /

Owner of Content
Shibboleth Daemon
Resource
Manager (RM)
thentication
System
Directory
(users)
Web
Server
Protected
Content
Protected
Content
User
1 Request Content
Protected
Content
Protected
Content
Captulo 4 - Configurao de autenticao Shibboleth
Figura 4.1
Arquitetura de
autenticao
Shibboleth.
4 Send handle / ID to service provider

51
Usando o Security Assertion Markup Language 2.0 (SAML2) atravs do web browser SSO
profile, o usurio pode acessar um recurso em um provedor de servios ou acessar um
provedor de identidades, de tal forma que o provedor de servios e o recurso desejado
so conhecidos ou esto implcitos. O usurio se autentica no provedor de identidades que
produz uma assero de autenticao; o provedor de servios consome a assero para
estabelecer um contexto seguro na sesso do navegador web. Durante esse processo, um
name identifier deve ser tambm estabelecido entre os provedores para o principal, sujeito
aos parmetros da interao e ao consentimento das partes.
O name identifier geralmente usado para identificar a pessoa sobre a qual a assero
enviada pelo IdP versa. Name identifiers podem ser qualquer coisa; um endereo de e-mail
ou um principal name Kerberos so exemplos comuns do dia a dia de tais informaes.
Para implementar esse cenrio, um profile do protocolo SAML Autentication Request
usado em conjunto com o HTTP Redirect, HTTP POST e HTTP Artifact bindings. assumido
que o usurio est usando um navegador comercial padro e pode se autenticar em um
provedor de identidades por algum meio fora do escopo do SAML.
Front e back channels

Front channel.
11 Comunicao via web browser.

Back channel.
11 Comunicao por contato direto IdP/SP.Os conceitos de front e back channel so
comuns em se tratando de SAML. Nos protocolos que utilizam o front channel a comunicao feita via redirecionamento do navegador web do usurio. Um exemplo de
comunicao fronte channel o envio da assero de autenticao do IdP para o SP.
O back channel usa normalmente um canal seguro para troca direta de informaes entre
as partes, utilizando um web service. A solicitao de atributos do usurio geralmente feita
via back channel, como um tipo de resoluo de artefato (o SP envia o handle do usurio e o
IdP resolve os atributos). Outras implementaes de SAML, como o SimpleSAMLPhp, usa o
front channel para envio dos atributos, juntamente com a assero de autenticao.
52
Autenticao/autorizao via servidor web

Apache
11 Autenticao gerenciada nas diretivas <Directory>, <File> ou <Location>.
22 Arquivos .htaccess.
IIS
11 Autenticao gerenciada nas configuraes do Shibboleth.
22 Elemento RequestMapper, shibboleth2.xml.
A autenticao shibboleth pode ser requisitada pela definio de alguns atributos nas
diretivas Directory, Location ou File do Apache. Pode-se, ainda, configurar via arquivos
.htaccess para proteger arquivos e pastas. Nesse servidor pode-se configurar o .htaccess
da seguinte forma:
Location:
11 AuthType shibboleth
11 ShibRequireSession On
11 Require valid-user
<Location /minhaaplicacao>

AuthType Shibboleth

require valid-user
</Location>
No IIS, a proteo deve ser realizada, necessariamente, via elemento RequestMapper do
arquivo shibboleth2.xml. As regras bsicas para autorizao podem ser definidas com o atributo require. importante salientar que todas as requisies feitas atravs dos contextos
protegidos carregaro os atributos obtidos no processo de autenticao, e no apenas a primeira requisio. As requisies realizadas em outros contextos no possuiro tais atributos.
Autorizao via Shibboleth

<htaccess>
11 Permite o uso de comandos familiares do Apache.

11 Funciona apenas no Apache.
<AccessControl>
11 Plugin que implementa uma linguagem simples para controle de acesso usando XML.
11 Suporta combinar regras com os operadores lgicos.
11 Soluo portvel.
A autorizao pode ser definida pelo elemento RequestMap, onde dois elementos so disponibilizados: o <htaccess> e o <AccessControl>. O primeiro s aplicvel ao servidor Apache
HTTPD. O segundo uma soluo portvel entre os servidores.
</Host>
<Host name=admin.org applicationId=admin
authType=shibboleth>
<AccessControl>
<Rule require=affiliation>faculty@osu.edu student@osu.edu</
Rule>
</AccessControl>
</Host>
</RequestMap>
<Path name=secure authType=shibboleth

53
Esse trecho exibe dois exemplos de proteo com shibboleth. No primeiro caso, todas as
requisies feitas para http://www.example.org/secure so protegidas com autenticao
shibboleth. Nenhuma restrio de controle de acesso feita nesse nvel. J no segundo caso,
as requisies feitas para http://admin.org requerem autenticao shibboleth e utilizam as
configuraes de aplicao com id admin (provavelmente derivada de um ApplicationOverride).
Alm disso, definida uma regra de controle de acesso que s permite a passagem de usurios cujo atributo affiliation seja faculty@osu.edu ou student@osu.edu. Uma resposta HTTP
403 dada caso as exigncias no sejam cumpridas.
Utilizao de autenticao Shibboleth

Shibboleth Enabled Applications
22 Ensino a distncia:
33 Moodle, Blackboard, Sakai e OLAT.
22 WIKI:
33 Media Wiki, Confluence Wiki e Dokuwiki.
22 Portal:
33 Uporta e Joomla.
22 Correio eletrnico:
33 SYMPA e Google Apps/Email.
22 Blogs:
33 WordPress.
Vrias aplicaes possuem plugins para realizar autenticao via Shibboleth, o que incentiva
ainda mais a implantao de Provedores de Identidade e do servio na instituio. Essas
aplicaes no precisam ter seu cdigo alterado, sendo necessrias apenas algumas configuraes no Apache HTTPD e na aplicao.
Veremos, a seguir, como isso pode ser feito para o software de ensino a distncia Moodle.
Estudo de caso: Moodle
54
Moodle:
11 Modular Object-Oriented Dynamic Learning Environment.
22 Software livre de apoio aprendizagem em ambiente virtual.

22 Sistema de gesto de aprendizagem.
11 Principais recursos:
22 Chat, glossrio, frum, questionrios e blog.
22 Gesto de contedos.
22 Suporte autenticao Shibboleth.
O Moodle um Learning Management System (LMS) ou Ambiente Virtual de Aprendizagem
(AVA). Ele um aplicativo web gratuito que os educadores podem utilizar na criao de sites
de aprendizado eficazes. Tornou-se muito popular entre os educadores de todo o mundo
como uma ferramenta para criar sites de web dinmicos para seus alunos.
Pr-requisitos
Moodle instalado.
11 PHP 5.
11 Apache22.
11 MySQL 5.
Shibboleth instalado e configurado.
11 IdP.
11 SP.
O software implementado em PHP e utiliza o banco de dados MySQL. As discusses desta
sesso no versam sobre os detalhes de instalao do Moodle. Assumiremos apenas que
foi instalado com sua configurao padro. Alm das ferramentas instaladas neste curso,
faremos uso de um provedor de identidades previamente instalado na mquina do instrutor, alm do banco de dados MySQL e do software Moodle na VM do aluno.
Configuraes no Apache
Arquivo virtual Host do Apache.
11 Localizao: /etc/apache2/sites-enabled
11 Proteger /auth/shibboleth/index.php
<Location ~ /auth/shibboleth/index.php>
AuthType shibboleth
require valid-user
</Location>
11 Possibilidade de usar outras restries
require affiliation student

No caso do Moodle, deve-se proteger uma pgina de login alternativa com o Shibboleth.
A pgina de login via outros tipos de autenticao continua disponvel e outros tipos de
Configuraes no Moodle
11 Acessar Moodle e logar como administrador.
11 Ativar a autenticao Shibboleth no Moodle.
22 Tela principal do Moodle.
autenticao podem ser usados.
55
Figura 4.2
Tela de
Administrao
do Moodle.
Para configurar a autenticao via Shibboleth, necessrio que o adminstrador do Moodle

logue-se e acesse o menu principal de configuraes:
Administrao do site > Plugins > Autenticao > Gerenciar Autenticao.
56
Figura 4.3
Menu do
Administrador
Moodle.
Para encontrar a tela de configurao de Autenticao via Shibboleth, podemos percorrer

todo o menu de configuraes ou ainda possvel optar por pesquisar por Shibboleth na
opo Buscar, localizada abaixo do menu, para que a tela de configurao seja exibida.
11 Ativar a autenticao Shibboleth.
11 Configurar as preferncias.
Figura 4.4
Configuraes
de autenticao
Moodle.
O Moodle possui vrias opes de plugins para autenticao de usurios, entre elas a opo
Shibboleth. Primeiro necessrio ativar a autenticao Shibboleth, clicando sobre o cone
do olho fechado, que exibido. O cone ser alterado para um olho aberto, indicando que a
autenticao est ativa.
Em seguida, deve-se clicar no link de Configuraes para fazer os ajustes de mapeamentos
de atributos e preferncias.
Configuraes:
11 Nome de Usurio;
11 API de modificao dos dados;
11 Moodle WAYF Service;
11 Identity Providers;
11 Shibboleth Service Provider logout handler URL;
11 Alternative logout return URL;
11 Alternative login URL;
11 Authentication Method Name;
11 Pgina de mudana de senha
namento aps o logout da aplicao, a pgina para mudana de senha e a lista de IdPs para o
WAYF (caso seja interessante o uso). Os atributos recebidos do IdP tambm devem ser mapeados para os respectivos dados do perfil de usurio, que criado ou atualizado no Moodle.
O Moodle exige o mapeamento de pelo menos um atributo, que ser usado como identificador do usurio. Esse atributo pode ser, por exemplo, o CPF, e-mail, ou um identificador
opaco do usurio.
Mapeamento de atributos Shibboleth/Moodle:
11 Nome;
11 Sobrenome;
11 Endereo de e-mail;
11 Cidade/Municpio;
11 Pas;
Entre as configuraes para a autenticao Shibboleth, possvel definir a url para redirecio-
57
11 Idioma;
11 Descrio;
11 Pgina Web;
11 Nmero ID;
11 Instituio.
11 ...
Os dados sobre o perfil do usurio podero ser preenchidos automaticamente caso o provedor de identidade que autenticou o usurio os fornea para o SP que hospeda o Moodle.
Mapeamento de atributos Moodle/Shibboleth:
Figura 4.5
Mapeamento
de Atributos
Shibboleth/Moodle.
A figura 4.5 mostra como feito o mapeamento dos atributos recebidos pelo shibboleth SP para
a aplicao Moodle. O nome mapeado deve ser aquele indicado no arquivo attribute-map.xml,
ou seja, o nome local com os quais os atributos so mapeados para o servidor web.
possvel definir se haver a atualizao dos valores retornados para os atributos; essa
atualizao pode ser apenas quando o usurio for criado ou a cada login. Outra opo blo-
quear ou no o valor: quando o atributo est marcado como bloqueado, o prprio usurio
58
no consegue atualizar a informao. Nesse caso, os atributos obtidos pelo processo de

autenticao sempre vo prevalecer.
Mapeamento de atributos Moodle/Shibboleth.
11 Nome do atributo no Shibboleth:
33 Campo que recebe o nome do atributo correspondente mapeado no shibboleth.
11 Atualizao local:
33 Define quando ser realizada a atualizao dos dados, ao logar ou apenas no
primeiro acesso do usurio.
11 Bloquear valor:
22 Define se os dados sero bloqueados para edio do usurio.
Group Management Tool (GTM)

11 Funo de criar e gerenciar grupos de usurios.
11 Aplicao web PHP.

11 Cdigo aberto (licena BSD).
11 Informaes podem ser usadas.
22 Via arquivo .htaccess.
22 Via arquivo de controle de acesso XML AccessControl.
22 Via interface PHP ou Perl por outras aplicaes.
O GMT tem como principal caracterstica a gesto de grupos federados. uma aplicao
web desenvolvida pela SWITCH para criar e gerenciar grupos de usurios Shibboleth de
diferentes provedores de identidade. A informao de grupos pode ser usada por outras
aplicaes web para decises sobre controle de acesso.
Isto feito, por um lado, gerando arquivos .htaccess para restringir acesso a diretrios do
servidor web baseado em um identificador nico do usurio. Por outro lado, a informao
de grupo pode ser requisitada por um servidor remoto via interface PHP ou Perl.
A Figura 4.6 mostra a interface principal do aplicativo Group Management Tool. A partir
desta tela possvel verificar quais grupos esto cadastrados e se possuem arquivos de
autorizao vinculado ao grupo.
Recursos do aplicativo Group Management Tool:
11 Gerir vrios grupos para vrias aplicaes;
11 Trs funes de usurio/administrador com privilgios diferentes;
11 Transferncia de privilgios para outros usurios;
11 Convidar novos usurios para participar de um grupo via e-mail;
11 Usurio pode pedir para participar de um grupo (autoinscrio);
11 Gerar arquivos de autorizao (Apache .htaccess);
11 API para uso em mquinas remotas.
Figura 4.6
Tela principal
aplicao GMT.
59
60
5
Aprender as diferentes formas de implementar a autenticao Shibboleth em
uma aplicao.
conceitos
objetivos
Aplicaes Federadas
Autenticao Shibboleth em aplicaes; Recuperao de atributos Shibboleth em

diferentes linguagens.
Mdulo mod_shib
11 Parte da arquitetura Shibboleth acoplada ao servidor web.
11 No caso do servidor web Apache, esse acoplamento ocorre atravs do mdulo mod_shib.
11 Configurao similar aos mdulos mod_auth_basic e mod_ssl.
Servidor de Aplicaes
Apache
shibd
mod_proxy
O mod_shib usado para proteger as aplicaes web no Apache HTTPD. Esse mdulo
trabalha em conjunto com o deamon shibd para atender ao protocolo SAML2. De forma
simplificada, o mod_shib usado para interceptar as requisies do usurio e o shibd para
atender ao protocolo SAML2 (resoluo de artefatos, por exemplo).
Podem ser protegidos elementos do tipo <Files>, <Directory> ou <Location> atravs do
arquivo de configurao do apache ou atravs de um arquivo .htaccess.
<Location /diretorio>
AuthType shibboleth
ShibRequireAll On
require mail ~.*@ufmg.br$
</Location>
Captulo 5 - Aplicaes Federadas
Figura 5.1
Arquitetura
Shibboleth SP.
61
A configurao pode ser realizada nos arquivos de virtual hosts do apache ou em arquivos
.htaccess. Nesse exemplo o diretrio protegido pelo Shibboleth ser acessado apenas por
usurios que possuem o email com domnio ufmg.br.
Opes do mod_shib
Principais diretivas:
11 require
22 require valid-user
22 require shibboleth
11 ShibRequireAll on/off
11 ShibRequireSession on/off
11 ShibUseHeaders on/off
11 require valid-user: o recurso poder ser acessado desde que j exista uma seo iniciada;
11 require shibboleth: decises sobre o acesso ao recurso dependem das configuraes
encontradas no RequestMapper do shibboleth2.xml.
11 ShibRequireAll on/off:
22 on: so feitas operaes AND entre as regras;
22 off: so realizadas operaes OR entre as regras (default).
ShibRequireSession on/off: determinar quando necessrio exigir uma sesso Shibboleth
para acessar um recurso. Quando configurado com o valor off, a aplicao tem de disparar a criao de uma seo quando necessrio;
ShibRequireSessionWith <id>: indica que o session initiator para aquele contexto deve ser
aquele identificado por <id>;
ShibUseHeaders on/off: o Shibboleth 2.0 usa por padro as variveis de ambiente em vez
dos cabealhos HTTP para incrementar a segurana. No h diferena para a maioria das
aplicaes, a no ser quando h uma estrutura de proxy e forwarding;
62
Protegendo aplicaes
O modo como uma aplicao federalizada depende de algumas caractersticas
do sistema:
11 Disponibilidade do cdigo-fonte.
11 Aplicao pblica com privilgios para usurios autenticados.
11 Necessidade de dados do usurio na aplicao. Respondendo a estas questes
possvel definir qual a melhor estratgia para proteger a aplicao com Shibboleth.
11 Disponibilidade do cdigo fonte: dependendo de como construdo o objeto de usurio
e dada autorizao a ele, pode ser necessrio alterar esse mecanismo;
11 Aplicao pblica com privilgios para usurios autenticados: alguns tipos de aplicaes disponibilizam todo o contedo para navegadores annimos, entretanto, usurios
autenticados podem ter mais privilgios, dependendo de suas autorizaes. Blogs e wikis
so casos tpicos desse modelo;
11 Necessidade de dados de usurio na aplicao: algumas aplicaes podem necessitar

apenas que o usurio seja autorizado de alguma forma, sem, contudo, criar efetivamente
um contexto para ele. Esse tipo de sistema pode ser facilmente federalizado pela solicitao de autenticao shibboleth e restrio de acesso a pessoas autorizadas,
com autorizao definida a nvel de servidor web.
Formas de proteger aplicaes

11 Toda a aplicao.
11 Toda a aplicao com o mecanismo de lazy sessions.

11 Somente a pgina que cria uma sesso na aplicao.
page
page
login
page
page
page
login
Figura 5.2
Formas de proteger
uma aplicao com
Shibboleth.
page
page
page
login
Protegendo toda a aplicao

Soluo mais simples.
11 Todo acesso requerido deve ser feito mediante autenticao shibboleth.
11 Desvantagem: no h nenhuma parte da aplicao acessvel sem autenticao.
<Location /aplicacao>
AuthType shibboleth
require valid-user
</Location>
q
page
63
A soluo de proteger toda a aplicao tambm no atende para o caso de uma aplicao
que precisa ter outros mtodos de autenticao. A soluo adequada para controle de
acesso a contedos estticos ou para aplicaes que necessitem de autenticao prvia
para todas as operaes. uma soluo no amigvel, porque nenhuma home page
exibida antes do login.
Protegendo parte da aplicao

Este mtodo permite que a autenticao Shibboleth seja acionada somente quando necessria.
<Location /aplicacao/login.php>
AuthType shibboleth
require valid-user
</Location>
Neste exemplo apenas a pgina login.php protegida pelo Shibboleth. As outras pginas da
aplicao no tm esse requisito.
Essa forma tambm interessante em casos onde vrios mtodos de autenticao so
suportados; a pgina em questo seria apenas uma forma de criar a sesso do usurio com
atributos provindos da autenticao shibboleth. Outras partes do sistema podem requerer
apenas que exista uma sesso estabelecida para o usurio ou podem ser, ainda, pblicas.
Por suportar bem outros tipos de autenticao, uma das solues mais indicadas.
Lazy sessions
11 Proteo via regras baseadas na URL do recurso.
11 Verificao de sesso pelas variveis de ambiente.

11 Redirecionamento explcito para SessionInitiator.
11 O controle de acesso fica completamente por conta da aplicao.
64
11 Url: https://servidor/Shibboleth.sso/Login?target:http://servidor/applicacao.
Lazy sessions muito usado quando um site possui acesso pblico e privado para os mesmos
recursos. til para aplicaes dinmicas que tipicamente desejam oferecer um modo guest
por padro e iniciar um login de usurio apenas quando escolhido pelo usurio.
Funciona da seguinte forma: o recurso protegido por Shibboleth, mas no requer uma
sesso ativa. Assim, as requisies passam normalmente, mas se o usurio no foi autenticado, as variveis de ambiente ou cabealhos HTTP no so mapeados. A aplicao faz a
verificao da presena de tais informaes (atributos personalizados, REMOTE_USER etc.)
para decidir pela autorizao ou no.
Quando o usurio deseja criar sua sesso, a aplicao deve disparar explicitamente um redirecionamento HTTP para a URL indicada pelo handler de SessionInitiator com alguns parmetros.
Usado em:
11 Aplicaes que tm funcionalidades que no necessitam de sesso de usurio todo o tempo;
11 Aplicaes que suportam vrios mecanismos de autenticao.
<Location /aplicacao>
AuthType shibboleth
ShibRequireSession Off
require shibboleth
</Location>
Proxy reverso
nica opo vivel para uma aplicao proprietria onde o mtodo de autenticao no
pode ser adaptado ao Shibboleth.
Figura 5.3
Protegendo
aplicao com
Proxy Reverso.
Shibboleth SP
mod_proxy
apache
Aplicao
O mtodo de proxy reverso usado quando a aplicao no suporta autenticao

Shibboleth nativamente. Aplicaes JEE so o caso tpico. Nesse cenrio, todas as chamadas so interceptadas pelo servidor Apache, que ento repassa as chamadas para a
aplicao. No caso de aplicaes JEE, esse repasse feito via protocolo AJP.
nica opo vivel para uma aplicao proprietria onde o mtodo de autenticao no
pode ser adaptado ao Shibboleth.
ProxyPass /app http://Servidor/app

<Location /app>
AuthType shibboleth
ShibRequireSession ON
require shibboleth
</Location>
O mtodo de proxy reverso usado quando a aplicao no suporta autenticao Shibboleth
nativamente. Aplicaes JEE so o caso tpico.
Nesse cenrio, todas as chamadas so interceptadas pelo servidor Apache, que ento
repassa as chamadas para a aplicao.
Atributos e mapeamentos
Atributos:
11 Representam informaes relativas ao usurio como nome, e-mail, filiao etc.
11 Podem ser disponibilizados pelo SP para a aplicao atravs de variveis de ambiente
ou cabealhos http.
11 As aplicaes podem utiliz-los para realizar a autorizao de usurios.
No caso de aplicaes JEE, esse repasse feito via protocolo AJP.
65
Os cabealhos HTTP so inseguros, pois so podem ser gerados a partir do navegador web,
podendo ser forjados. As variveis de ambiente web so disponibilizadas aplicao diretamente pelo servidor, impedindo essa possvel falsificao.
Variveis de ambiente web so padro no Shibboleth2. Nem todos os servidores suportam
variveis de ambiente web, como o caso do IIS.
Mapeamentos:
11 Definem o nome de cabealho ou varivel de ambiente web para cada nome de atributo.
11 So configurados no SP pelo arquivo attribute-map.xml.
11 Exemplo de um mapeamento para o atributo cn:
<Attribute name=urn:mace:dir:attribute-def:cn id=ShibCafe-Person-cn/>

<Attribute name=urn:oid:2.5.4.3 id=ShibCafe-Person-cn/>
11 O atributo name da tag Attribute representa um espao de nome universal.
11 O atributo id define o nome do cabealho HTTP ou varivel de ambiente web a ser fornecida pelo SP.
11 Utilizam-se duas tags para manter compatibilidade entre os protocolos SAML1 e SAML2.
Autorizao via aplicao

11 A estrutura Shibboleth autentica o usurio e fornece os atributos para a aplicao.
11 A aplicao responsvel pela autorizao.

11 Nem a aplicao, nem o servidor HTTP manipulam a senha do usurio.
11 H necessidade de atributos comuns/compatveis entre os IdPs para uma
autorizao global.
Aps a autenticao, o Provedor de Servios (SP) pode solicitar ao Provedor de Identidades (IdP) atributos do usurio. De acordo com a poltica de liberao de atributos
acordada entre IdP e SP, os atributos podem ser liberados para que o SP repasse para a
aplicao. A aplicao, de posse desses atributos, pode utiliz-los para controle de acesso
66
dos usurios. Para que a autorizao seja global (para todos os usurios da aplicao),
necessrio que todos possuam atributos em comum que devero ser utilizados na autorizao de acesso aos recursos.
Definir atributos necessrios para a autorizao e recomend-los s instituies.
IdP B
IdP A
IdP C
SP
Estudantes (autorizados)
Tc. Administrativos
O que fazer se os usurios no possurem atributos em comum?

Algumas possveis solues:
11 Criar atributos em comum;
11 Usar GMT para criao de grupos federados;
11 Usar Unique ID ou email para autorizao (autorizao individualizada no SP).
Atributos disponibilizados pelo esquema brEduPerson que podem ser utilizados para a
autorizao:
11 brEduAffiliationType
22 Tipo de vinculo com a instituio.
11 brEntranceDate
22 Data de incio de vnculo.
11 brExitDate
22 Data de fim do vnculo.
A Federao CAFe recomenda a disponibilizao de alguns atributos e define seus nomes
e semnticas, caso sejam utilizados. Os atributos brEduAffiliationType, brEntranceDate e
brExitDate so atributos interessantes para uzar como base para autorizao para grandes
grupos de usurios. Os tipos de vnculos recomendados no esquema brEduPerson so:
11 Faculty (professores , administradores);
11 Student (estudante);
Figura 5.4
Regras de
autorizao
via atributos.
Professores
Regra:
Aliao: estudante
67
11 Staff (pessoal);
11 Position (coordenador etc.);
11 Scholarshipawardee (iniciao, p ...);
11 Other (contrato de outro tipo).
A autorizao tambm pode ser assistida por uma base relacional proporcionando.
11 Maior flexibilidade:
22 Liberdade na criao das regras de autorizao.
11 Facilidade de Integrao:
22 Maior facilidade no relacionamento com outras bases.
11 Necessidade de manuteno:
22 As regras devem ser criadas e mantidas pela aplicao.
As aplicaes podem manter bases adicionais para controle de acesso. Dessa forma, os
atributos recebidos no processo de autenticao federada podem servir como chave para
busca de autorizao na base local. H um custo adicional para manuteno dessa base,
mas muitas vezes isto necessrio.
Configurao para containers JEE

Para aplicaes Java Web utilizando Tomcat e Apache2:
11 Instalar o mdulo mod_proxy_ajp;

11 Repassar chamadas do Apache para o Tomcat;
11 ProxyPass /minappp ajp://servidor:8009/appjee;
11 Proteger o contexto para criao da sesso de usurio.
<Location /minhaapp>
AuthType Shibboleth
require valid-user
</Location>
68
O Tomcat um servidor web Java, mais puramente, um container web JEE. O mod_proxy_ajp
um mdulo do Apache usado para implementar um proxy reverso entre o Apache HTTPD
e containeres web JEE, que tipicamente respondem ao protocolo AJP.
As requisies so feitas, dessa forma, para o servidor Apache. Este intercepta a chama e
verifica que o contexto necessita autenticao Shibboleth.
Antes da autenticao ser completada, o Apache ainda no tem conhecimento de que tipo
de recurso est sendo solicitado (pgina web, arquivo binrio, imagem, aplicao php, aplicao JE, etc.).
Ao final do processo de autenticao, o Apache HTTPD pode observar que age como um
proxy para a aplicao JEE, o que indicado pela diretiva ProxyPass. A requisio complementada com os atributos obtidos e enviada ao container web via protocolo AJP. O container
web, por sua vez, processa a requisio (possivelmente criando uma sesso para o usurio)
e devolve a resposta para o Apache, que ento a repassa ao navegador cliente.
11 Recuperao via atributos da requisio.
uid = request.getAttribute(ShibCafe-InetOrgPerson-Uid);
11 Recuperao via HTTP header.
uid = request.getHeader(HTTP_SHIBCAFE_INETORGPERSON_UID);
Na aplicao JEE, os atributos podem ser recuperados via atributos da requisio ou via
HTTP headers (caso esta opo esteja habilitada no Apache). Note que via headers os atributos so em maisculo e pr fixados de HTTP.
Configurao para PHP

11 PHP se integra nativamente ao Apache.
11 No necessrio utilizar proxy.

11 Proteo do recurso direta via diretiva Location.
if (isset($_SERVER[HTTP_SHIBCAFE_INETORGPESON_UID]) and
!empty($_SERVER[HTTP_SHIBCAFE_INETORGPESON_UID])){
$uid= $_SERVER[HTTP_SHIBCAFE_INETORGPESON_UID];
$uid= utf8_decode($uid);
// verificao de regras e outros processamentos...
}
else{
// Erro: atributo no encontrado!
}
Em PHP, para ter acesso aos atributos repassados pelo Shibboleth via Headers, necessrio
acrescentar HTTP_ como prefixo e trocar por _ alm de ser em caixa alta.
Exemplo: O atributo mapeado no arquivo attribute-map.xml com nome ShibPerson-cn estar
disponvel no apache via cabealho com o nome: HTTP_SHBPERSON_CN.
Caso seja repassado como varivel de ambiente, estar disponvel com o mesmo nome
mapeado no arquivo attribute-map.xml.
Configurao para outras linguagens

11 Perl:
my $uid = $ENV{SHIBCAFE_INETORGPERSON_UID};
11 Python:
11 ASP:
Set uid = Request(HTTP_SHIB_IDENTITY_PROVIDER);
Os trechos exibem como os atributos definidos pelo Shibboleth podem ser recuperados em
linguagens como Perl, Python e ASP.
uid = environ.get(SHIBCAFE_INETORGPERSON_UID);
69
Implementao da autorizao
Autorizao por vnculo.
11 Autorizao por vnculo;
11 Mapear tipos de vnculo com um nvel de autorizao especfico;
22 Identificar os vnculos da identidade;
11 Consultar o valor do atributo brEduAffiliationType;
11 Realizar autorizao;
22 Comparar o nvel de autorizao da pgina (recurso) com os nveis dos vnculos
da identidade.
Para realizar a autorizao, a aplicao necessita conhecer todos os possveis valores dos
atributos para poder definir as regras de acesso que devero ser aplicadas.
Ser necessrio definir nveis de autorizao para cada um dos vnculos possveis.
70
6
Explorar algumas configuraes avanadas do Provedor de Servios Shibboleth.
conceitos
objetivos
Configuraes Avanadas do
Shibboleth SP
Esta sesso ir demonstrar como simular dois Provedores de Servios lgicos, cada
um se comportando de maneira distinta, em uma nica instalao fsica do software.
SPs Lgicos e Fsicos

11 Uma nica instalao do software SP pode atuar como servios lgicos distintos,
e um nico servio lgico pode abranger qualquer nmero de hosts fsicos.

O primeiro ponto a destacar que o termo Service Provider (SP) como um monte de outras
definies em computao, composto pela parte fsica (os bits de software que voc est
l instalando) e a parte lgica (a noo de um servio).
Para fins de SAML, um SP simplesmente qualquer sistema que est aceitando autenticao
de um IdP. Este sistema pode ser uma centena de servidores web, um nico servidor web,
ou um nico diretrio em um servidor web, isso no est definido.
Alm disso, cada SP tem um nome exclusivo chamado de EntityID que nomalmente uma
URL que se parece com um endereo da web, mas na verdade apenas um identificador
para rotular o SP e identific-lo na Federao.
Razes vlidas pra adicionar um SP lgico

11 Casos em que um SP adicional deve ser definido:
22 Necessidade de simular 2 SPs, alterar o EntityID (ou seja, expondo um SP lgico

adicional a partir de uma nica instalao fsica);
22 Metadados diferente ou poltica de segurana (Certificados);
22 Diferente mapeamento de atributo ou regras de filtragem por servio;
22 Regras diferentes para o comportamento de sesses, tal como o tempo de espera.
Antes de fazer a configurao de um SP lgico necessrio analisar se realmente h
necessidade. Em Alguns casos apenas com configuraes personalizadas possvel atender
algumas demandas especficas para alguma aplicao sem a necessidade de definir um novo
Captulo 6 - Configuraes Avanadas do Shibboleth SP
O conceito de SP representa apenas alguma

coleo de recursos
que compe um
servio coerente.
SP na mesma configurao.
71
Quando se deseja que dois servios distintos cada um responda com um Identificador
prprio (EntityID do SP) necessrio fazer a configurao de um SP lgico, sobrescrevendo a
propriedade EntityID.
Este servio ento ter seu prprio Metadata e responder como um servio distinto
mesmo estando fisicamente instalado no mesmo SP Fsico.
Quando no h necessidade
11 Aqui esto alguns casos de uso em que um SP lgico no precisa ser definido;
22 Utilizao de um servio de IdP ou descoberta em particular com base no recurso

propriedade requireSessionWith resolve este problema;
22 Uso de diferentes tipos de credenciais (por exemplo, certificados) com diferentes IdPs;
22 Manipulao de erro personalizada.
Alguns desses casos de uso em verses mais antigas do Shibboleth necessitavam de definio de um novo SP lgico, mas agora h uma variedade de opes avanadas disponveis
wPara mais detalhes
atravs de configuraes de contedo.

Em vez de criar um monte de configurao XML extra, voc pode simplesmente definir propriedades usando Apache ou o <RequestMapper> baseado no host virtual ou caminho,
e alterar muitos comportamentos.
Configurando um SP Lgico
11 Ao utilizar a configurao de SP Lgico:
22 Cada SP poder usar um certificado diferente, ter seu prprio EntityID,

e seu prprio arquivo de Metadata;
22 Pode autenticar em um IdP, liberando asseres SAML e atributos distintos,
ou apresentar uma pgina de login especfica para cada caso;
22 Definir o prprio arquivo de mapeamento e filtro de atributos.
Ao realizar a configurao de um SP lgico ele estar compartilhando a mesma instalao
fsica do seu provedor de servio, mas logicamente ir se comportar como uma outra insta-
72
lao, e responder isoladamente pelas requisies feitas ao servio configurado, de acordo

com as configuraes que foram sobrescritas atravs da tag <ApplicationOverride>.
possvel definir um novo par de chave/certificado, alterar o identificador do provedor de
Servios (EntityID), criar um novo arquivo de mapeamento e filtro de atributos, alterar configuraes de incio de sesso como tempo de espera, qual IdP redirecionar na autenticao e
definir novo arquivo de Metadados de IdPs parceiros.
H duas formas de configurar um SP Lgico
11 Utilizando Virtual Hosts;
22 Caso de 2 aplicaes cada uma em um virtual host: www.app1.br e www.app2.br;
22 Cada um dos hosts ser um SP lgico;
22 Forma usual e mais simples;
11 Utilizando paths;
22 2 aplicaes 1 em cada diretrio de um servidor: /app1 e /app2;
22 Cada um dos diretrios ser um SP lgico.
sobre propriedades
que auxiliam na
configurao personalizada do seu provedor
de servios acesse
NativeSPContentSettings no site em https://
wiki.shibboleth.net.
A forma usual de configurar um servio adicional atravs de virtual hosts. Cada um dos
hosts ir se comportar como um SP e ter suas configuraes personalizadas para o servio.
Quando se usa dois virtuais hosts o arquivo de metadata pode ser obtido automaticamente
atravs do handle /shibboleth.sso/Metadata sendo acessado via navegador com o nome de
cada virtual host.
Existe outra opo que utilizar diretrios. Com esta configurao o arquivo de metadado
deve ser gerado pelo usurio, no gerado automaticamente. A url de handle ir mudar adicionando o nome do diretrio antes: por exemplo https://SERVIDOR/homologa/Shibboleth.sso/
Configuraes necessrias
11 Arquivo /etc/shibboleth/shibboleth2.xml;
22 O ApplicationDefaults tem um identificador simples associado a ele, que

id=default;
22 A aplicao default a padro que configura o comportamento da primeira
aplicao utilizada;
22 Ao criar um ApplicationOverride, para definir uma nova aplicao,
ele ir sobrescrever as propriedades que forem citadas;
22 As propriedades no citadas continuam sendo herdadas do apllicationDefaults.
Para configurar um novo SP o primeiro passo inserir um elemento <ApplicationOverride>
que ir herdar e poder opcionalmente tambm sobrescrever as propriedades disponveis
na tag <ApllicationDefault>.
Todos os elementos que forem citados na tag ApplicationOverride iro ser sobrescritos,
j os que no forem includos continuaram com os valores configurados na Tag
<ApplicationDefault> ou valores padro.
ApplicationOverride
Passo 1: Criar e nomear a aplicao via <ApplicationOverride>:
<ApplicationOverride id=myApp>
checkAddress=false handlerURL=/app2/Shibboleth.sso/>
A propriedade handlerURL deve ser informada com o novo caminho para as urls do SP
recm criado quando se usa paths, ao usar virtual hosts no necessrio pois o Handle /
Shibboleth.sso/Metadata ir gerar automaticamente quando acessado o endereo de cada
virtual host.
O exemplo acima demonstra um SP lgico sendo definido utilizando um diretrio. A aplicao
app2 o nome do diretrio que responder como o SP. O exemplo utiliza diretrio necessrio sobrescrever a propriedade handlerURL com o novo caminho: /app2/Shibboleth.sso.
Passo 2: Associar os recursos que compem a nova aplicao para uma configurao
<ApplicationOverride>:
Mapeamento feito atravs da propriedade applicationId que coincide com o ID que voc
<Sessions lifetime=28800 timeout=3600
escolheu no passo anterior. Este mapeamento pode ser realizado via:

73
11 Apache Commands (httpd.conf ou equivalente);

11 RequestMapper (Portvel funciona IS).
Outra configurao necessria informar qual aplicao ir utilizar a nova configurao definida no ApplicationOverride. Existem duas formas de fazer este mapeamento: Atravs da tag
RequestMapper e atravs de configuraes nativas do Apache. A propriedade applicationId
pode ser usada dentro da tag RequestMapper ou no apache dentro de uma diretiva Location
por exemplo, indicando que a aplicao corrente ir utilizar o ApplicationOVerride cujo ID
coincidir com o informado na tag applicationId. Os comandos nativos do apache no so
portveis, por exemplo no IS no funciona, j a configurao via RequestMapper funciona
em qualquer servidor WEB.
Exemplo de utilizao de virtual hosts com mapeamento no Apache.
<VirtualHost>
...
ServerName sp.curso.rnp:443
...
<Location />
ShibRequestSetting applicationId myApp
</Location>
...
</VirtualHost>
Neste exemplo utilizando a configurao do Apache, a aplicao configurada no virtual
host sp.curso.rnp ir utilizar as configuraes sobrescritas na tag ApplicationOverride de
id=myApp.
RequestMapper
74
Passo 1: Usando paths e mapeamento via RequestMapper no Shibboleth2.xml

(Soluo portvel IS):
<Host name=sp.curso.rnp>
<Path name=app2 applicationId=myApp/>
</Host>

</RequestMap>
</RequestMapper>
Este exemplo j configura uma aplicao que est dentro de um diretrio do servidor,
no caso o diretrio app2 a usar o ApplicationOverride de id=myApp.
Passo 2: Usando Virtual Hosts a tag path deve ser omitida:
<Host name=sp.curso.rnp applicationId=myApp/>
</RequestMap>
</RequestMapper>
Esta configurao a mesma, porm estamos assumindo que a aplicao no vai utilizar
diretrios e sim vai estar na raiz do virtual host sp.curso.rnp.
Passo 3: Proteger os 2 diretrios no apache ou via requestMapper no arquivo shibboleth2.xml:
<Path name=secure authType=shibboleth
</Host>
<Host name=admin.example.org applicationId=myApp
authType=shibboleth requireSession=true>
<AccessControl>
<Rule require=affiliation>faculty@osu.edu student@osu.edu</
Rule>
</AccessControl>
</Host>
</RequestMap>
O SP j est configurado, o prximo passo proteger a aplicao para que no momento
que for requisitado acesso inicie o processo de autenticao Shibboleth redirecionando o
No exemplo acima foram adicionadas as tags authType e requireSession para fazer a proteo da aplicao.
A mesma proteo poderia ser feita tambm diretamente no apache como segue:
<Location /secure>
applicationId
myApp
authType
shibRequireSession On
</Location>
shibboleth
usurio para o Discovery Service ou IdP configurado.
75
Passo 4: Obter o arquivo de Metadados do novo SP:

11 Criar o arquivo de metadados novo (necessrio criar, quando utiliza paths no gerado
automaticamente pelo handle /Shibboleth.sso/Metadata);
11 Acessar a url do Handler que gera o metadado automaticamente quando se usa virtual hosts;
O arquivo de metadados quando se usa diretrio ter a estrutura semelhante a exibida a seguir.
<md:EntityDescriptor xmlns:md=urn:oasis:names:tc:SAML:2.0:metadata
ID=_c2b1f78bd80ebfab2c4eed15cc8111fc113a333d entityID=https://
admin.example.org/shibboleth>
....
<md:KeyDescriptor>
<ds:KeyInfo xmlns:ds=http://www.w3.org/2000/09/xmldsig#>
<ds:KeyName>sp.curso.rnp</ds:KeyName>
<ds:X509Data>
<ds:X509SubjectName>CN=sp.curso.rnp,C=BR,OU=CPD</
ds:X509SubjectName>
<ds:X509Certificate>
CONTEDO DO CERTIFICADO
</ds:X509Certificate>
<md:ArtifactResolutionService
Binding=urn:oasis:names:tc:SAML:2.0:bindings:SOAP
Location=https://sp.curso.rnp/homologa/Shibboleth.sso/Artifact/
SOAP index=0/>
<md:SingleLogoutService
Binding=urn:oasis:names:tc:SAML:2.0:bindings:SOAP
Location=https://sp.curso.rnp/homologa/Shibboleth.sso/SLO/SOAP/>
<md:SingleLogoutService Binding=urn:oasis:names:tc:SAML:2.0:
bindings:HTTP-Redirect Location=https://sp.curso.rnp/homologa/
Shibboleth.sso/SLO/Redirect/>
<md:SingleLogoutService Binding=urn:oasis:names:tc:SAML:2.0:bin
dings:HTTP-POST Location=https://sp.curso.rnp/homologa/Shibboleth.
sso/SLO/POST/>
<md:SingleLogoutService Binding=urn:oasis:names:tc:SAML:2.0
:bindings:HTTP-Artifact Location=https://sp.curso.rnp/homologa/
Shibboleth.sso/SLO/Artifact/>
<md:AssertionConsumerService Binding=urn:oasis:names:tc:SAM
L:2.0:bindings:HTTP-POST Location=https://sp.curso.rnp/homologa/
Shibboleth.sso/SAML2/POST index=0/>
<md:AssertionConsumerService Binding=urn:oasis:names:tc:SAML
:2.0:bindings:HTTP-POST-SimpleSign Location=https://sp.curso.rnp/
homologa/Shibboleth.sso/SAML2/POST-SimpleSign index=1/>
76
<md:AssertionConsumerService Binding=urn:oasis:names:tc:SAML:
2.0:bindings:HTTP-Artifact Location=https://sp.curso.rnp/homologa/
Shibboleth.sso/SAML2/Artifact index=2/>
<md:AssertionConsumerService
Binding=urn:oasis:names:tc:SAML:2.0:bindings:PAOS
Location=https://sp.curso.rnp/homologa/Shibboleth.sso/SAML2/ECP
index=3/>
<md:AssertionConsumerService Binding=urn:oasis:names:tc:SAML:
1.0:profiles:browser-post Location=https://sp.curso.rnp/homologa/
Shibboleth.sso/SAML/POST index=4/>
<md:AssertionConsumerService
Binding=urn:oasis:names:tc:SAML:1.0:profiles:artifact-01
Location=https://sp.curso.rnp/homologa/Shibboleth.sso/SAML/Artifact
index=5/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
Sobrescrevendo configuraes do <ApplicationOverride>

11 Para customizar o arquivo de Metadata usado para a nova aplicao:
<ApplicationOverride id=myappname>
<MetadataProvider type=XML file=idpformyapp-metadata.xml/>
Para customizar o arquivo de mapeamento de atributos:
<AttributeExtractor type=XML file=myapp-attribute-map.xml/>
O exemplo acima demonstra como sobrescrever algumas propriedades da tag <Applicationdos parceiros que ser utilizado pelo novo SP. O segundo exemplo substitui o arquivo de
mapeamento de atributos que ser usado para expor os dados dos usurios para o servio.
11 Para utilizar diferentes pares de chave/certificado para cada aplicao:
<CredentialResolver type=File key=myappname-key.pem
certificate=myappname-cert.pem/>
Outra possibilidade sobrescrever tambm o par de chave/certificado utilizado para assinar
as mensagens.
Defaults> para personalizar o novo SP. O primeiro exemplo substitui o arquivo de metadados
77
78
Edr Quinto Moreira Bacharel e

Mestre em Cincia da Computao
pela Universidade Federal de Minas
Gerais. Entre 2000 e 2003 participou
da implantao do diretrio corporativo da UFMG. Possui grande experincia em autenticao federativa com
protocolo SAML, tendo atuado como assistente 1 no Grupo
de Trabalho Middleware da RNP de 2003 a 2005. Possui
grande experincia com a plataforma JEE, tendo se certificado em programao Java em 2001. Em 2009 participou do
projeto que deu origem Federao CAFe. Participou da
elaborao e desenvolvimento do sistema EID. Atualmente
membro do Comit Tcnico da Federao CAFe. tambm
arquiteto de software no Departamento de Cincia da Computao da UFMG.
Bacharel em Sistemas de Informao
pela PUC Minas. Atualmente Analista
de Sistemas na UFMG trabalhando na
implantao de diretrios federados
no projeto CAFe. Trabalhou tambm
no desenvolvimento da ferramenta
EID (Export Import Directory). Experincia em autenticao
federativa com Shibboleth, LDAP, Apache Tomcat, Banco de
Dados e Java para Web.
LIVRO DE APOIO AO CURSO
O Curso desenvolve competncias para a implantao

de um provedor de servios na instituio.
So apresentados os conceitos sobre Federao, protocolo SAML e Shibboleth, com nfase na autorizao
ao uso dos servios pelos membros da federao.
O curso aborda desde a instalao at a congurao
de um provedor de servios na plataforma Shibboleth,
alm de apresentar algumas opes para federalizar
aplicaes e integr-las a uma Federao.
ISBN 978-85-63630-39-1
9 788563 630391

Muito mais do que documentos

Federação CAFe: Provedores de Serviços de Aplicações Federadas

Enviado por

Dados do documento

Descrição:

Descrição:

Direitos autorais:

Federação CAFe: Provedores de Serviços de Aplicações Federadas

Enviado por

Descrição:

Direitos autorais:

Títulos relacionados

e Pesquisa qualificada como

uma Organizao Social (OS),

Programa Interministerial RNP,

LIVRO DE APOIO AO CURSO

Ldia Aparecida O. Alixandrina

A RNP Rede Nacional de Ensino

O curso foi desenvolvido para auxiliar as instituies

Federao CAFe: Provedores de Servios e Aplicaes Federadas

Edr Quinto Moreira Bacharel e

que conta com a participao dos

ministrios da Educao (MEC), da

Edr Quinto Moreira

A RNP Rede Nacional de Ensino

Programa Interministerial RNP,

Copyright 2013 Rede Nacional de Ensino e Pesquisa RNP

Escola Superior de Redes

Escola Superior de Redes

Rua Lauro Mller, 116 sala 1103

Dados Internacionais de Catalogao na Publicao (CIP)

1. Introduo autenticao e autorizao federadas

2. Instalao do Shibboleth SP e do Discovery Service

3. Configurao do Shibboleth SP 2.4

4. Configurao de autenticao Shibboleth

6. Configuraes Avanadas do Shibboleth SP

Escola Superior de Redes

As sesses de aprendizagem onde se do a apresentao dos contedos e a realizao das

Convenes utilizadas neste livro

e autorizao interinstitucional; Entender o conceito de federao, seus elementos

Interao entre os elementos de uma federao; SAML 2.0; Single Sign-On;

Infraestrutura de autenticao e autorizao federada; Elementos de uma federao;

Infraestrutura de autenticao e autorizao federada

Aprender sobre demandas para a implantao de uma infraestrutura de autenticao

Este curso foi desenvolvido no escopo do projeto e-AA: Infraestrutura de Autenticao e

Contas vinculadas a servios

Federao CAFe : Provedores de Servios e Aplicaes Federadas

lizados raramente. Alm da questo da experincia do usurio, o cadastro de vrias contas

Contas desvinculadas dos servios

A autenticao distribuda transfere todo o esforo da administrao de usurios para os

Captulo 1 - Introduo autenticao e autorizao federadas

11 Aplicaes internas podem usar esses diretrios para autenticao.

Infraestrutura de autenticao e autorizao federada

Federao CAFe : Provedores de Servios e Aplicaes Federadas

O cumprimento das etapas de autenticao e autorizao como etapas fundamentais para

a disponibilizao de um servio implica, normalmente, na necessidade de manuteno de

Sist. Arq. Dist.

Sist. Arq. Dist.

Elementos de uma federao

11 Provedor de Identidade (IdP).

Federao CAFe : Provedores de Servios e Aplicaes Federadas

11 Instituio do usurio: possui um IdP e um processo interno de autenticao.

Uma federao constituda por dois componentes principais:

A figura 1.5 apresenta os principais componentes de uma federao e as associaes entre

Componente adicional de uma federao

11 Elemento que centraliza as informaes sobre provedores de identidade de uma

Captulo 1 - Introduo autenticao e autorizao federadas

11 Disponibilizado pela federao.

Federao CAFe : Provedores de Servios e Aplicaes Federadas

lA federao geralmente mantm

Captulo 1 - Introduo autenticao e autorizao federadas

11 Atributos dos usurios:

Federao CAFe : Provedores de Servios e Aplicaes Federadas

privilgios de acesso baseados em informaes adicionais sobre os usurios (por exemplo,

Interao entre os elementos de uma federao

garantir a privacidade do usurio, apenas so disponibilizados atributos previamente

Captulo 1 - Introduo autenticao e autorizao federadas

11 Passo 7: se necessrio, o SP requisita atributos adicionais desse usurio ao IdP; para

Federao CAFe : Provedores de Servios e Aplicaes Federadas

Artifact Resolution Protocols