Escolar Documentos
Profissional Documentos
Cultura Documentos
responsvel
pelo
Federao CAFe:
Provedores de
Servios de
Aplicaes
Federadas
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
responsvel
pelo
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
Ldia Aparecida O. Alixandrina
Federao CAFe:
Provedores de
Servios de
Aplicaes
Federadas
Edr Quinto Moreira
Ldia Aparecida O. Alixandrina
Rio de Janeiro
Escola Superior de Redes
2014
Diretor Geral
Nelson Simes
Diretor de Servios e Solues
Jos Luiz Ribeiro Filho
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
Escola Superior de Redes
A metodologia da ESRvii
Sobre o curso viii
A quem se destinaix
Convenes utilizadas neste livroix
Permisses de usoix
Sobre o autorx
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
iv
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
vi
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
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.
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
conceitos
Federao CAFe.
q
Captulo 1 - Introduo autenticao e autorizao federadas
objetivos
lUma federao
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
com tantas contas para diversos servios. Isso se agrava nos casos dos servios que so uti-
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
Figura 1.2
Autenticao
distribuda.
Provedor de
Identidade
Autenticao multi-institucional
11 Instituies possuem diretrios independentes para satisfazer necessidades internas.
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.
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.
Captulo 1 - Introduo autenticao e autorizao federadas
Figura 1.3
Modelo usual de
autenticao.
Universidade A
Correio eletrnico
I/S
Cluster de servidores
Biblioteca
Biblioteca Digital
Universidade B
Administrao
EaD
I/S
Administrao
e autenticao
do usurio
I/S
Credenciais
Autorizao
Recurso/Servio
Figura 1.4
Modelo de
autenticao
federada.
SP
SP
IdP
IdP
SP
SP
SP
SP
IdP
SP
SP
SP
SP
Figura 1.5
Principais
componentes de
uma federao.
IdP
Metadados da federao
Metadados:
<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/>
<md:SingleLogoutService Location=https://service.example.org/
Shibboleth.sso/SLO/Redirect
Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect/>
<md:SingleLogoutService Location=https://service.example.org/
Shibboleth.sso/SLO/POST
8
Binding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST/>
<md:SingleLogoutService Location=https://service.example.org/
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.
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
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.
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;
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
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).
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:
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.
Implementaes de SAML 2:
11 Shibboleth 2.0.
11 Google Apps APIs.
11 Oracle Identity Management.
Federao CAFe : Provedores de Servios e Aplicaes Federadas
14
11 Python SAML2.
11 ...
O protocolo SAML2 possui diversas implementaes. Entre as mais conhecidas est
o Shibboleth e o Simple SAML php.
Service Provider
User Agent
Identity Provider
3
4
6
7
Figura 1.8
Diagrama
Web Browser
SSO Profile.
10
11
12
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).
Federao CAFe : Provedores de Servios e Aplicaes Federadas
16
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.
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.
Handles disponveis no Shibboleth SP:
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.
17
</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.
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.
19
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.
[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
jan14
jun14
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
jan14
jun14
70
21
22
2
Aprender sobre a instalao do Shibboleth SP e do Discovery Service centralizado
e embarcado.
Shibboleth SP
Shibboleth Service Provider:
conceitos
objetivos
Instalao do Shibboleth SP
e do Discovery Service
23
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.
24
#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:
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.
25
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
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>
11 Baixar arquivos.
11 Descompactar e copiar para o apache.
28
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>
Figura 2.3
Exemplo de
Discovery Service
Centralizado
Federao CAFe.
29
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
identifier=
url=file:///etc/shibboleth/metadata.
xml/>
Configurar SP para redirecionar para DS
Arquivo Shibboleth2.xml:
30
VIDOR:8080/discovery/WAYF>
SAML2 SAML1
</SSO>
3
Conhecer as configuraes bsicas necessrias para a execuo do Provedor
de Servios Shibboleth.
conceitos
objetivos
Certificados
CERTIFICADO
Resource
CERTIFICADO
Webserver
CERTIFICADO
Shibboleth
Service
Provider
Metadado
Figura 3.1
Certificados
de Instalao
Shibboleth SP.
Federao
Assinatura
CERTIFICADO
CERTIFICADO
Webserver
Shibboleth
Service
Provider
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:
Federao CAFe : Provedores de Servios e Aplicaes Federadas
32
#openssl req -new -x509 -nodes -days 1095 -sha1 -key `nomekey`.
key -set_serial 00 config openssl.cnf > `nomeCert`.crt
Arquivo shibboleth2.xml
11 Define a maioria das configuraes do SP.
/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.
33
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/>
homeURL=https://sp.example.org/index.html/>
<SecurityPolicies/>
</SPConfig>
RequestMapper
11 Define as pginas que sero protegidas pelo shibboleth.
RequestMap
Atributos:
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
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:
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/>
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).
<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
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:
<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.
<MetadataProvider type=Chaining>
<!-- Example of remotely supplied batch of signed metadata. -->
<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>
<!-- Example of locally maintained metadata.-->
</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.
<TrustEngine type=Chaining>
41
AttributeExtractor:
11 Configura a chave privada e o certificado usados pelo SP para identificar-se aos Provedores de Identidade.
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>
<RequestMap applicationId=default>
<Host name=service.university.org
authType=shibboleth
requireSession=true/>
<Host name=other.university.org applicationId=otherapp authType=shibboleth
requireSession=true/>
</RequestMapper>
<ApplicationDefaults id=default policyId=default
entityID=https://service.university.org/shibboleth
homeURL=https://service.university.org/welcome/ REMOTE_USER=eppn
persistent-id targeted-id signing=false encryption=false>
[...]
<!-- Overrides for other-app -->
<ApplicationOverride id=other-app
entityID=https://other.org/shibboleth/>
</ApplicationDefaults>
</RequestMap>
43
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
<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-
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 />
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:PermitValueRule>
</afp:AttributeRule>
<afp:AttributeRule attributeID=unscoped-affiliation>
<afp:PermitValueRuleReference ref=eduPersonAffiliationValues/>
</afp:AttributeRule>
</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>
xmlns:saml=urn:mace:shibboleth:2.0:afp:mf:saml />
</afp:PermitValueRule>
<afp:AttributeFilterPolicy>
XMLSchema-instance>
47
<afp:PolicyRequirementRule xsi:type=ANY/>
<afp:AttributeRule attributeID=affiliation>
<afp:PermitValueRule xsi:type=AND>
</afp:PermitValueRule>
</afp:AttributeRule>
<afp:AttributeRule attributeID=*>
</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
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
<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.
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
# 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.
conceitos
objetivos
Configurao de autenticao
Shibboleth
Where are
3 Ask home server
to authenticate user
You From
(WAYF)
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
Shibboleth Daemon
Resource
Manager (RM)
thentication
System
Directory
(users)
Web
Server
Protected
Content
Protected
Content
User
1 Request Content
Protected
Content
Protected
Content
Figura 4.1
Arquitetura de
autenticao
Shibboleth.
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 channel para envio dos atributos, juntamente com a assero de autenticao.
52
Location:
11 AuthType shibboleth
11 ShibRequireSession On
11 Require valid-user
<Location /minhaaplicacao>
AuthType Shibboleth
ShibRequireSession On
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.
<RequestMap applicationId=default>
<Host name=www.example.org>
</Host>
<Host name=admin.org applicationId=admin
authType=shibboleth>
<AccessControl>
<Rule require=affiliation>faculty@osu.edu student@osu.edu</
Rule>
</AccessControl>
</Host>
</RequestMap>
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.
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.
54
Moodle:
11 Modular Object-Oriented Dynamic Learning Environment.
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
ShibRequireSession On
require valid-user
</Location>
11 Possibilidade de usar outras restries
Configuraes no Moodle
11 Acessar Moodle e logar como administrador.
11 Ativar a autenticao Shibboleth no Moodle.
22 Tela principal do Moodle.
55
Figura 4.2
Tela de
Administrao
do Moodle.
56
Figura 4.3
Menu do
Administrador
Moodle.
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
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
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
ShibRequireSession On
ShibRequireAll On
require mail ~.*@ufmg.br$
</Location>
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
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;
page
page
login
page
page
page
login
Figura 5.2
Formas de proteger
uma aplicao com
Shibboleth.
page
page
page
login
<Location /aplicacao>
AuthType shibboleth
ShibRequireSession On
require valid-user
</Location>
q
Captulo 5 - Aplicaes Federadas
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.
<Location /aplicacao/login.php>
AuthType shibboleth
ShibRequireSession On
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.
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
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.
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:
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
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.
<Location /minhaapp>
AuthType Shibboleth
ShibRequireSession On
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.
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.
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.
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.
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.
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;
Configurando um SP Lgico
11 Ao utilizar a configurao de SP Lgico:
fsica do seu provedor de servio, mas logicamente ir se comportar como uma outra insta-
72
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;
ApplicationOverride
Passo 1: Criar e nomear a aplicao via <ApplicationOverride>:
<ApplicationOverride id=myApp>
checkAddress=false handlerURL=/app2/Shibboleth.sso/>
</ApplicationOverride>
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
<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
<RequestMapper type=Native>
<RequestMap applicationId=default>
<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.
<RequestMapper type=Native>
<RequestMap applicationId=default>
<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:
<RequestMap applicationId=default>
<Host name=www.example.org>
<Path name=secure authType=shibboleth
requireSession=true/>
</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
75
<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
Federao CAFe : Provedores de Servios e Aplicaes Federadas
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>
<ApplicationOverride id=myappname>
<MetadataProvider type=XML file=idpformyapp-metadata.xml/>
</ApplicationOverride>
Para customizar o arquivo de mapeamento de atributos:
<ApplicationOverride id=myappname>
<AttributeExtractor type=XML file=myapp-attribute-map.xml/>
</ApplicationOverride>
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:
<ApplicationOverride id=myappname>
<CredentialResolver type=File key=myappname-key.pem
certificate=myappname-cert.pem/>
</ApplicationOverride>
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
ISBN 978-85-63630-39-1
9 788563 630391