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

e Pesquisa – é qualificada como uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

Programa Interministerial RNP,

LIVRO DE APOIO AO CURSO

Lídia Aparecida O. Alixandrina é Bacharel em Sistemas de Informação pela PUC Minas. Atualmente é Analista de Sistemas na UFMG trabalhando na implantação de diretórios federados no projeto CAFe. Trabalhou também no desenvolvimento da ferramenta EID (Export Import Directory). Experiência em autenticação 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 instituições no processo de implantação de um provedor de serviços para a Federação Acadêmica Federada (CAFe). Tem como objetivo demonstrar o funcionamento de uma infraestrutura de autenticação e autorização federada, com ênfase na autorização ao uso dos serviços pelos membros da federação. Para isso são apresentadas as ferramentas de software disponíveis para a construção desta infraestrutura, e o modo de integração de uma instituição acadêmica ou de pesquisa à federação CAFe como provedor de Serviços.

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

Edré Quintão Moreira é Bacharel e Mestre em Ciência da Computação pela Universidade Federal de Minas Gerais. Entre 2000 e 2003 participou da implantação do diretório corporativo da UFMG. Possui grande experiência em autenticação federativa com protocolo SAML, tendo atuado como assistente 1 no Grupo de Trabalho Middleware da RNP de 2003 a 2005. Possui grande experiência com a plataforma JEE, tendo se certificado em programação Java em 2001. Em 2009 participou do projeto que deu origem à Federação CAFe. Participou da elaboração e desenvolvimento do sistema EID. Atualmente é membro do Comitê Técnico da Federação CAFe. É também arquiteto de software no Departamento de Ciência da Computação da UFMG.

que conta com a participação dos

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

ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação,

Edré Quintão Moreira Lídia Aparecida O. Alixandrina

computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação

ISBN 978-85-63630-39-1 Ministério da Ciência, Tecnologia e Inovação

9 788563 630391

A RNP – Rede Nacional de Ensino e Pesquisa – é qualificada como uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

e

responsável

pelo

Programa Interministerial RNP, que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação Ministério da Ciência, Tecnologia e Inovação

Federação CAFe:

Provedores de Serviços de Aplicações Federadas Edré Quintão Moreira Lídia Aparecida O. Alixandrina

Federação CAFe:

Provedores de Serviços de Aplicações Federadas Edré Quintão Moreira Lídia Aparecida O. Alixandrina

Rio de Janeiro Escola Superior de Redes 2014

Copyright © 2013 – Rede Nacional de Ensino e Pesquisa – RNP Rua Lauro Müller, 116 sala 1103 22290-906 Rio de Janeiro, RJ

Diretor Geral Nelson Simões Diretor de Serviços e Soluções José Luiz Ribeiro Filho

Escola Superior de Redes Coordenação Luiz Coelho Edição Lincoln da Mata Coordenação Acadêmica de Gestão de Identidade Renato Duarte Rocha Equipe ESR (em ordem alfabética) Adriana Pierro, Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Edson Kowask, Elimária Barbosa, Evellyn Feitosa. Felipe Nascimento, Lourdes Soncin, Luciana Batista, Luiz Carlos Lobato e Yve Abel Marcial. Capa, projeto visual e diagramação Tecnodesign Versão 1.0.1 Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail [email protected]. A Rede Nacional de Ensino e Pesquisa e os autores não 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. Distribuição

Escola Superior de Redes

Rua Lauro Müller, 116 – sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br [email protected]

Dados Internacionais de Catalogação na Publicação (CIP) F293 Federação café: Provedores de Serviços de Aplicações Federadas / Edré Quintão Moreira, Lídia 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 serviço. 2. Serviço de descoberta. 3. Criptografia de dados (computação). 4. Redes de computadores – medidas de segurança. I. Rosseto, Silvana. II. Titulo. CDD 004.6

Sumário Escola Superior de Redes A metodologia da ESR vii Sobre o curso viii A quem se destina ix Convenções utilizadas neste livro ix Permissões de uso ix Sobre o autor x

1. Introdução à autenticação e autorização federadas Contas vinculadas a serviços 2 Contas desvinculadas dos serviços 2 Autenticação multi-institucional 4 Infraestrutura de autenticação e autorização federada 4 Elementos de uma federação 6 Componente adicional de uma federação 7 Metadados da federação 8 Provedores de Identidade 10 Provedores de serviço 10 Interação entre os elementos de uma federação 11 SAML 2.0 11 Componentes SAML 12 Motivação/Vantagens 14 SAML 2.0 – Web Browser SSO Profile 14

iii

Single Sign-On 15 Single Logout 16 Provedores de serviço 16 Exemplos de federações acadêmicas 19 A Federação CAFe 19 Estatísticas Provedores de Serviços da CAFe 21 Estatísticas Provedores de Identidade da CAFe: 21

2. Instalação do Shibboleth SP e do Discovery Service Shibboleth SP 23 Visão geral sobre instalação 23 Discovery Service 25 Implementações do Discovery Service 25 Discovery Service embarcado 26 Discovery Service Centralizado 29

3. Configuração do Shibboleth SP 2.4 Certificados 31 Arquivo shibboleth2.xml 33 Configurações realizadas no shibboleth2.xml 33 Estrutura do arquivo shibboleth2.xml 34 Sessions 37 SessionInitiator 38 Elementos filhos 39 Principais configurações 43 Arquivo attribute-map.xml 44 Elemento filho 45 Arquivo attribute-policy.xml 46 Diretivas de log 48 Configuração do Apache HTTPD 49 Configuração do Apache 49 Configuração do Apache – Certificados 50

iv

4. Configuração de autenticação Shibboleth Utilização de autenticação Shibboleth 51 Front e back channels 52 Autenticação/autorização via servidor web 52 Autorização via Shibboleth 53 Utilização de autenticação Shibboleth 54 Estudo de caso: Moodle 54 Pré-requisitos 55 Configurações no Apache 55 Configurações no Moodle 55 Group Management Tool (GTM) 59

5. Aplicações Federadas Módulo mod_shib 61 Opções do mod_shib 62 Protegendo aplicações 62 Formas de proteger aplicações 63 Protegendo toda a aplicação 63 Protegendo parte da aplicação 64 Lazy sessions 64 Proxy reverso 65 Atributos e mapeamentos 65 Autorização via aplicação 66 Configuração para containers JEE 68 Configuração para PHP 69 Configuração para outras linguagens 69 Implementação da autorização 70

6. Configurações Avançadas do Shibboleth SP SPs Lógicos e Físicos 71 Razões válidas pra adicionar um SP lógico 71 Quando não há necessidade 72 Configurando um SP Lógico 72 Configurações necessárias 73 ApplicationOverride 73 RequestMapper 74 v

vi

Escola Superior de Redes A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunicação (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicáveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e Governança de TI. A ESR também participa de diversos projetos de interesse público, como a elaboração e execução de planos de capacitação para formação de multiplicadores para projetos educacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na aprendizagem como construção do conhecimento por meio da resolução de problemas típicos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e informações, mas principalmente como orientador do aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema semelhantes às encontradas na prática profissional, que são superadas por meio de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do problema, em abordagem orientada ao desenvolvimento de competências. Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

vii

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atuação do futuro especialista que se pretende formar. As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir: Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona 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 dúvidas e oferecer explicações complementares. Terceira etapa: discussão das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso O curso foi desenvolvido para auxiliar as instituições no processo de implantação de um provedor de serviços para a Federação Acadêmica Federada (CAFe). Tem como objetivo demonstrar o funcionamento de uma infraestrutura de autenticação e autorização federada, com ênfase na autorização ao uso dos serviços pelos membros da federação. Para isso são apresentadas as ferramentas de software disponíveis para a construção desta infraestrutura, e o modo de integração de uma instituição acadêmica ou de pesquisa à federação CAFe como provedor de Serviços. Este curso está organizado em 6 capítulos. O capítulo 1 apresenta uma visão geral sobre a motivação para o uso de serviços federados e uma introdução ao SAML e à plataforma Shibboleth. O Capítulo 2 detalha a instalação do Shibboleth SP e do Discovery Service centralizado e embarcado. O Capítulo 3 apresenta detalhes de configuração do Shibboleth SP e do servidor Apache HTTPD. O Capítulo 4 detalha como configurar a autenticação e autorização para acesso às aplicações e apresenta a ferramenta Group Management Tool, que pode ser usada para facilitar esse controle. O Capítulo 5 explica como construir uma aplicação que usufrua da autenticação federada, com exemplos em Java e PHP. Por fim, o Capítulo 6 explica como configurar mais de um Shibboleth SP em uma mesma instalação do software. viii

A quem se destina O curso se destina aos técnicos das instituições que pretendem oferecer serviços federados para seus usuários através da integração destes serviços à Federação CAFe e também aos interessados em saber mais sobre autenticação federada e a Plataforma Shibboleth.

Convenções utilizadas neste livro As seguintes convenções tipográficas são usadas neste livro: Itálico Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos. Comandos que serão digitados pelo usuário são grifados em negrito e possuem o prefixo do ambiente em uso (no Linux é normalmente # ou $, enquanto no Windows é C:\).

Conteúdo de slide q Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo w Indica referência complementar disponível em site ou página na internet.

Símbolo d Indica um documento como referência complementar.

Símbolo v Indica um vídeo como referência complementar.

Símbolo s Indica um arquivo de aúdio como referência complementar.

Símbolo ! Indica um aviso ou precaução a ser considerada.

Símbolo p Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao entendimento do tema em questão.

Símbolo l Indica notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação.

Permissões de uso Todos os direitos reservados à RNP. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citação: MOREIRA, Edré Quintão et al. Federação CAFe: Implantação do Provedor de Identidade. Rio de Janeiro: Escola Superior de Redes, RNP, 2014.

ix

Comentários e perguntas Para enviar comentários e perguntas sobre esta publicação: Escola Superior de Redes RNP Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo Rio de Janeiro – RJ – 22290-906 E-mail: [email protected]

Sobre o autor Edré Quintão Moreira é Bacharel e Mestre em Ciência da Computação pela Universidade Federal de Minas Gerais. Entre 2000 e 2003 participou da implantação do diretório corporativo da UFMG. Possui grande experiência em autenticação federativa com protocolo SAML, tendo atuado como assistente 1 no Grupo de Trabalho Middleware da RNP de 2003 a 2005. Possui grande experiência com a plataforma JEE, tendo se certificado em programação Java em 2001. Em 2009 participou do projeto que deu origem à Federação CAFe. Participou da elaboração e desenvolvimento do sistema EID. Atualmente é membro do Comitê Técnico da Federação CAFe. É também arquiteto de software no Departamento de Ciência da Computação da UFMG. Lídia Aparecida O. Alixandrina é Bacharel em Sistemas de Informação pela PUC Minas. Atualmente é Analista de Sistemas na UFMG trabalhando na implantação de diretórios federados no projeto CAFe. Trabalhou também no desenvolvimento da ferramenta EID (Export Import Directory). Experiência em autenticação federativa com Shibboleth, LDAP, Apache Tomcat, Banco de Dados e Java para Web.

x

1 Introdução à autenticação e autorização federadas

e autorização interinstitucional; Entender o conceito de federação, seus elementos principais e sua arquitetura básica; Conhecer o conceito de federação, seus elementos principais e sua arquitetura básica; Saber o que é SAML, Single Login e Logout; Saber de que forma está sendo projetada a federação acadêmica brasileira CAFe.

Interação entre os elementos de uma federação; SAML 2.0; Single Sign-On; Sigle Logout; Provedores de Serviços- Handles; Exemplos de federações acadêmicas;

conceitos

Infraestrutura de autenticação e autorização federada; Elementos de uma federação;

Federação CAFe.

Infraestrutura de autenticação e autorização federada Motivação: 11 Disseminação de tecnologias e ferramentas que estimulam o compartilhamento de recursos, informações e serviços interinstitucionais. Desafio para as instituições: 11 Desenvolver ambientes seguros e escaláveis para permitir que a colaboração visionada aconteça de fato. Exemplos de serviços internos: 11 Cadastro de projetos, matrícula de alunos, registro de notas, compartilhamento de documentos etc. Exemplos de serviços externos: 11 Acesso a bibliotecas digitais, compartilhamento de recursos (ciclos de CPU, espaço de armazenamento), ensino a distância etc. 11 Uma federação oferece para as instituições a infraestrutura de autenticação e autorização necessária para interconectar pessoas e compartilhar recursos, informações e serviços.

q Capítulo 1 - Introdução à autenticação e autorização federadas

objetivos

Aprender sobre demandas para a implantação de uma infraestrutura de autenticação

1

lUma federação

Este curso foi desenvolvido no escopo do projeto e-AA: Infraestrutura de Autenticação e Autorização Eletrônica, idealizado e coordenado pela RNP (Rede Nacional de Ensino e Pesquisa), com a colaboração das instituições: 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 início em julho de 2007 e sua meta principal é criar as condições necessárias para a implantação de uma Federação Acadêmica no Brasil. A finalidade deste curso é capacitar o pessoal de TI das instituições de ensino e pesquisa no Brasil para implantar e gerenciar em suas instituições um Provedor de Serviço. Uma infraestrutura de autenticação e autorização federada traz ganhos tanto internos quanto externos. Os serviços disponibilizados internamente pelas instituições exclusivamente para seus membros podem se aproveitar de um ponto central para autenticação. No contexto externo, serviços compartilhados como Bibliotecas Digitais, serviços governamentais etc. podem utilizar autenticadores já existentes e conhecidos pelos membros das instituições. A federação oferece os meios necessários para que essa colaboração, principalmente externa, seja possível.

Contas vinculadas a serviços Cada usuário:

q

11 Múltiplas senhas. 11 Múltiplas contas. 11 Dificuldade de lembrar usuário ou senha. 11 Facilita o roubo de senhas. Cada serviço permite manter sua própria base de usuários, e gerência de múltiplas contas é trabalhosa não só para o administrador do serviço que deverá gerenciar, muitas vezes, milhões de contas de usuários, manter serviços de recuperação de senha e atendimento a usuários, mas também para o usuário que deve recordar várias senhas e acaba se perdendo

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

com tantas contas para diversos serviços. Isso se agrava nos casos dos serviços que são uti-

2

lizados raramente. Além da questão da experiência do usuário, o cadastro de várias contas em locais diferentes pode facilitar o roubo de credenciais diminuindo a confiabilidade.

Contas desvinculadas dos serviços Autenticação centralizada. 11 Autenticação fica como recurso administrado por um único local. 11 Serviços tomam conhecimento das senhas. Autenticação distribuída: 11 Autenticação distribuída entre vários domínios, formando um círculo de confiança. 11 Serviço não toma conhecimento do usuário e senha. 22 Vantagens da autenticação distribuída: 33 Credencial única compartilhada entre as instituições. 33 Credencial única para vários serviços. 33 Diminui a carga na administração de contas externas. 33 Menos senhas a serem recordadas pelos usuários.

q

acadêmica envolve instituições de ensino e pesquisa, permitindo que as pessoas vinculadas a essas instituições compartilhem informações e recursos, e tenham acesso a serviços restritos, usando o vínculo institucional como critério básico para esse compartilhamento.

Serviços

Operador de Identidade

Serviços

Figura 1.1 Autenticação centralizada.

Serviços

Serviços

Na figura 1.1, os vários serviços utilizam um ponto central para a gerência de usuários. Isso minimiza os problemas citados anteriormente, já que apenas um serviço de recuperação é necessário e o usuário não precisa se recordar de várias senhas. Uma questão relevante nesse modelo é que os serviços tomam conhecimento do usuário e da senha dos usuários, tornando a arquitetura mais vulnerável a ataques. Provedor de Identidade

Serviço 1

Serviço 2

Provedor de Identidade


A autenticação distribuída transfere todo o esforço da administração de usuários para os provedores de identidades. Dessa forma, o serviço deve se preocupar apenas em atender bem suas regras de negócio. Por outro lado, cada provedor de identidade deve se preocupar em garantir os requisitos de segurança em apenas um ponto. O fato de o serviço não tomar conhecimento das credenciais, usuário e senha, minimiza possibilidades de ataques. Na autenticação distribuída, vários serviços localizados em diferentes domínios podem ser acessados com as mesmas credenciais usando os atributos dos usuários fornecidos pelos autenticadores nos quais ele confia, permitindo que o administrador do serviço não se preocupe com a gerência de usuários, se dedicando apenas em estabelecer regras pra que os provedores de identidade possam acessar o serviço. Outra vantagem da autenticação distribuída é a escalabilidade, permitindo que outros serviços se juntem à rede, aproveitando os autenticadores disponíveis, assim como novos autenticadores podem se juntar à rede permitindo que mais usuários tenham acesso aos serviços. Tudo isso com baixíssimo custo.

Capítulo 1 - Introdução à autenticação e autorização federadas

Figura 1.2 Autenticação distribuída.


3

Autenticação multi-institucional 11 Instituições possuem diretórios independentes para satisfazer necessidades internas.

q

11 Aplicações internas podem usar esses diretórios para autenticação. 22 Evita a criação de mais um cadastro de usuários. 11 Federações se aproveitam das autenticações locais já implementadas. As instituições já possuem (ou deveriam possuir) diretórios internos para autenticar usuários para seus diversos serviços (modelo de autenticação centralizada). A ideia central da federação é a de se aproveitar dessas autenticações, extrapolando o domínio da instituição, sem comprometer a segurança dos serviços. A experiência do usuário também é melhorada, uma vez que é conveniente para ele a memorização de apenas uma forma de autenticação, além de se autenticarem sempre em uma interface conhecida e familiar.

Infraestrutura de autenticação e autorização federada O que é uma Federação?

q

11 Tipo de rede de confiança que permite facilitar contratos bilaterais entre usuários e provedores de serviços. 11 Implementa o princípio de identidade federada: 22 Instituições implementam métodos distintos de autenticação, mantendo a interoperabilidade. O crescente avanço das tecnologias de redes de computadores (em particular da internet) e o uso dessas tecnologias para a construção de aplicações que permitem o acesso remoto (e em tempo real) a diferentes serviços trouxe a necessidade de se criar e manter bases de dados com informações sobre as pessoas que podem acessar esses serviços e definir o nível de privilégio. Essa demanda de reconhecimento e validação de acesso dos usuários aos serviços pode ser sintetizada em duas etapas denominadas autenticação e autorização.


O cumprimento das etapas de autenticação e autorização como etapas fundamentais para

4

a disponibilização de um serviço implica, normalmente, na necessidade de manutenção de bases de dados com registros sobre os possíveis usuários do serviço. A demanda do lado de quem disponibiliza um serviço é a necessidade de criar e manter suas próprias bases de dados de usuários. Do outro lado, para quem usa os diferentes serviços disponibilizados, a demanda é a necessidade de criar e manter contas (ou cadastros) para cada serviço a que se deseja ter acesso. O conceito de federação acadêmica visa minimizar as demandas dos provedores e dos usuários de serviços disponibilizados por instituições de ensino e pesquisa no que diz respeito à manutenção de informações usadas para autenticação e autorização de acesso a esses serviços. A ideia básica consiste no seguinte: as informações sobre uma pessoa são mantidas em uma única base, gerida por sua instituição de vínculo, cabendo a cada instituição estabelecer seu modelo de gestão de identidade, isto é, de que forma informações sobre pessoas são mantidas e atualizadas e quais métodos de autenticação são usados. Os provedores de serviço confiam no modelo de gestão de identidade das instituições e disponibilizam seus serviços para os usuários vinculados a essas instituições, criando assim o princípio de identidade federada.

Universidade A

I/S

Correio eletrônico

I/S

Cluster de servidores

I/S Biblioteca

I/S

Biblioteca Digital

I/S

I/S

Universidade B

Administração

I/S

EaD

I/S I/S

Administração e autenticação do usuário

I/S

Credenciais

Autorização

Recurso/Serviço

As figuras 1.3. e 1.4 ilustram a diferença entre um modelo usual, onde cada serviço deve manter informações sobre seus possíveis usuários, e um modelo onde as informações sobre os usuários são concentradas e mantidas em um único local. No primeiro caso, a implementação de cada serviço deve prever um módulo adicional para tratar o registro dos usuários que podem acessá-lo, e cada pessoa precisa ter um cadastro (usuário/senha) para cada serviço que deseje acessar. No segundo caso, as informações sobre as pessoas são mantidas em um único local, tipicamente a instituição com a qual a pessoa mantém seu vínculo principal, e cada pessoa precisa ter apenas um registro (usuário/senha); nesse caso, a implementação dos serviços oferecidos não requer o módulo de registro de usuários. Capítulo 1 - Introdução à autenticação e autorização federadas

Figura 1.3 Modelo usual de autenticação.

Sist. Arq. Dist.

5

Universidade A Correio eletrônico I/S

Cluster de servidores

Biblioteca

Biblioteca Digital

Universidade B Administração EaD

I/S

Sist. Arq. Dist.

Administração e autenticação do usuário

I/S

Credenciais

Autorização

Recurso/Serviço

Elementos de uma federação Uma federação inclui dois elementos:

q

11 Provedor de Identidade (IdP). 11 Provedor de Serviço (SP). Atores em uma federação: 11 Usuário: deseja usar um recurso protegido. 11 Provedor do recurso: aplicação com um SP instalado.


11 Instituição do usuário: possui um IdP e um processo interno de autenticação.

6

Uma federação é constituída por dois componentes principais: 11 Provedores de identidade: armazenam e gerenciam as informações sobre pessoas; 11 Provedores de serviço: oferecem serviços restritos para grupos de usuários. Há ainda um elemento secundário, chamado serviço de descoberta (ou discovery service), que pode ser usado para facilitar a identificação do provedor de identidades por um usuário no momento de sua autenticação. Esse elemento está mais ligado ao serviço e pode existir ou não no contexto federado.

Figura 1.4 Modelo de autenticação federada.

SP

SP IdP IdP

SP SP

SP SP IdP

SP

SP

SP

SP

A figura 1.5 apresenta os principais componentes de uma federação e as associações entre eles. Podemos observar que dentro de uma federação é possível definir subgrupos com um provedor de identidade e um ou mais provedores de serviços associados. Essa configuração pode ser usada para os seguintes casos: 11 Serviços internos da instituição, como matrícula de alunos, e-mail, registro de notas, cadastro de projetos, entre outros exemplos; 11 Serviços externos à instituição, como o caso de bibliotecas digitais, ensino a distância, armazenamento distribuído, entre outros exemplos, podendo ser oferecidos a usuários ligados a diferentes provedores de identidade.

Componente adicional de uma federação Where Are You From (WAYF)/Discovery Service (DS).

q

11 Elemento que centraliza as informações sobre provedores de identidade de uma federação. Como um provedor de serviço em uma federação normalmente permite o acesso de usuários de diferentes instituições, um componente adicional é incluído na federação para auxiliar no redirecionamento dos usuários 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 informações sobre os provedores de identidade da federação e suas localizações. Ao ser redirecionado para o DS, o usuário seleciona a sua instituição 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 federação.

IdP

7

Metadados da federação Metadados:

q

11 Disponibilizado pela federação. 11 Informações relevantes sobre os IdPs e SPs. 22 Confiança: 33 Certificados. 33 Chaves públicas. 22 Comunicação: 33 IDs. 33 URLs. 33 Protocolos. 33 Dados de contato para exibição no Discovery Service. Os metadados estabelecem a confiança entre as partes e são, tecnicamente falando, o coração da federação. Neles estão descritos endpoints, protocolos e certificados digitais para conversação entre as partes.


... base64-encoded certificate elided ...
lA federação geralmente mantém atualizado e distribui um conjunto de informações para todos os seus membros. Essas informações são assinadas digitalmente para garantir a procedência e integridade.

Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”/> …. Example Organization, Ltd. Example Organization https://service.example.org/ Ficheiro de Metadados da Federação 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

Federação

Identity Provider IdP

Organização

Service Provider SP

Info. SP Info. SP Info. SP


Figura 1.6 Ficheiro de Metadados da Federação.

9

Os membros podem aplicar filtros a esse conjunto, reconhecendo apenas as partes com quem realmente deseja interar. Isso porque a federação facilita o mecanismo de compartilhamento, mas não, necessariamente, força o relacionamento bilateral entre todas as partes.

Provedores de Identidade Implementam a política interna de gestão de identidade de uma instituição.

q

11 Atributos dos usuários: 22 Nome, data do vínculo, cargo ocupado, matrícula etc. 11 Método de autenticação: 22 Login/senha, certificados etc. 11 Identificador único para cada pessoa vinculada à instituição. Os provedores de identidade são responsáveis por manter as informações sobre as pessoas vinculadas a uma instituição, incluindo dados pessoais (nome, data de nascimento, CPF, nomes dos pais, sexo, data de nascimento etc.) e vínculos internos (data de admissão, cargo ocupado, número de matrícula, número VoIP etc.). O provedor de identidade estabelece seu método de autenticação interno e deve garantir que cada pessoa da instituição tenha um identificador único.

Provedores de serviço Implementam serviços que devem ser disponibilizados para pessoas vinculadas às insti-

q

tuições. Requerem: 11 Autenticação: 22 Identificação dos usuários do serviço. 11 Autorização: 22 Atributos adicionais do usuário que garantem certos privilégios de acesso. Foco na implementação do serviço, e não na manutenção dos registros dos usuários. Os provedores de serviço oferecem serviços de acesso restrito, podendo requisitar ainda


privilégios de acesso baseados em informações adicionais sobre os usuários (por exemplo,

10

aluno matriculado em determinado curso, professor coordenador de curso etc.). Na implementação do serviço são definidos os privilégios de acesso e as informações adicionais que serão solicitadas. Não cabe ao provedor de serviço manter essas informações, mas apenas solicitá-las aos provedores de identidade e tomar a decisão de autorização ou não.

Interação entre os elementos de uma federação WAYF/DS 4

3 2

5 Credenciais

6

Instituição do usuário

7

1

Handle

Handle

Recurso

Atributos

Figura 1.7 Interação entre elementos da federação (IdP, SP, DS).

Requisição/Resposta HTTP Redirecionamento HTTP Conexão servidor/servidor A interação entre os elementos (atores) de uma federação é mostrada na figura 1.7: 11 Passo 1: usuário acessa provedor de serviço (SP); 11 Passo 2: o serviço apresenta escolhas fornecidas pelo repositório centralizado Discovery Service (DS), que lista todos os Provedores de Identidade disponíveis para autenticação na federação; 11 Passo 3: o usuário seleciona o Provedor de Identidade da sua instituição de origem; 11 Passo 4: o usuário é redirecionado para o seu provedor de identidade (IdP); 11 Passo 5: o IdP autentica o usuário com o método escolhido pela instituição; 11 Passo 6: o SP recebe garantia de autenticação do usuário pelo IdP;

garantir a privacidade do usuário, apenas são disponibilizados atributos previamente acordados entre o IdP e o SP; 11 Passo 8: o provedor de serviço decide sobre as autorizações e disponibiliza o serviço para o usuário.

SAML 2.0 Definição: 11 Security Assertion Markup Language – SAML. 22 Padrão definido pela Organization for the Advancement of Structured Information Standards (OASIS), baseado em XML para a troca de autenticação e autorização de dados entre um provedor de identidade (IdP) e um provedor de serviços (SP). Histórico: 11 V1.0 se tornou um padrão OASIS em novembro de 2002. 11 V1.1 surgiu em setembro de 2003. 11 V2.0 foi anunciado em março de 2005.

q


11 Passo 7: se necessário, o SP requisita atributos adicionais desse usuário ao IdP; para

11

Security Assertion Markup Language – SAML 2.0, permite cenários de autenticação e autorização baseados na web, incluindo cross-domain single sign-on (SSO), que ajuda a reduzir a sobrecarga administrativa de distribuir vários tokens de autenticação para o usuário.

Componentes SAML O SAML possui os seguintes componentes:

Assertions 11 É um pacote de informações que fornece uma ou mais declarações 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 serviços (https://sp.example.com/SAML2). 11 Exemplo:

https://idp.example.org/SAML2

xmlns:ds=”https://www.w3.org/2000/09/xmldsig#”>...

12

3f7b3dcf-1674-4ecd-92c8-1544f346baf8
InResponseTo=”aaf23196-1773-2113-47a-fe114412ab72”

Recipient=”https://sp.example.com/SAML2/SSO/POST”

NotOnOrAfter=”2004-12-05T09:2705”/>

Protocols São elementos de pedidos/respostas que empacotam as assertions. O SAML possui vários protocolos, e o mais importante é o Authentication Request Protocol. No SAML 2.0, o fluxo começa no prestador de serviços que emite uma solicitação de autenticação explícita ao provedor de identidade. Um elemento é transmitido para o provedor de identidade pelo SP. O provedor de identidade autentica o usuário (se necessário) e emite uma resposta de autenticação, que é transmitida de volta para o SP (através do browser).

Artifact Resolution Protocols A mensagem SAML é transmitida por valor ou por referência. Uma referência a uma mensagem SAML é chamado de um artefato, onde o receptor de um artefato resolve a referência através do envio de um pedido 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 são usadas dentro de protocolos de transporte. Para Web Browser SSO, o HTTP Redirect Binding e o HTTP POST Binding são comumente usados. O SP pode usar “HTTP Redirect” para enviar um pedido, enquanto o provedor de são frequentemente enviadas diretamente na URL de uma solicitação HTTP GET. O “HTTP Redirect” é adequado para mensagens curtas, como , já que o tamanho de uma URL é limitado. As mensagens mais longas (exemplo: aqueles que contêm assinaturas de asserções SAML) devem ser transmitidas através de outros bindings, como o “HTTP POST”. Exemplo de formulário XHTML enviado pelo SP via “HTTP POST Binding”:

... other input parameter....


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 específicos.

Motivação/Vantagens 11 Neutralidade da plataforma.

q

11 Fraco acoplamento de diretórios. 11 Melhor experiência on-line para usuários finais. 11 Redução de custos administrativos para o SP. 11 Transferência 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 serviços essa escolha. Dessa forma, um mesmo serviço poderá ter diversos tipos de autenticação (usuário/senha, certificados etc.), já que cada provedor de identidade pode optar pela tecnologia de autenticação. O provedor de serviços por sua vez não deverá se preocupar em administrar a base de potenciais usuários para seus serviços, transferindo todo esse custo administrativo para o provedor de identidade. O usuário final do serviço também será beneficiado com o uso de uma única credencial e ambiente de autenticação familiar, onde poderá ter acesso a diversos serviços providos pela federação.

Implementações de SAML 2:

q

11 Shibboleth 2.0. 11 Google Apps APIs. 11 Oracle Identity Management. Federação CAFe : Provedores de Serviços e Aplicações Federadas

11 Simple SAML php.

14

11 Python – SAML2. 11 ... O protocolo SAML2 possui diversas implementações. Entre as mais conhecidas está o Shibboleth e o Simple SAML php.

SAML 2.0 – Web Browser SSO Profile O diagrama ilustra a sequência de funcionamento do SSO na autenticação de um usuário via federação. Como atores, temos o provedor de serviço, o usuário que acessa o serviço e o provedor de identidade que autenticará o usuário que requisita acesso ao serviço.

Service Provider

1

User Agent

Identity Provider

Request target resource Discover the IdP

2

Redirect to SSO Service Request SSO Service

3 4

Request Artifact Resolution Service

5

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

8

Request Artifact Resolution Service

9

Request with SAML Authn Request

10

Redirection to target resource

11

Request target resource

12

Respond with requested resource

Single Sign-On A autenticação Single Sign-On (SSO) permite que um usuário se autentique apenas uma vez em seu domínio de origem e use essa autenticação nos demais domínios de um sistema distribuído.

Identity Provider

Ser reconhecido Figura 1.9 Single Sign-On.

Service Provider O Single Sign-On permite que o usuário, logando-se apenas uma vez em seu provedor de

identidade, seja reconhecido como autenticado por outro serviço que solicite a autenticação no mesmo IdP; isso é válido para a mesma seção do navegador web. O serviço recebe o mesmo handle criado durante a autenticação, necessitando apenas solicitar os atributos e decidir pela liberação de acesso ou não. Para o usuário, isso é transparente, já que não precisa informar novamente seus dados para autenticação.


Login

15

Single Logout 11 Logout de todas as aplicações iniciadas pelo usuário.

q

11 Problemas: 22 Ao acionar o “logout”, nem todas as aplicações são encerradas. 22 Problema com experiência do usuário. 22 Falta de segurança. 22 Acesso malicioso a serviços. O SSO oferece uma melhoria significativa de usabilidade. Por outro lado, introduz um grande problema, que é o single logout (ou SLO). Dado que as aplicações estão em domínios diferentes, como determinar se o usuário deseja fazer o logout apenas daquela aplicação ou de todas? Como ter certeza de que o logout foi realmente feito em todas as aplicações (o protocolo SAML2 fornece pouca informação)? Essas e outras questões sempre recaem em um mesmo direcionamento ao usuário – que devem encerrar o navegador web para que todas as informações atreladas à sua sessão sejam limpas.

Provedores de serviço Handles disponíveis no Shibboleth SP: 11 São configurados no arquivo shibboleth2.xml. 11 Podem ser acessados via navegador. 11 Auxiliam em testes e debugs do SP. Handles disponíveis no Shibboleth SP. 11 Metadata Generation Handler: 22 Gera metadados de amostra com base na configuração do SP. 22 Type=“MetadataGenerator”. 22 URL para acesso: https://SERVIDOR/Shibboleth.sso/Metadata. 22 Entre os atributos disponíveis para configuração, vamos destacar o https (boolean). Federação CAFe : Provedores de Serviços e Aplicações Federadas

22 Força ou desativa a geração de parâmetros de protocolo usando o esquema https,

16

independentemente de qual esquema é usado ao acessar o manipulador. 11 Handles disponíveis no Shibboleth SP: 22 Status Handler. 22 Gera um xml sobre o estado operacional do SP e algumas informações de configuração. 22 Type= “Status”. 22 URL para acesso: https://SERVIDOR/Shibboleth.sso/Status. 22 Informações retornadas podem ser consideradas confidenciais por alguns implantadores (versão do SP e S.O.). 22 Um atributo importante é o “ACL” – para impedir acesso indevido a esse Handler, através desse atributo, é possível restringir o acesso por IPs. O elemento é usado para configurar manipuladores genéricos do SP que oferecem funcionalidades diversas que não se enquadram nas categorias abrangidas por outros elementos pré-definidos.

q

O arquivo de Metadados fornecido por esse Handler pode ser gerado através da utilização de um arquivo modelo, e suporta assinatura. O metadata gerado por esse handler não é recomendado para uso em ambientes de produção por não ser tão completo. A ideia é que seja usado na geração de exemplos úteis para compreensão de como produzir metadados reais.

Implementações maduras, muitas vezes, necessitam de conteúdo de metadados que vão além do que o manipulador pode gerar. Access Control List (ACL) é responsável por listar os endereços IP permitindo restringir o acesso a um determinado grupo – a sua configuração padrão é permitir o acesso. A partir de V2.5, o uso de Classless Inter-Domain Routing (CIDR) e endereços IPv6 passou a ser suportado. A seguir um exemplo do uso do atributo ACL para limitar o acesso apenas para o servidor local:

Handles disponíveis no Shibboleth SP:

q

11 Session Handler. 11 Exibe informações da sessão de um usuário específico para auxiliar no debug. 11 Type= “Session”. 11 URL para acesso: https://SERVIDOR/Shibboleth.sso/Session. 11 Um atributo importante é showAttributeValues (boolean). O padrão é false, que indica se os valores dos atributos serão exibidos. 11 O Atributo ACL para limitar acesso também está disponível, mas apenas informações do próprio usuário são exibidas, então não é relevante seu uso. Exemplo de configuração do Handler no arquivo Shibboleth2.xml:

showAttributeValues=”false”/> Outro atributo disponível é o contentType no formato string, que seleciona o tipo de conteúdo da resposta, afetando o formato de saída. O padrão, como nas versões mais antigas, é uma página HTML simples. Para uso em programação, o valor “application / json” é suportado, fazendo com que o resultado seja uma estrutura JSON. Handles disponíveis no Shibboleth SP: 11 Discovery Feed Handler (A partir da versão 2.4). 22 Exibe informações dos IdPs disponíveis 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.

q


17


q

11 Attribute Checker Handler (A partir da versão 2.5). 22 Valida a sessão de um usuário com uma lista de atributos obrigatórios (e, opcionalmente, seus valores), pode retornar o usuário para completar o processo de login ou exibir uma página de erros personalizada. 22 type=”AttributeChecker”. 22 URL acesso: https://SERVIDOR/Shibboleth.sso/AttributeChecker. 22 Esse manipulador é projetado para complementar a configuração sessionHook, aproveitando para verificar os atributos necessários. Através do arquivo gerado pelo DiscoFeed, algumas aplicações, como o Discovery Service embarcado, obtêm a lista de IdPs disponíveis para autenticação no serviço. Os atributos validados podem ser especificados de duas maneiras: Uma lista de IDs de atributos esperados pelo SP:

Pela incorporação de uma política de controle de acesso válido dentro do elemento:


18

A última opção permite a verificação da sessão com combinações booleanas de atributos e valores. Por exemplo, em vez de exigir que todos os atributos de um conjunto devem estar presente, uma opção pode ser utilizada. Atributos: 11 Template (caminho local): especifica o caminho para um template para a página de erros que deve ser usada no caso de a verificação falhar. Os atributos da sessão estão disponíveis e podem ser usados através de tags ; 11 flushSession (boolean): por padrão, está atribuído o parâmetro “false”; se for true, a sessão do usuário é finalizada à força se a validação falhar; 11 attributes (lista delimitada por espaços em branco de IDs de atributos): especifica uma lista de atributos para procurar. Se a sessão não contém pelo menos um valor para cada atributo designado, a validação falha.

sessionHook: attributo da tag que especifica um local para enviar o cliente depois que uma sessão foi criada (ou seja, após o login), mas antes de transferir o cliente para o eventual recurso final. Um exemplo comum é a verificação de atributos necessários. uApprove por exemplo é um aplicativo que faz essa verificação.


q

11 External Authentication Handler (a partir da versão 2.5). 22 Implementa uma interface REST loopback para a criação de sessões de usuário com base na lógica de autenticação externa. 22 Type=“ExternalAuth”. 22 URL acesso: https://SERVIDOR/Shibboleth.sso/ExternalAuth; 22 Por motivo de segurança, não deve ser exposto a qualquer interface de rede. 22 Permite que qualquer interlocutor confiável crie sessões de usuário. O External Authentication Handler é um manipulador que não deve ser exposto a qualquer interface de rede não confiável. Sua utilização inadequada pode expor a segurança do sistema. Ele permite que qualquer interlocutor confiável crie sessões de usuário com base nas informações apresentadas. Possui o atributo ACL, que limita o acesso por IPs, onde o padrão é liberado apenas para o servidor local. Exemplo de configuração do Handler no arquivo Shibboleth2.xml:

Exemplos de federações acadêmicas InCommon:

q

11 Federação nos EUA, 107 instituições, 2 milhões de usuários. Feide: 11 Federação na Noruega. Switch: 11 Federação na Suíça. SDSS:

Federações acadêmicas já são implementadas e mantidas em outros países. Alguns exemplos: InCommon, Feide, Switch e SDSS. Uma tendência natural para o futuro será a junção de federações em confederações, ampliando o escopo de serviços disponibilizados aos usuários e o número de possíveis usuários de um serviço para além dos limites geográficos dos países.

A Federação CAFe Iniciativa da RNP para criar uma Federação Acadêmica no Brasil. 11 Surgiu a partir do Projeto E-AA, iniciado em julho de 2007, envolvendo cinco instituições: UFC, UFMG, UFF, UFRGS e Cefet-MG. Metodologia adotada: 11 Integrar padrões e soluções de software utilizados por outras federações. 11 Desenvolver ferramentas auxiliares e definir políticas para a federação.

q


11 Federação no Reino Unido.

19

No Brasil, os primeiros esforços para a construção de uma federação acadêmica resultaram na criação da Federação CAFe (Comunidade Acadêmica Federada), cuja meta é prover uma infraestrutura de autenticação e autorização para as universidades e instituições de pesquisa brasileiras. A metodologia adotada para a construção da infraestrutura básica da federação consiste na utilização de padrões e soluções de software já disponíveis e adotados por outras federações, e na implementação e experimentação de ferramentas auxiliares para apoiar a implantação dos provedores de identidade e de serviço. Faz parte, também, do escopo da Federação CAFe o estudo, a proposição, a análise e a validação de políticas para regular o seu funcionamento (requisitos mínimos que provedores de identidade e de serviço deverão cumprir).

Metadado

RNP

?

Diretório LDAP

Recomendação para obtenção de atributos (e certificados para autenticação)

Provedor de serviço (membro ou parceiro externo)

Figura 1.10 Estrutura Federação CAFe.

A figura 1.10 mostra a arquitetura básica utilizada pela Federação CAFe. O componente


WAYF é centralizado e mantido pela RNP, mas os provedores de serviço também podem usar

20

uma aplicação própria para localização da instituição de origem dos usuários. Os provedores de serviço poderão ser implantados nas instituições que já compõem a federação, como provedores de identidade (universidades e instituições de pesquisa) ou poderão ser implantados por membros externos (os quais atuam apenas como provedores de serviço). As políticas definidas para a operação da Federação CAFe estabelecem os critérios para a inclusão de um membro na federação e as obrigações dos provedores de identidade e de serviço, bem como garantem a preservação dos requisitos básicos de privacidade. A recomendação para os provedores de identidade é a utilização de serviço de diretórios para a organização das informações sobre as pessoas vinculadas à instituição. 11 Provedores de Serviços da CAFe: 22 Microsoft Dreamspark. 22 Atlases. 22 Gisela Science Gateway.

q

q

11 Portal de Periódicos da CAPES. 11 Portal de vídeo digital. 11 JEMS. 11 PADBR. 11 Readex. 11 GENI. 11 Portal RedCLARA. 11 eduGain (Vários provedores de serviços Internacionais).

Estatísticas Provedores de Serviços da CAFe 20

[un.]

15

Figura 1.11 Estatística Provedores de Serviço.

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

q

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

Estatísticas Provedores de Identidade da CAFe: 75

71 65

65 60

57

57

65

72

65

60

[un.]

55 50 45 Figura 1.12 Estatística Provedores de Identidade.

45

45

48

49

40 35 30

jul13 ago13

set13 out13 nov13 dez13

jan14

fev14 mar14 abr14 mai14

Como aderir à Federação CAFe: 11 Como Provedor de Identidade: http://portal.rnp.br/web/servicos/adesao-a-cafe-como-provedor-de-identidade 11 Como Provedor de Serviços: http://portal.rnp.br/web/servicos/adesao-a-cafe-como-provedor-de-servico

jun14

q


70

21

22


2 Aprender sobre a instalação do Shibboleth SP e do Discovery Service centralizado e embarcado.

Implementações do Discovery Service; Instalação do Discovery Service Embarcado e Centralizado.

Shibboleth SP Shibboleth Service Provider:

conceitos

Arquitetura Shibboleth SP; Visão Geral da Instalação do Shibboleth SP;

q

11 Implementa o protocolo SAML 2. 11 Independente de linguagem de implementação. 11 Módulo de autenticação para Apache ou IIS. Não insere dependências nas aplicações. O Shibboleth Service Provider (Shibboleth SP) permite que as aplicações web escritas em qualquer linguagem de programação ou framework sejam federadas. Integra-se nativamente com servidores web populares, como o Apache e Internet Information Server (IIS). A estratégia de integração é flexível e permite a troca de atributos e outros recursos de valor agregado. Muitas vezes, exige pouca alteração no código da aplicação ou uso de interfaces proprietárias.

Visão geral sobre instalação 11 Código aberto sob Licença Apache 2. 11 Pode ser compilado para diversas plataformas. 11 Binários disponíveis para algumas plataformas. 22 Instalador para Windows. 22 Instalador RPM.

q

Capítulo 2 - Instalação do Shibboleth SP e do Discovery Service

objetivos

Instalação do Shibboleth SP e do Discovery Service

23

q

11 Shibboleth Service Provider. 22 mod_shib. 33 Módulo do Apache. 22 shibd. 33 Daemon. Desenvolvido sob a licença Apache 2, o Shibboleth SP é implementado em C++ e pode ser

compilado para diversas plataformas. Existem distribuições binárias oficiais para Windows que utilizam o Apache HTTPD ou IIS, bem como pacotes RPM, para utilização com Apache HTTPD em sistemas Linux. Serviços que suportam o Shibboleth SP: 11 Linux; 11 Mac OS X;

lInformações 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 módulo de autenticação que pode ser facilmente carregado pelo Apache. Esse componente é responsável por iniciar o protocolo de autenticação; 11 shibd: é um deamon responsável por resolver artefatos como, por exemplo, requisitar atributos do usuário autenticado.

Pré-requisitos para a instalação Verificar os pré-requisitos: 1 Sistema Operacional. 1 Base de pacotes de dependência. 1 Versão do Apache. 1 Versão OpenSSL. Antes de iniciar a instalação do serviço, é fundamental verificar todos os pré-requisitos de

sistema. Para a instalação do sistema Shibboleth Service Provider, é necessária a instalação prévia do Apache HTTPD e OpenSSL. Um requisito fundamental para todos os serviços é efetuar a configuração do serviço de sincronização de tempo (NTP), evitando problemas de horário na comunicação com o Provedor de Identidade.

24

q

Instalação via pacotes Com o comando apt-get podemos facilmente instalar as dependências, uma vez que todos os pacotes estão disponíveis nos repositórios distribuídos por padrão no Ubuntu.

#apt-get update #apt-get -y install apache2 libapache2-mod-php5 libapache2-mod-shib2 O módulo PHP do Apache não é necessário para o funcionamento do Shibboleth. Faremos aqui a instalação para utilizarmos essa linguagem em outros exemplos mais adiante.

Discovery Service Visão Geral:

q

11 DS (Discovery Service) Versão 2.x. 11 WAYF (Where Are You From) Versão 1.x. 22 Protocolo diferente. 11 Permite a escolha do provedor de identidades para autenticação. 11 Normalmente passa por intermediário para listagem das possibilidades. 11 Pode também redirecionar diretamente para o autenticador. Como um provedor de serviço em uma federação normalmente permite o acesso de usuários de diferentes instituições, um componente adicional é incluído na federação para auxiliar no redirecionamento dos usuários para os seus respectivos provedores de identidade. Esse componente, denominado Discovey Service (DS) a partir do Shibboleth 2.x, centraliza as informações sobre os provedores de identidade da federação e suas localizações, obtendo essas informações do arquivo de Metadados da Federação. Ao ser redirecionado para o DS, o usuário seleciona a sua instituição de origem e, em seguida, passa a interagir com o seu provedor de identidade para fornecer as suas credenciais.

autenticação ao IdP é o provedor de serviços (SP), e não o intermediário. Como esse protocolo é implementado pelo SP Shibboleth, é viável construir URL que solicita autenticação diretamente a um IdP.

Implementações do Discovery Service Discovery Service Embarcado: 11 Dentro do portal do próprio serviço é exibida a lista de instituições para escolha do usuário. 11 Usuário não é redirecionado para outra página. 11 Melhora a “experiência” do usuário. 11 Discovery Service Centralizado: 11 Usuário é redirecionado para fora da aplicação para escolha do IdP quando login é necessário.

q


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 serviço, exibindo uma lista de instituições para escolha do usuário, fazendo com que o usuário não seja redirecionado para outra página, permitindo melhor experiência. Já o modelo centralizado pode ser compartilhado e usado por diferentes aplicações. Nesse modelo, o usuário é redirecionado para fora da aplicação para escolha do IdP, quando o login é necessário.

Discovery Service embarcado A figura 2.2 exibe um exemplo de Discovery Service embarcado, usado no site do Provedor de Serviços CAPES. Dentro do próprio portal de periódicos, é exibida a lista de instituições usuárias do serviço (IdPs). Esse modelo é indicado quando se deseja melhor experiência de uso (evita redirecionamentos excessivos) e apenas um (ou poucos sistemas) no domínio do SP será federado, dado que em cenário oposto cada um dos sistemas necessitaria implementar sua própria interface, dificultando a manutenção. Por ser proprietário, possibilita


uma filtragem dos IdPs de interesse do serviço.

Figura 2.2 Exemplo de Discovery Service embarcado CAPES.

É viável a implementação de uma interface proprietária para atender ao protocolo. Entretanto, existem pacotes disponíveis que facilitam a utilização. Esses pacotes são geralmente APIs em javascript, que podem ser facilmente usadas pelas aplicações. Algumas implementações de referência: 11 DiscoJuice; 11 Shibboleth Embedded DS; 11 SWITCH Embedded Discovery Service/WAYF. 11 EDS – Embedded Discovery Service Shibboleth: 22 Implementação baseada em Json (Parser). 22 Necessita da versão 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

q

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, obtém essas informações do arquivo de Metadados da federação configurado no Shibboleth SP. Para visualizar o arquivo do Disco Feed, acesse a URL https://IP_SERVIDOR_SP/Shibboleth.sso/DiscoFeed. Essa é a URL padrão em servidor configurado com Shibboleth SP 2.X. Arquivos do EDS Shibboleth:

q

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 página padrão pelo arquivo idpselect.js, que é responsável pelas fontes. Recomendamos que esse arquivo não seja alterado pelo arquivo idpselect_config.js, responsável pela configuração (deve ser alterado de acordo com a documentação do sistema), e pelo arquivo idpselect.css cascading style sheets (CSS) para o EDS. Os arquivos de leiaute, disponíveis na instalação padrão, podem ser customizados de acordo com a necessidade da instituição para serem embutidos no site do serviço que estará federado.


11 idpselect.js

27

Exemplo de página IDP select test bed <meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-5” />
<script src=”idpselect_config.js” type=”text/javascript”

language=”javascript”> <script src=”idpselect.js” type=”text/javascript” language=”javascript”>

Passos para Instalação Shibboleth Discovery Service Embarcado:

q

11 Baixar arquivos. 11 Descompactar e copiar para o apache.


11 Configurar SSO para usar a url do DSE – shibboleth2.xml.

28

SAML2 SAML1 11 Verificar se Shibboleth possui serviço DiscoFeed.

11 Alterar a página do serviço inserindo o código do EDS ou testar a partir da página de teste do EDS “index.html”. A configuração do WAYF embarcado é bastante simples. Basta copiar os arquivos de configuração para o Apache. Porém, é necessário também que o provedor de serviços esteja instalado e configurado para utilizar o Discovery Embarcado. A configuração no DE é feita no arquivo Shibboleth2.xml informando a url da página principal do serviço.

Para usar a versão do Shibboleth DS embarcado, é necessário que a versão do provedor de serhandle: É usado para configurar manipuladores genéricos do provedor de Serviço que oferecem funcionalidades diversas que não se enquadram nas categorias abrangidas por outros elementos pré-definidos.

viços usado tenha suporte ao DiscoFeed, que é um handle disponível nas versões mais recentes do software que lista todos os IDPs habilitados no arquivo de metadados configurado. Para navegadores que não suportam JavaScript:

q

11 Gerar hiperlinks para cada IdP que será ser exibido no DS. 11 Dados necessários: 22 URL: a URL base do DS que você usa. 22 EI: o Entity ID do IdP. 22 RET: seu endereço de retorno para o serviço após o login no IdP.

11 Exemplo de hiperlinks para cada IdP

Discovery Service Centralizado O DS Centralizado pode ser usado por diferentes serviços, evitando que cada um faça sua implementação. Nesse modelo, é interessante quando o serviço é disponibilizado para todas as instituições participantes da federação ou se deseja poupar esforços mantendo interface proprietária. Um exemplo de implementação de DS centralizado é o Shibboleth Discovery Service. A figura 2.3 exibe a página de Discovery Service da Federação café. Esse é

Figura 2.3 Exemplo de Discovery Service Centralizado – Federação CAFe.


um exemplo de aplicação do Discovery Service Centralizado.

29

Instalação do Discovery Service Centralizado

q

Requisitos: 11 JDK 1.6 + 11 Tomcat 6.x Instalação: 1. Download do Discovery Service. 2. Descompactar em algum diretório. 3. Entrar no diretório descompactado. 4. Copiar as bibliotecas (Endorse Xerces e Xalan que estão dentro do diretório endorsed) para o tomcat ($TOMCAT_ROOT\common\endorsed). 5. Executar o install.sh com usuário 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 padrão é criada a pasta “/opt/shibboleth-ds”. Aí estão

localizados os arquivos de configuração, como o wayfconfig.xml, utilizado para especificar os arquivos de metadados. Para instalar o serviço, é necessário copiar o arquivo discovery.war, gerado na subpasta war, para a pasta webapps do Tomcat.

Configuração do Discovery Service Centralizado

q

Apontar para o arquivo de Metadata: 11 Configuração feita em /opt/shibboleth-ds/conf/ wayfconfig.xml

identifier=

url=”file:///etc/shibboleth/metadata.

xml”/> Configurar SP para redirecionar para DS Arquivo Shibboleth2.xml:


30

VIDOR:8080/discovery/WAYF> SAML2 SAML1

Dentro do arquivo de configuração do Discovery Service, é necessário especificar o caminho para o arquivo de metadados da Federação. É a partir desse arquivo que o serviço 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, além dos metadados dos IdPs, o metadado do SP para uso do Discovery Service. O próximo passo é a configuração da tag no arquivo shibboleth2.xml. O Atributo discoveryURL dessa tag deverá conter o endereço da página do Discovery Service que será usado.

3 Conhecer as configurações básicas necessárias para a execução do Provedor de Serviços Shibboleth.

conceitos

objetivos

Configuração do Shibboleth SP 2.4

Configuração do Shibboleth SP, desde a configuração do Apache HTTPD até a configuração dos arquivos básicos do Shibboleth Service Provider.

Certificados

q

11 Objetiva certificar que uma entidade é quem diz ser. 11 Baseado em chaves assimétricas.

O objetivo dos certificados é garantir a confiabilidade na comunicação entre IdP e SP. Não 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 configuração do SP.

2

SSL com Browser

CERTIFICADO

Resource CERTIFICADO

Webserver CERTIFICADO

Shibboleth Service Provider

SSL com IdP 3

Metadado

Figura 3.1 Certificados de Instalação Shibboleth SP.

Federação Assinatura CERTIFICADO

CERTIFICADO

Webserver Shibboleth Service Provider

Capítulo 3 - Configuração do Shibboleth SP 2.4

Home Organization

1

31

O SP usa, basicamente, dois pares de chaves em sua configuração. O primeiro par é indicado no contexto da comunicação do SP com o IdP no momento da troca do handle de autenticação. Nesse ponto, é interessante que seu valor não seja interceptado por terceiros, para evitar ataques. Para tanto, é importante que essa comunicação utilize SSL/TLS. Como a autenticação se dá via redirecionamento do SP para o IdP e vice-versa, o endereço de retorno deve ser protegido por canal seguro. Esse certificado deve ser aceito pelos navegadores para a efetivação da troca de mensagens. Para evitar mensagens indesejadas que os navegadores costumam disparar quando a autoridade certificadora emissora do certificado não é reconhecida, é interessante que esse certificado seja assinado por uma AC com raiz reconhecida. O segundo par é utilizado para estabelecer um canal seguro de comunicação do SP diretamente com o IdP, bem como para assinatura de mensagens trocadas entre essas partes. Como essa comunicação não passa pelo navegador web do usuário, não é necessário 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 federação e não pelo SP. Na Federação CAFe existem requisitos mínimos para a aceitação do par chave/certificado: 11 Nome distinto: o campo Common Name (CN) deve estar preenchido com o nome completo de domínio (FQDN) do servidor; 11 O certificado deve estar válido (não expirado) e o intervalo de tempo entre os campos notBefore e notAfter deve ser no máximo igual a 4 anos; 11 Deve ser usado o algoritmo SHA1 com encriptação RSA; 11 Deve ser utilizada uma chave RSA de no mínimo 1024 bits – recomenda-se 2048; 11 Deve possuir as extensões digitalSignature e keyEncipherment, acertadas como verdadeiro; 11 O certificado não deve possuir a restrição básica CA acertada como verdadeiro. Geração de certificado com parâmetros pré-configurados (openssl.cnf).

q

11 Geração da chave: Federação CAFe : Provedores de Serviços e Aplicações Federadas

#openssl genrsa 2048 -config openssl.cnf > `nomekey`.key

32

11 Geração 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 configurações necessárias para que os certificados gerados a partir dele cumpram todos os requisitos para aceitação do par chave/certificado pela Federação CAFe.

Arquivo shibboleth2.xml 11 Define a maioria das configurações do SP.

q

11 Foi renomeado para enfatizar a incompatibilidade com o arquivo shibboleth.xml da versão 1.3 11 Localização padrão:

/etc/shibboleth/shibboleth2.xml 11 Muitos atributos referenciam outros elementos definidos dentro do arquivo. 11 Algumas configurações realizadas nesse arquivo: 22 Indicação do caminho para arquivos de logs (tags OutOfProcess, InProcess). 22 Identificação do SP (entityID). 22 Indicação dos Metadados dos parceiros (MetadataProvider). 22 Configurações de Virtual Hosts (RequestMapper). 22 Indicação do caminho da chave e certificado para assinatura e SSL. O arquivo shibboleth2.xml é o principal arquivo de configuração do Shibboleth Service Provider (SP). Na versão 1.3 do shibboleth, esse arquivo era chamado shibboleth.xml, e foi renomeado para enfatizar a incompatibilidade entre as duas versões. A maioria das alterações nesse arquivo exige o reinício do deamon shibd para que o arquivo shibboleth.xml seja lido. Muitas vezes são utilizados identificadores para os elementos XML do arquivo, e esses são referenciados em outras partes. Isso simplifica a configuração por facilitar a pré-configuração de cenários diferentes e uso desses cenários em situações distintas (por exemplo, uso de pares de chaves distintos para comunicar com diferentes IdPs). Uma das principais configurações realizadas nesse arquivo é a definição do entityID, que é o nome pelo qual o SP é reconhecido pelas entidades federadas.

Configurações realizadas no shibboleth2.xml 11 Personalização de páginas de erros.

q

11 Mapeamento de requisições e suas configurações. 11 Configurações específicas para aplicações. 11 Indicação do IdP para autenticação (WAYF,DS, ou IdP diretamente). 11 Caminho para arquivo de mapeamento de atributos (Attribute-map.xml).

Personalização de páginas de erros Alguns problemas comuns na configuração do SP geram erros no acesso aos serviços. É possível personalizar a página exibida para o usuário com mensagens de erros mais esclarecedoras para auxiliar a resolver o problema.

Mapeamento de requisições e suas configurações É possível mapear nesse arquivo as configurações para as requisições de início e fim de sessão, como por exemplo timeout, uso de https etc.


11 Caminho para arquivo de política de filtro de atributos (Attribute-policy.xml).

33

Configurações específicas para aplicações Nesse arquivo também é possível personalizar as configurações de início de sessão para cada uma das aplicações protegidas.

Indicação do IdP para autenticação (WAYF,DS, ou IdP diretamente) É possível definir para aonde o usuário será redirecionado no momento em que solicitar acesso ao serviço federado: as opções são ir para um Discovery Service que centraliza as informações dos Provedores de Identidade parceiros da federação ou ainda ir diretamente para um provedor de identidade específico.

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á disponível na aplicação/serviço.

Caminho para arquivo de política de filtro de atributos (Attribute-policy.xml) Especifica-se o caminho do arquivo que define a política para aceitação dos atributos fornecidos pelos provedores de identidade.

Metadados indicam quais IdPs são reconhecidos Nos Metadados são listados todos os IdPs que estão disponíveis para autenticar usuários via federação e seus dados.

Pares de chaves podem variar em função do IdP contatado É possível definir um par de chave/certificado diferente para a comunicação com determinado Provedor de Identidade.

Estrutura do arquivo shibboleth2.xml O arquivo shibboleth2.xml, como a própria extensão sugere, é um arquivo que deve seguir a sintaxe XML. A estrutura do arquivo é definida de forma rígida, sendo validada contra um


esquema XML quando é carregado. Qualquer erro de validação impede que o serviço se inicie.

34

homeURL=“https://sp.example.org/index.html”/>

RequestMapper 11 Define as páginas que serão protegidas pelo shibboleth.

q

22 Equivalente ao recurso do Apache. 11 Permite ao SP isolar-se das diferenças de servidores. 11 Mapeia cada requisição às configurações específicas de cada aplicação (Atributo applicationId). 11 Elemento filho: RequestMap. O RequestMapper define quais serão as páginas protegidas pelo shibboleth e sua função é equivalente ao recurso Location do Apache. Ele permite que o SP se isole das diferenças de servidores, fazendo com que a configuração seja portável e funcione tanto em servidores Apache quanto ISS e outros. É feito o mapeamento de cada requisição às suas configurações específicas para cada aplicação usando o atributo applicationId. Possui uma função importante para proteger aplicações no Internet Information Services (IIS). O Apache HTTPD também pode ser utilizado, porém existe um conjunto de diretivas necessárias nos arquivos de configuração deste último.

RequestMap Atributos:

q

11 Herda os atributos do elemento raiz RequestMapper. 11 Deve conter um atributo applicationId com o valor default. Elementos filhos:

referência para outro ApplicationDefaults. 11 AccessControl – Controle de acesso: 22 22 22 O RequestMap possui o atributo applicationId, que mapeia o contexto da requisição e identifica qual a configuração que se aplica a ele. Os elementos filhos Host e Path indicam o contexto ao qual a configuração se aplica e o elemento filho AccessControl pode ser usado para definir regras básicas de autorização baseadas em aplicação de regras sobre os atributos do usuário.


11 – configuração de virtual hosts, pode redefinir o atributo applicationId com

35

Essa seção do arquivo é monitorada pelo deamon e pode ser alterada com o serviço ligado, aplicando as configurações feitas. O exemplo de configuração a seguir define o virtual host “admin.example.org” e protege o contexto secure com o shibboleth. Além disso, o elemento define uma regra para controle de acesso onde apenas usuários que possuírem o atributo affiliation igual a [email protected] ou [email protected] terão acesso ao contexto.

[email protected] [email protected]

ApplicationDefaults Id:

q


11 String – obrigatório.

36

11 Identificador único do ApplicationDefaults, deve ter o valor “default”. entityID: 11 URI – obrigatório. 11 É o identificador único SAML para nomear o SP. PolicyId: 11 String – obrigatório. 11 Referência para o elemento Policy definido dentro do elemento . O container ApplicationDefaults abriga as configurações de um SP, especificando o comportamento padrão e atuando como um recipiente para quaisquer outros elementos (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 definição do entityID é feita da seguinte forma no arquivo shibboleth2.xml:

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:

q

11 Atributo que será mapeado como cabeçalho REMOTE_USER. 11 Lista de strings delimitada por espaços. 11 Atributos listados em ordem de precedência. 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 serão mapeados no cabeçalho da requisição HTTP. Dada a lista de possibilidades, o primeiro atributo não vazio encontrado é mapeado dessa forma. Muitos serviços usam esse atributo em seus mecanismos de identificação do usuário (uPortal é um exemplo). O atributo signing indica se a assinatura de mensagens XML é requerida ou não, ou se é requerida em um caso particular (front channel ou back channel). Já o atributo encryption é

Sessions


semelhante, e possui a função de controlar a encripção de mensagens.

37

O elemento Sessions tipicamente discrimina uma série de handlers, usados para prover as funcionalidades-chave do SAML. Esse elemento é responsável 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 segurança, esse atributo deve ser utilizado com cautela, pois pode ser fonte de erros quando o usuário utiliza proxy ou NAT. Isso porque o IdP adiciona a informação do endereço IP do cliente autenticado na asserção. Quando definido como true, o endereço informado pelo IdP é confrontado com aquele apresentado pelo cliente, acusando erro caso não coincidam; 11 exportLocation e exportaACL: são usados em conjunto para possibilitar o acesso à asserção SAML associada à sessão. A partir da versão 2.4, esses elementos foram reagrupados em três grandes grupos , e . Essa organização permite uma melhor divisão por tipo de serviço.

SessionInitiator Exemplo padrão baseado nas versões anteriores à 2.4, direcionado para IdPs específicos, SAML2 sobre Shib1.


type=”Shib1” defaultACSIndex=”5”/>

38

Exemplo usando o estilo antigo do WAYF, onde o Shib 1 utiliza uma única entityID.

O elemento SessionInitiator indica como ocorrerá o início da sessão. O parâmetro Location indica o handler responsável por atender ao pedido de login e está associado aos handlers habilitados para o elemento Sessions.

Vários desses elementos podem ser definidos para uso em cenários diferentes: 11 Em um contexto federado, é interessante passar por um Discovery Service, o que é configurado em um iniciador de sessão; 11 Em uma intranet, o mesmo serviço pode remeter o usuário diretamente ao IdP. Isso também é uma configuração de iniciador de sessão. Uma forma de indicar qual SessionInitiator será utilizado é definir o atributo ShibRequireSessionWith nas configurações do Apache HTTPD ao proteger uma aplicação com autenticação Shibboleth.

Elementos filhos (Versão 2.4 e superiores).

q

11 Substitui o elemento < SessionInitiator> usando em versões anteriores. Um exemplo básico utilizando suporte ao protocol SAML:

SAML2 SAML1 Um exemplo usando um SAML Discovery Service:

SAML2 SAML1 Na versão 2.4 e superiores do Shibboleth SP, o elemento Session Initiator foi substituído por com seus valores padrão.

11 Configurações de manipulações de erros ocorridos na aplicação.

q


. Alguns atributos foram ocultos, mas continuam sendo definidos na configuração

39

supportContact=”root@localhost” logoLocation=”/shibboleth-sp/logo.jpg” styleSheet=”/shibboleth-sp/main.css”/> O Elemento Errors pode ser usado tanto para definir padrões de páginas que serão apresentadas em caso de erro, quanto para redirecionar o usuário para outros locais que farão um tratamento especial para cada tipo de erro.

q

11 Sobrescreve definições personalizando o comportamento relacionado com a comunicação para provedores de identidade ou grupos específicos de provedores.

O elemento permite ao SP personalizar seu comportamento quando interage com um provedor de identidades particular ou com um grupo de provedores de identidade. Por padrão, várias propriedades são definidas globalmente no elemento ApplicationDefaults. Esse elemento possibilita que sejam sobrescritas seletivamente. Se o elemento Name estiver presente, o processo de casamento para identificação do RelyingParty a ser usado começa 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 configuração de um elemento desses para comunicação com um IdP específico, outro utilizado para qualquer IdP de uma federação e um terceiro para utilização com qualquer outro IdP. Notify:

q

11 Configura notificação de logout da aplicação.

O elemento Notify pode ser usado para notificar operação de logout ou um evento de alteração no NameID enviado pelo IdP. Um caso típico de uso é forçar o logout em um IdP específico quando a sessão é terminada no SP (possível apenas quando se usa apenas um IdP para autenticação). Vale notar que isso não é o SLO, mas pode ser usado em uma intranet.

MetadataProvider.

q

11 Metadados dos provedores de identidade reconhecidos.

O elemento MetadataProvider indica para o SP quais são os IdPs confiáveis 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 próprio arquivo mantido localmente. Os metadados podem ser assinados e permitir que suas assinaturas sejam verificadas durante a recarga. É possível definir filtros nos metadados, tanto de black list (IdPs bloqueados) quanto de white list (IdPs aceitos). TrustEngine.

q

11 Mecanismo utilizado pelo SP para autenticar as mensagens.

Esse elemento indica de onde serão extraídas as informações de chaves utilizadas, desde SSL/TLS até verificação 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 também extrai conjuntos de âncoras confiáveis de extensões especiais dos metadados e aplica a validação do caminho de certificação.


41

AttributeExtractor:

q

11 Como atributos SAML são decodificados e expostos para os aplicativos. 11 Referencia o arquivo attribute-map.xml.

No arquivo attribute-map.xml é feito o mapeamento do nome dos atributos recebidos do IdP para o nome em que estarão disponíveis no SP e na aplicação protegida. O Shibboleth SP disponibiliza os atributos de duas formas: variáveis de ambiente (padrão do Shibboleth por ser mais seguro) ou cabeçalhos HTTP (menos recomendado o uso). Para receber os atributos via cabeçalhos http, é necessário habilitar essa opção no apache usando a propriedade: ShibUseHeaders On. CredentialResolver.

q

11 Configura a chave privada e o certificado usados pelo SP para identificar-se aos Provedores de Identidade.

Ou

/etc/shibboleth/sp.key


42

/etc/shibboleth/sp.crt É 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. 11 Elementos herdam todas as configurações do elemento , mas também podem substituí-los. 11 Configurar aplicações com comportamento diferente do padrão. 11 Alguns atributos do se tornam opcionais para o .

q

... ... Esse elemento possibilita várias configurações de SP em uma única instalação do serviço. O elemento define, minimamente, o atributo entityId, que é como o serviço será apresentado para a outra parte.

Principais configurações

requireSession=”true”/>

[...]


43

O ApplicationOverride permite que qualquer requisição recebida para o servidor virtual other.university.org use as configurações 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 Extração e mapeamento de atributos das asserções SAML para as variáveis de

q

ambiente ou cabeçalhos HTTP. 11 Tag Attribute. 22 Mapeia o atributo extraído em uma variável ou cabeçalho 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 variável de ambiente ou cabeçalho


HTTP pelo qual o atributo será disponibilizado para o aplicativo.

O arquivo attribute-map.xml mapeia atributos que chegam na asserção SAML em variáveis de ambiente ou headers HTTP nas requisições. Qual forma será utilizada não é regulada por esse arquivo, mas em configuração do servidor HTTP. Apache/cabeçalhos http: 11 Shibboleth 2 não recomenda o uso de cabeçalhos HTTP. 11 Variáveis de ambiente é o padrão, por serem mais seguras. 11 Para ativar o uso de cabeçalhos HTTP, ativar a property. Exemplo Apache:

AuthType shibboleth ShibRequereSession On

44

q

require valid-user ShibUseHeaders On Para que atributos sejam passadas para atributos da requisição em aplicações JEE utilizando o protocolo AJP, é importante ajustar o valor do atributo attributePrefix do elemento ApplicationDefaults para “AJP_”, caso contrário, os valores não são passados. O uso de cabeçalhos é desencorajado por poderem ser definidos diretamente no navegador web do cliente; entretanto, alguns serviços habilitados para shibboleth podem exigir que os atributos estejam ali disponíveis. Nesse caso, é necessário habilitar a passagem com a diretiva ShibUseHeaders On.

Elemento filho

q

AttributeDecoder. 22 Tag opcional que indica o extrator que será utilizado para realizar a extração das Asserções SAML. 22 Utilizados para extrair atributos mais complexos.

id=”affiliation”>

xsi:type=”ScopedAttributeDecoder”

caseSensitive=”false”/>

Para atributos que são simples strings, não é necessário usar esta tag, mas se os valores do atributo são mais do que simples strings, um personalizado precisa ser fornecido dentro do elemento para indicar como será feita a extração.


def:eduPersonPrincipalName” id=”eppn”>

45

... O trecho do arquivo de configuração 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 definições para o atributo “givenName”: o motivo é manter a compatibilidade com a versão 1.x do SAML que utiliza o padrão name=”urn:mace:dir:attribute-def:NOME_ATTR”. Já a versão SAML2 utiliza o padrão name=”urn:oid:x.x.x.x.x.

Arquivo attribute-policy.xml 11 Configuração da política de aceitação de atributos do SP com relação ao IdP. 11 Primeira parte do arquivo define regras para aceitação.

“ value=”staff” /> 11 Caso o valor da string case com um dos valores “faculty”, “student” ou “staff”, a regra é aceita.


q

Vários operadores podem ser utilizados na definição das regras de aceitação para o valor dos atributos. Em particular, a regra ANY é usada para aceitação 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 rejeição de atributos não causa erros no SP, sendo nesse caso filtrados e não serão repassados para o servidor HTTP. Segunda parte do arquivo mapeia a regra definida com um atributo específico ou grupo

q

de atributos. 11 Atributo attributeID contém o nome do atributo ao qual a regra se aplica idêntico ao especificado no arquivo attribute-map.xml.

As regras definidas para aceitação de atributos individuais são amarradas em políticas de aceitação, onde podem envolver o método utilizado para autenticação.

...

xmlns:saml=”urn:mace:shibboleth:2.0:afp:mf:saml” />


XMLSchema-instance”>

47

O trecho do arquivo attribute-policy.xml exibe a definição de regras para os atributos affiliation e todos os outros (*).

Diretivas de log Arquivos de Log do SP:

q

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 configuração de Níveis 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 níveis vão de TRACE (mais fino) a NONE (nenhum log). O primeiro arquivo possibilita definição dos níveis de log para a comunicação SP/IdP, possibilitando a análise até a nível de asserções SAML trocadas. Logs gerais do SP são enviados para o arquivo shibd.log, bem como mensagens SAML. Esse arquivo é o que deve ser consultado primeiramente em caso de investigação de problemas. O arquivo transactions.log apresenta transações de atributos passados ao servidor HTTP para cada sessão estabelecida.

Configuração do Apache HTTPD 11 Carregar módulo mod_shib.

q

11 Proteger contextos com authType shibboleth. 11 Configuração de SSL normalmente é necessário. As configurações que devem ser feitas no Apache HTTPD são mínimas. Basicamente se restringem a carregar o módulo de autenticação mod_shib e indicar os Location ou Directory que serão protegidos pelo módulo. As configurações de SSL são necessárias quando a aplicação protegida necessitar dessa funcionalidade, porém o shibboleth também deverá ser configurado para utilizar handles seguros (atributo handlerSSL do elemento Sessions com o valor true).

Devemos ter atenção especial para esse ponto: caso seja configurado para utilizar SSL, apenas requisições seguras serão tratadas, caso contrário, apenas requisições não seguras serão processadas.

Configuração do Apache Exemplo de configuração de Virtual Host no apache:

ServerName

$HOSTNAME

ServerSignature Off

# Redirecionamento para SSL RewriteEngine on RewriteCond %{HTTPS} !=on RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [R,L]

Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all


DocumentRoot /var/www/

49

Esse arquivo faz uso do mod Rewrite do apache para redirecionar todo acesso para a porta 443 com SSL.

Configuração do Apache – Certificados Exemplo de configuração de Virtual Host https:

q

NameVirtualHost *:443 ServerName

servidor.instituicao.br

SSLEngine

on

SSLCertificateFile /etc/shibboleth/nomeCertificado.crt SSLCertificateKeyFile /etc/shibboleth/nomeChave.key DocumentRoot /var/www-ssl/ AuthType shibboleth ShibRequireSession On require valid-user Order allow,deny allow from all O certificado configurado no arquivo de virtual hosts é o que será exibido no browser para o usuário no momento de acesso ao recurso protegido pelo Shibboleth. Aqui é aconselhável


usar um certificado assinado por uma CA reconhecida pelos navegadores para evitar a exi-

50

bição de mensagens de alerta. Após a criação dos arquivos de Virtual Host, é necessário habilitar os sites e módulos:

# a2enmod shib2 # a2enmod ssl # a2enmod rewrite # a2ensite shibboleth-sp

4 Entender como é feita a configuração da autenticação em aplicações que já possuem suporte nativo ao Shibboleth.

Autorização/Autenticação via servidores web; Configuração de Autenticação Shibboleth no Moodle; Mapeamento de Atributos do SP para a aplicação.

conceitos

objetivos

Configuração de autenticação Shibboleth

Utilização de autenticação Shibboleth Arquitetura de autenticação 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

Capítulo 4 - Configuração de autenticação Shibboleth

Figura 4.1 Arquitetura de autenticação Shibboleth.

4 Send handle / ID to service provider 51

Usando o Security Assertion Markup Language 2.0 (SAML2) através do web browser SSO profile, o usuário pode acessar um recurso em um provedor de serviços ou acessar um provedor de identidades, de tal forma que o provedor de serviços e o recurso desejado são conhecidos ou estão implícitos. O usuário se autentica no provedor de identidades que produz uma asserção de autenticação; o provedor de serviços consome a asserção para estabelecer um contexto seguro na sessão do navegador web. Durante esse processo, um name identifier deve ser também estabelecido entre os provedores para o principal, sujeito aos parâmetros da interação e ao consentimento das partes. O name identifier é geralmente usado para identificar a pessoa sobre a qual a asserção enviada pelo IdP versa. Name identifiers podem ser qualquer coisa; um endereço de e-mail ou um principal name Kerberos são exemplos comuns do dia a dia de tais informações. Para implementar esse cenário, um profile do protocolo SAML Autentication Request é usado em conjunto com o HTTP Redirect, HTTP POST e HTTP Artifact bindings. É assumido que o usuário está usando um navegador comercial padrão e pode se autenticar em um provedor de identidades por algum meio fora do escopo do SAML.

Front e back channels Front channel.

q

11 Comunicação via web browser. Back channel. 11 Comunicação por contato direto IdP/SP.Os conceitos de front e back channel são comuns em se tratando de SAML. Nos protocolos que utilizam o front channel a comunicação é feita via redirecionamento do navegador web do usuário. Um exemplo de comunicação fronte channel é o envio da asserção de autenticação do IdP para o SP. O back channel usa normalmente um canal seguro para troca direta de informações entre as partes, utilizando um web service. A solicitação de atributos do usuário é geralmente feita via back channel, como um tipo de resolução de artefato (o SP envia o handle do usuário e o IdP resolve os atributos). Outras implementações de SAML, como o SimpleSAMLPhp, usa o


front channel para envio dos atributos, juntamente com a asserção de autenticação.

52

Autenticação/autorização via servidor web Apache 11 Autenticação gerenciada nas diretivas , ou . 22 Arquivos .htaccess. IIS 11 Autenticação gerenciada nas configurações do Shibboleth. 22 Elemento RequestMapper, shibboleth2.xml. A autenticação shibboleth pode ser requisitada pela definição 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

q

11 ShibRequireSession On 11 Require valid-user

AuthType Shibboleth

ShibRequireSession On

require valid-user

No IIS, a proteção deve ser realizada, necessariamente, via elemento RequestMapper do arquivo shibboleth2.xml. As regras básicas para autorização podem ser definidas com o atributo “require”. É importante salientar que todas as requisições feitas através dos contextos protegidos carregarão os atributos obtidos no processo de autenticação, e não apenas a primeira requisição. As requisições realizadas em outros contextos não possuirão tais atributos.

Autorização via Shibboleth

q

11 Permite o uso de comandos familiares do Apache. 11 Funciona apenas no Apache. 11 Plugin que implementa uma linguagem simples para controle de acesso usando XML. 11 Suporta combinar regras com os operadores lógicos. 11 Solução portável. A autorização pode ser definida pelo elemento RequestMap, onde dois elementos são disponibilizados: o e o . O primeiro só é aplicável ao servidor Apache HTTPD. O segundo é uma solução portável entre os servidores.

[email protected] [email protected]


53

Esse trecho exibe dois exemplos de proteção com shibboleth. No primeiro caso, todas as requisições feitas para http://www.example.org/secure são protegidas com autenticação shibboleth. Nenhuma restrição de controle de acesso é feita nesse nível. Já no segundo caso, as requisições feitas para http://admin.org requerem autenticação shibboleth e utilizam as configurações de aplicação com id admin (provavelmente derivada de um ApplicationOverride). Além disso, é definida uma regra de controle de acesso que só permite a passagem de usuários cujo atributo affiliation seja [email protected] ou [email protected]. Uma resposta HTTP 403 é dada caso as exigências não sejam cumpridas.

Utilização de autenticação Shibboleth “Shibboleth Enabled Applications”

q

22 Ensino a distância: 33 Moodle, Blackboard, Sakai e OLAT. 22 WIKI: 33 Media Wiki, Confluence Wiki e Dokuwiki. 22 Portal: 33 Uporta e Joomla. 22 Correio eletrônico: 33 SYMPA e Google Apps/Email. 22 Blogs: 33 WordPress. Várias aplicações possuem plugins para realizar autenticação via Shibboleth, o que incentiva ainda mais a implantação de Provedores de Identidade e do serviço na instituição. Essas aplicações não precisam ter seu código alterado, sendo necessárias apenas algumas configurações no Apache HTTPD e na aplicação. Veremos, a seguir, como isso pode ser feito para o software de ensino a distância Moodle.


Estudo de caso: Moodle

54

Moodle: 11 Modular Object-Oriented Dynamic Learning Environment.

q

22 Software livre de apoio à aprendizagem em ambiente virtual. 22 Sistema de gestão de aprendizagem. 11 Principais recursos: 22 Chat, glossário, fórum, questionários e blog. 22 Gestão de conteúdos. 22 Suporte à autenticação 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 criação de sites de aprendizado eficazes. Tornou-se muito popular entre os educadores de todo o mundo como uma ferramenta para criar sites de web dinâmicos para seus alunos.

Pré-requisitos Moodle instalado.

q

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 discussões desta sessão não versam sobre os detalhes de instalação do Moodle. Assumiremos apenas que foi instalado com sua configuração padrão. Além das ferramentas instaladas neste curso, faremos uso de um provedor de identidades previamente instalado na máquina do instrutor, além do banco de dados MySQL e do software Moodle na VM do aluno.

Configurações no Apache Arquivo virtual Host do Apache.

q

11 Localização: /etc/apache2/sites-enabled 11 Proteger /auth/shibboleth/index.php

AuthType shibboleth ShibRequireSession On require valid-user 11 Possibilidade de usar outras restrições

require affiliation student No caso do Moodle, deve-se proteger uma página de login alternativa com o Shibboleth. A página de login via outros tipos de autenticação continua disponível e outros tipos de

Configurações no Moodle 11 Acessar Moodle e logar como administrador. 11 Ativar a autenticação Shibboleth no Moodle. 22 Tela principal do Moodle.

q


autenticação podem ser usados.

55

Figura 4.2 Tela de Administração do Moodle.

Para configurar a autenticação via Shibboleth, é necessário que o adminstrador do Moodle logue-se e acesse o menu principal de configurações:


“Administração do site” > “Plugins” > “Autenticação” > “Gerenciar Autenticação”.

56

Figura 4.3 Menu do Administrador Moodle.

Para encontrar a tela de configuração de Autenticação via Shibboleth, podemos percorrer todo o menu de configurações ou ainda é possível optar por pesquisar por “Shibboleth” na opção Buscar, localizada abaixo do menu, para que a tela de configuração seja exibida. 11 Ativar a autenticação Shibboleth. 11 Configurar as preferências.

q

Figura 4.4 Configurações de autenticação Moodle.

O Moodle possui várias opções de plugins para autenticação de usuários, entre elas a opção Shibboleth. Primeiro é necessário ativar a autenticação Shibboleth, clicando sobre o ícone do olho fechado, que é exibido. O ícone será alterado para um olho aberto, indicando que a autenticação está ativa. Em seguida, deve-se clicar no link de “Configurações” para fazer os ajustes de mapeamentos de atributos e preferências. Configurações: 11 Nome de Usuário; 11 API de modificação 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 Página de mudança de senha

namento após o logout da aplicação, a página para mudança de senha e a lista de IdPs para o WAYF (caso seja interessante o uso). Os atributos recebidos do IdP também devem ser mapeados para os respectivos dados do perfil de usuário, que é criado ou atualizado no Moodle. O Moodle exige o mapeamento de pelo menos um atributo, que será usado como identificador do usuário. Esse atributo pode ser, por exemplo, o CPF, e-mail, ou um identificador opaco do usuário. Mapeamento de atributos Shibboleth/Moodle: 11 Nome; 11 Sobrenome; 11 Endereço de e-mail; 11 Cidade/Município; 11 País;


Entre as configurações para a autenticação Shibboleth, é possível definir a url para redirecio-

57

11 Idioma; 11 Descrição; 11 Página Web; 11 Número ID; 11 Instituição. 11 ... Os dados sobre o perfil do usuário poderão ser preenchidos automaticamente caso o provedor de identidade que autenticou o usuário os forneça 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 aplicação Moodle. O nome mapeado deve ser aquele indicado no arquivo attribute-map.xml, ou seja, o nome local com os quais os atributos são mapeados para o servidor web. É possível definir se haverá a atualização dos valores retornados para os atributos; essa atualização pode ser apenas quando o usuário for criado ou a cada login. Outra opção é blo-


quear ou não o valor: quando o atributo está marcado como bloqueado, o próprio usuário

58

não consegue atualizar a informação. Nesse caso, os atributos obtidos pelo processo de autenticação sempre vão 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 Atualização local: 33 Define quando será realizada a atualização dos dados, ao logar ou apenas no primeiro acesso do usuário. 11 Bloquear valor: 22 Define se os dados serão bloqueados para edição do usuário.

q

Group Management Tool (GTM) 11 Função de criar e gerenciar grupos de usuários.

q

11 Aplicação web PHP. 11 Código aberto (licença BSD). 11 Informações podem ser usadas. 22 Via arquivo .htaccess. 22 Via arquivo de controle de acesso XML AccessControl. 22 Via interface PHP ou Perl por outras aplicações. O GMT tem como principal característica a gestão de grupos federados. É uma aplicação web desenvolvida pela SWITCH para criar e gerenciar grupos de usuários Shibboleth de diferentes provedores de identidade. A informação de grupos pode ser usada por outras aplicações web para decisões sobre controle de acesso. Isto é feito, por um lado, gerando arquivos .htaccess para restringir acesso a diretórios do servidor web baseado em um identificador único do usuário. Por outro lado, a informação 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 é possível verificar quais grupos estão cadastrados e se possuem arquivos de autorização vinculado ao grupo. Recursos do aplicativo Group Management Tool: 11 Gerir vários grupos para várias aplicações; 11 Três funções de usuário/administrador com privilégios diferentes; 11 Transferência de privilégios para outros usuários; 11 Convidar novos usuários para participar de um grupo via e-mail; 11 Usuário pode pedir para participar de um grupo (autoinscrição); 11 Gerar arquivos de autorização (Apache .htaccess); 11 API para uso em máquinas remotas.


Figura 4.6 Tela principal aplicação GMT.

59

60


5 Aprender as diferentes formas de implementar a autenticação Shibboleth em uma aplicação.

conceitos

objetivos

Aplicações Federadas

Autenticação Shibboleth em aplicações; Recuperação de atributos Shibboleth em diferentes linguagens.

Módulo mod_shib 11 Parte da arquitetura Shibboleth é acoplada ao servidor web.

q

11 No caso do servidor web Apache, esse acoplamento ocorre através do módulo mod_shib. 11 Configuração similar aos módulos mod_auth_basic e mod_ssl.

Servidor de Aplicações Apache shibd

mod_proxy

O mod_shib é usado para proteger as aplicações web no Apache HTTPD. Esse módulo trabalha em conjunto com o deamon shibd para atender ao protocolo SAML2. De forma simplificada, o mod_shib é usado para interceptar as requisições do usuário e o shibd para atender ao protocolo SAML2 (resolução de artefatos, por exemplo). Podem ser protegidos elementos do tipo , ou através do arquivo de configuração do apache ou através de um arquivo .htaccess.

AuthType shibboleth ShibRequireSession On ShibRequireAll On require mail ~.*@ufmg.br$

Capítulo 5 - Aplicações Federadas

Figura 5.1 Arquitetura Shibboleth SP.

61

A configuração pode ser realizada nos arquivos de virtual hosts do apache ou em arquivos .htaccess. Nesse exemplo o diretório protegido pelo Shibboleth será acessado apenas por usuários que possuem o email com domínio ufmg.br.

Opções do mod_shib Principais diretivas:

q

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 seção iniciada; 11 require shibboleth: decisões sobre o acesso ao recurso dependem das configurações encontradas no RequestMapper do shibboleth2.xml. 11 ShibRequireAll on/off: 22 on: são feitas operações AND entre as regras; 22 off: são realizadas operações OR entre as regras (default). ShibRequireSession on/off: determinar quando é necessário exigir uma sessão Shibboleth para acessar um recurso. Quando é configurado com o valor “off”, a aplicação tem de disparar a criação de uma seção quando necessário; ShibRequireSessionWith : indica que o session initiator para aquele contexto deve ser aquele identificado por ; ShibUseHeaders on/off: o Shibboleth 2.0 usa por padrão as variáveis de ambiente em vez dos cabeçalhos HTTP para incrementar a segurança. Não há diferença para a maioria das


aplicações, a não ser quando há uma estrutura de proxy e forwarding;

62

Protegendo aplicações O modo como uma aplicação é “federalizada” depende de algumas características

q

do sistema: 11 Disponibilidade do código-fonte. 11 Aplicação pública com privilégios para usuários autenticados. 11 Necessidade de dados do usuário na aplicação. Respondendo a estas questões é possível definir qual a melhor estratégia para proteger a aplicação com Shibboleth. 11 Disponibilidade do código fonte: dependendo de como é construído o objeto de usuário e é dada autorização a ele, pode ser necessário alterar esse mecanismo; 11 Aplicação pública com privilégios para usuários autenticados: alguns tipos de aplicações disponibilizam todo o conteúdo para navegadores anônimos, entretanto, usuários autenticados podem ter mais privilégios, dependendo de suas autorizações. Blogs e wikis são casos típicos desse modelo;

11 Necessidade de dados de usuário na aplicação: algumas aplicações podem necessitar apenas que o usuário seja autorizado de alguma forma, sem, contudo, criar efetivamente um contexto para ele. Esse tipo de sistema pode ser facilmente “federalizado” pela solicitação de autenticação shibboleth e restrição de acesso a pessoas autorizadas, com autorização definida a nível de servidor web.

Formas de proteger aplicações 11 Toda a aplicação.

q

11 Toda a aplicação com o mecanismo de lazy sessions. 11 Somente a página que cria uma sessão na aplicação.

page

page

login

page

page

page

login

Figura 5.2 Formas de proteger uma aplicação com Shibboleth.

page

page

page

login

Protegendo toda a aplicação Solução mais simples. 11 Todo acesso requerido deve ser feito mediante autenticação shibboleth. 11 Desvantagem: não há nenhuma parte da aplicação acessível sem autenticação.

AuthType shibboleth ShibRequireSession On require valid-user

q Capítulo 5 - Aplicações Federadas

page

63

A solução de proteger toda a aplicação também não atende para o caso de uma aplicação que precisa ter outros métodos de autenticação. A solução é adequada para controle de acesso a conteúdos estáticos ou para aplicações que necessitem de autenticação prévia para todas as operações. É uma solução não amigável, porque nenhuma “home page“ é exibida antes do login.

Protegendo parte da aplicação Este método permite que a autenticação Shibboleth seja acionada somente quando necessária.

AuthType shibboleth ShibRequireSession On require valid-user Neste exemplo apenas a página login.php é protegida pelo Shibboleth. As outras páginas da aplicação não têm esse requisito. Essa forma é também interessante em casos onde vários métodos de autenticação são suportados; a página em questão seria apenas uma forma de criar a sessão do usuário com atributos provindos da autenticação shibboleth. Outras partes do sistema podem requerer apenas que exista uma sessão estabelecida para o usuário ou podem ser, ainda, públicas. Por suportar bem outros tipos de autenticação, é uma das soluções mais indicadas.

Lazy sessions 11 Proteção via regras baseadas na URL do recurso.

q

11 Verificação de sessão pelas variáveis de ambiente. 11 Redirecionamento explícito para SessionInitiator.


11 O controle de acesso fica completamente por conta da aplicação.

64

11 Url: https://servidor/Shibboleth.sso/Login?target:”http://servidor/applicacao”. Lazy sessions é muito usado quando um site possui acesso público e privado para os mesmos recursos. É útil para aplicações dinâmicas que tipicamente desejam oferecer um modo “guest” por padrão e iniciar um login de usuário apenas quando escolhido pelo usuário. Funciona da seguinte forma: o recurso é protegido por Shibboleth, mas não requer uma sessão ativa. Assim, as requisições passam normalmente, mas se o usuário não foi autenticado, as variáveis de ambiente ou cabeçalhos HTTP não são mapeados. A aplicação faz a verificação da presença de tais informações (atributos personalizados, REMOTE_USER etc.) para decidir pela autorização ou não. Quando o usuário deseja criar sua sessão, a aplicação deve disparar explicitamente um redirecionamento HTTP para a URL indicada pelo handler de SessionInitiator com alguns parâmetros. Usado em: 11 Aplicações que têm funcionalidades que não necessitam de sessão de usuário todo o tempo; 11 Aplicações que suportam vários mecanismos de autenticação.

AuthType shibboleth ShibRequireSession Off require shibboleth

Proxy reverso Única opção viável para uma aplicação proprietária onde o método de autenticação não pode ser adaptado ao Shibboleth.

Figura 5.3 Protegendo aplicação com Proxy Reverso.

Shibboleth SP

mod_proxy

apache

Aplicação

O método de proxy reverso é usado quando a aplicação não suporta autenticação Shibboleth nativamente. Aplicações JEE são o caso típico. Nesse cenário, todas as chamadas são interceptadas pelo servidor Apache, que então repassa as chamadas para a aplicação. No caso de aplicações JEE, esse repasse é feito via protocolo AJP. Única opção viável para uma aplicação proprietária onde o método de autenticação não pode ser adaptado ao Shibboleth.

ProxyPass /app http://Servidor/app AuthType shibboleth ShibRequireSession ON require shibboleth O método de proxy reverso é usado quando a aplicação não suporta autenticação Shibboleth nativamente. Aplicações JEE são o caso típico. Nesse cenário, todas as chamadas são interceptadas pelo servidor Apache, que então repassa as chamadas para a aplicação.

Atributos e mapeamentos Atributos: 11 Representam informações relativas ao usuário como nome, e-mail, filiação etc. 11 Podem ser disponibilizados pelo SP para a aplicação através de variáveis de ambiente ou cabeçalhos http. 11 As aplicações podem utilizá-los para realizar a autorização de usuários.

q


No caso de aplicações JEE, esse repasse é feito via protocolo AJP.

65

Os cabeçalhos HTTP são inseguros, pois são podem ser gerados a partir do navegador web, podendo ser forjados. As variáveis de ambiente web são disponibilizadas à aplicação diretamente pelo servidor, impedindo essa possível falsificação. Variáveis de ambiente web são padrão no Shibboleth2. Nem todos os servidores suportam variáveis de ambiente web, como é o caso do IIS. Mapeamentos:

q

11 Definem o nome de cabeçalho ou variável de ambiente web para cada nome de atributo. 11 São configurados no SP pelo arquivo attribute-map.xml. 11 Exemplo de um mapeamento para o atributo “cn”:

11 O atributo name da tag Attribute representa um espaço de nome universal. 11 O atributo id define o nome do cabeçalho HTTP ou variável de ambiente web a ser fornecida pelo SP. 11 Utilizam-se duas tags para manter compatibilidade entre os protocolos SAML1 e SAML2.

Autorização via aplicação 11 A estrutura Shibboleth autentica o usuário e fornece os atributos para a aplicação.

q

11 A aplicação é responsável pela autorização. 11 Nem a aplicação, nem o servidor HTTP manipulam a senha do usuário. 11 Há necessidade de atributos comuns/compatíveis entre os IdPs para uma autorização global. Após a autenticação, o Provedor de Serviços (SP) pode solicitar ao Provedor de Identidades (IdP) atributos do usuário. De acordo com a política de liberação de atributos acordada entre IdP e SP, os atributos podem ser liberados para que o SP repasse para a


aplicação. A aplicação, de posse desses atributos, pode utilizá-los para controle de acesso

66

dos usuários. Para que a autorização seja global (para todos os usuários da aplicação), é necessário que todos possuam atributos em comum que deverão ser utilizados na autorização de acesso aos recursos. Definir atributos necessários para a autorização e recomendá-los às instituições.

IdP B

IdP A

IdP C

SP

Estudantes (autorizados)

Téc. Administrativos

O que fazer se os usuários não possuírem atributos em comum? Algumas possíveis soluções: 11 Criar atributos em comum; 11 Usar GMT para criação de grupos federados; 11 Usar Unique ID ou email para autorização (autorização individualizada no SP). Atributos disponibilizados pelo esquema brEduPerson que podem ser utilizados para a

q

autorização: 11 brEduAffiliationType 22 Tipo de vinculo com a instituição. 11 brEntranceDate 22 Data de início de vínculo. 11 brExitDate 22 Data de fim do vínculo. A Federação CAFe recomenda a disponibilização de alguns atributos e define seus nomes e semânticas, caso sejam utilizados. Os atributos brEduAffiliationType, brEntranceDate e brExitDate são atributos interessantes para uzar como base para autorização para grandes grupos de usuários. Os tipos de vínculos recomendados no esquema brEduPerson são: 11 Faculty (professores , administradores); 11 Student (estudante);


Figura 5.4 Regras de autorização via atributos.

Professores

Regra: Afiliação: estudante

67

11 Staff (pessoal); 11 Position (coordenador etc.); 11 Scholarshipawardee (iniciação, pó ...); 11 Other (contrato de outro tipo). A autorização também pode ser assistida por uma base relacional proporcionando.

q

11 Maior flexibilidade: 22 Liberdade na criação das regras de autorização. 11 Facilidade de Integração: 22 Maior facilidade no relacionamento com outras bases. 11 Necessidade de manutenção: 22 As regras devem ser criadas e mantidas pela aplicação. As aplicações podem manter bases adicionais para controle de acesso. Dessa forma, os atributos recebidos no processo de autenticação federada podem servir como chave para busca de autorização na base local. Há um custo adicional para manutenção dessa base, mas muitas vezes isto é necessário.

Configuração para containers JEE Para aplicações Java Web utilizando Tomcat e Apache2:

q

11 Instalar o módulo mod_proxy_ajp; 11 Repassar chamadas do Apache para o Tomcat; 11 ProxyPass /minappp ajp://servidor:8009/appjee; 11 Proteger o contexto para criação da sessão de usuário.

AuthType Shibboleth ShibRequireSession On require valid-user


68

O Tomcat é um servidor web Java, mais puramente, um container web JEE. O mod_proxy_ajp é um módulo do Apache usado para implementar um proxy reverso entre o Apache HTTPD e containeres web JEE, que tipicamente respondem ao protocolo AJP. As requisições são feitas, dessa forma, para o servidor Apache. Este intercepta a chama e verifica que o contexto necessita autenticação Shibboleth. Antes da autenticação ser completada, o Apache ainda não tem conhecimento de que tipo de recurso está sendo solicitado (página web, arquivo binário, imagem, aplicação php, aplicação JE, etc.). Ao final do processo de autenticação, o Apache HTTPD pode observar que age como um proxy para a aplicação JEE, o que é indicado pela diretiva ProxyPass. A requisição é complementada com os atributos obtidos e enviada ao container web via protocolo AJP. O container web, por sua vez, processa a requisição (possivelmente criando uma sessão para o usuário) e devolve a resposta para o Apache, que então a repassa ao navegador cliente.

11 Recuperação via atributos da requisição.

q

uid = request.getAttribute(“ShibCafe-InetOrgPerson-Uid”); 11 Recuperação via HTTP header. uid = request.getHeader(“HTTP_SHIBCAFE_INETORGPERSON_UID”); Na aplicação JEE, os atributos podem ser recuperados via atributos da requisição ou via HTTP headers (caso esta opção esteja habilitada no Apache). Note que via headers os atributos são em maiúsculo e pré fixados de HTTP.

Configuração para PHP 11 PHP se integra nativamente ao Apache.

q

11 Não é necessário utilizar proxy. 11 Proteção 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); // verificação de regras e outros processamentos... } else{ // Erro: atributo não encontrado! } Em PHP, para ter acesso aos atributos repassados pelo Shibboleth via Headers, é necessário acrescentar HTTP_ como prefixo e trocar – por _ além de ser em caixa alta. Exemplo: O atributo mapeado no arquivo attribute-map.xml com nome ShibPerson-cn estará disponível no apache via cabeçalho com o nome: HTTP_SHBPERSON_CN. Caso seja repassado como variável de ambiente, estará disponível com o mesmo nome mapeado no arquivo attribute-map.xml.

Configuração para outras linguagens 11 Perl:

q

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

Implementação da autorização Autorização por vínculo. 11 Autorização por vínculo; 11 Mapear tipos de vínculo com um nível de autorização específico; 22 Identificar os vínculos da identidade; 11 Consultar o valor do atributo brEduAffiliationType; 11 Realizar autorização; 22 Comparar o nível de autorização da página (recurso) com os níveis dos vínculos da identidade. Para realizar a autorização, a aplicação necessita conhecer todos os possíveis valores dos atributos para poder definir as regras de acesso que deverão ser aplicadas.


Será necessário definir níveis de autorização para cada um dos vínculos possíveis.

70

q

6 Explorar algumas configurações avançadas do Provedor de Serviços Shibboleth.

conceitos

objetivos

Configurações Avançadas do Shibboleth SP

Esta sessão irá demonstrar como simular dois Provedores de Serviços lógicos, cada um se comportando de maneira distinta, em uma única instalação física do software.

SPs Lógicos e Físicos 11 Uma única instalação do software SP pode atuar como “serviços” lógicos distintos,

q

e um único “serviço” lógico pode abranger qualquer número de hosts físicos. O primeiro ponto a destacar é que o termo “Service Provider” (SP) como um monte de outras definições em computação, é composto pela parte física (os bits de software que você está

l instalando) e a parte lógica (a noção de um serviço).

Para fins de SAML, um SP é simplesmente qualquer sistema que está aceitando autenticação de um IdP. Este “sistema“ pode ser uma centena de servidores web, um único servidor web, ou um único diretório em um servidor web, isso não está definido. Além disso, cada SP tem um nome exclusivo chamado de EntityID que nomalmente é uma URL que se parece com um endereço da web, mas na verdade é apenas um identificador para rotular o SP e identificá-lo na Federação.

Razões válidas pra adicionar um SP lógico 11 Casos em que um SP adicional deve ser definido:

q

22 Necessidade de simular 2 SPs, alterar o EntityID (ou seja, expondo um SP lógico adicional a partir de uma única instalação física); 22 Metadados diferente ou política de segurança (Certificados); 22 Diferente mapeamento de atributo ou regras de filtragem por serviço; 22 Regras diferentes para o comportamento de sessões, tal como o tempo de espera. Antes de fazer a configuração de um SP lógico é necessário analisar se realmente há necessidade. Em Alguns casos apenas com configurações personalizadas é possível atender algumas demandas específicas para alguma aplicação sem a necessidade de definir um novo

Capítulo 6 - Configurações Avançadas do Shibboleth SP

O conceito de SP representa apenas alguma coleção de recursos que compõe um “serviço” coerente.

SP na mesma configuração. 71

Quando se deseja que dois serviços distintos cada um responda com um Identificador próprio (EntityID do SP) é necessário fazer a configuração de um SP lógico, sobrescrevendo a propriedade EntityID. Este serviço então terá seu próprio Metadata e responderá como um serviço distinto mesmo estando fisicamente instalado no mesmo SP Físico.

Quando não há necessidade 11 Aqui estão alguns casos de uso em que um SP lógico não precisa ser definido;

q

22 Utilização de um serviço 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 Manipulação de erro personalizada. Alguns desses casos de uso em versões mais antigas do Shibboleth necessitavam de definição de um novo SP lógico, mas agora há uma variedade de opções avançadas disponíveis

wPara mais detalhes

através de configurações de conteúdo. Em vez de criar um monte de configuração XML extra, você pode simplesmente definir propriedades usando Apache ou o baseado no host virtual ou caminho, e alterar muitos comportamentos.

Configurando um SP Lógico 11 Ao utilizar a configuração de SP Lógico:

q

22 Cada SP poderá usar um certificado diferente, ter seu próprio EntityID, e seu próprio arquivo de Metadata; 22 Pode autenticar em um IdP, liberando asserções SAML e atributos distintos, ou apresentar uma página de login específica para cada caso; 22 Definir o próprio arquivo de mapeamento e filtro de atributos. Ao realizar a configuração de um SP lógico ele estará compartilhando a mesma instalação


física do seu provedor de serviço, mas logicamente irá se comportar como uma outra insta-

72

lação, e responderá isoladamente pelas requisições feitas ao serviço configurado, de acordo com as configurações que foram sobrescritas através da tag . É possível definir um novo par de chave/certificado, alterar o identificador do provedor de Serviços (EntityID), criar um novo arquivo de mapeamento e filtro de atributos, alterar configurações de início de sessão como tempo de espera, qual IdP redirecionar na autenticação e definir novo arquivo de Metadados de IdPs parceiros. Há duas formas de configurar um SP Lógico 11 Utilizando Virtual Hosts; 22 Caso de 2 aplicações cada uma em um virtual host: www.app1.br e www.app2.br; 22 Cada um dos hosts será um SP lógico; 22 Forma usual e mais simples; 11 Utilizando paths; 22 2 aplicações 1 em cada diretório de um servidor: /app1 e /app2; 22 Cada um dos diretórios será um SP lógico.

q

sobre propriedades que auxiliam na configuração personalizada do seu provedor de serviços acesse NativeSPContentSettings no site em https:// wiki.shibboleth.net.

A forma usual de configurar um serviço adicional é através de virtual hosts. Cada um dos hosts irá se comportar como um SP e ter suas configurações personalizadas para o serviço. Quando se usa dois virtuais hosts o arquivo de metadata pode ser obtido automaticamente através do handle /shibboleth.sso/Metadata sendo acessado via navegador com o nome de cada virtual host. Existe outra opção que é utilizar diretórios. Com esta configuração o arquivo de metadado deve ser gerado pelo usuário, não é gerado automaticamente. A url de handle irá mudar adicionando o nome do diretório antes: por exemplo https://SERVIDOR/homologa/Shibboleth.sso/

Configurações necessárias 11 Arquivo /etc/shibboleth/shibboleth2.xml;

q

22 O ApplicationDefaults tem um identificador simples associado a ele, que é id=“default”; 22 A aplicação “default” é a padrão que configura o comportamento da primeira aplicação utilizada; 22 Ao criar um ApplicationOverride, para definir uma nova aplicação, ele irá sobrescrever as propriedades que forem citadas; 22 As propriedades não citadas continuam sendo herdadas do apllicationDefaults. Para configurar um novo SP o primeiro passo é inserir um elemento que irá herdar e poderá opcionalmente também sobrescrever as propriedades disponíveis na tag . Todos os elementos que forem citados na tag ApplicationOverride irão ser sobrescritos, já os que não forem incluídos continuaram com os valores configurados na Tag ou valores padrão.

ApplicationOverride Passo 1: Criar e nomear a aplicação via :

checkAddress=”false” handlerURL=”/app2/Shibboleth.sso”/> A propriedade handlerURL deve ser informada com o novo caminho para as urls do SP recém criado quando se usa paths, ao usar virtual hosts não é necessário pois o Handle / Shibboleth.sso/Metadata irá gerar automaticamente quando acessado o endereço de cada virtual host. O exemplo acima demonstra um SP lógico sendo definido utilizando um diretório. A aplicação app2 é o nome do diretório que responderá como o SP. O exemplo utiliza diretório é necessário sobrescrever a propriedade handlerURL com o novo caminho: /app2/Shibboleth.sso. Passo 2: Associar os recursos que compõem a nova aplicação para uma configuração : Mapeamento feito através da propriedade applicationId que coincide com o ID que você


escolheu no passo anterior. Este mapeamento pode ser realizado via: 73

11 Apache Commands (httpd.conf ou equivalente); 11 RequestMapper (Portável – funciona IS). Outra configuração necessária é informar qual aplicação irá utilizar a nova configuração definida no ApplicationOverride. Existem duas formas de fazer este mapeamento: Através da tag RequestMapper e através de configurações 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 aplicação corrente irá utilizar o ApplicationOVerride cujo ID coincidir com o informado na tag applicationId. Os comandos nativos do apache não são portáveis, por exemplo no IS não funciona, já a configuração via RequestMapper funciona em qualquer servidor WEB. Exemplo de utilização de virtual hosts com mapeamento no Apache.

... ServerName sp.curso.rnp:443 ... ShibRequestSetting applicationId myApp ... Neste exemplo utilizando a configuração do Apache, a aplicação configurada no virtual host sp.curso.rnp irá utilizar as configurações sobrescritas na tag ApplicationOverride de id=myApp.


RequestMapper

74

Passo 1: Usando paths e mapeamento via RequestMapper no Shibboleth2.xml (Solução portável IS):

Este exemplo já configura uma aplicação que está dentro de um diretório do servidor, no caso o diretório app2 a usar o ApplicationOverride de id=myApp.

Passo 2: Usando Virtual Hosts a tag path deve ser omitida:

Esta configuração é a mesma, porém estamos assumindo que a aplicação não vai utilizar diretórios e sim vai estar na raiz do virtual host sp.curso.rnp. Passo 3: Proteger os 2 diretórios no apache ou via requestMapper no arquivo shibboleth2.xml:

[email protected] [email protected] O SP já está configurado, o próximo passo é proteger a aplicação para que no momento que for requisitado acesso inicie o processo de autenticação Shibboleth redirecionando o

No exemplo acima foram adicionadas as tags authType e requireSession para fazer a proteção da aplicação. A mesma proteção poderia ser feita também diretamente no apache como segue:

applicationId

myApp

authType shibRequireSession On

shibboleth


usuário 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 (necessário criar, quando utiliza paths não é 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 diretório terá a estrutura semelhante a exibida a seguir.

.... sp.curso.rnp CN=sp.curso.rnp,C=BR,OU=CPD CONTEÚDO DO CERTIFICADO
Location=”https://sp.curso.rnp/homologa/Shibboleth.sso/SLO/SOAP”/> 76

Sobrescrevendo configurações do 11 Para customizar o arquivo de Metadata usado para a nova aplicação:

q

Para customizar o arquivo de mapeamento de atributos: O exemplo acima demonstra como sobrescrever algumas propriedades da tag
q

Outra possibilidade é sobrescrever também 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é Quintão Moreira é Bacharel e Mestre em Ciência da Computação pela Universidade Federal de Minas Gerais. Entre 2000 e 2003 participou da implantação do diretório corporativo da UFMG. Possui grande experiência em autenticação federativa com protocolo SAML, tendo atuado como assistente 1 no Grupo de Trabalho Middleware da RNP de 2003 a 2005. Possui grande experiência com a plataforma JEE, tendo se certificado em programação Java em 2001. Em 2009 participou do projeto que deu origem à Federação CAFe. Participou da elaboração e desenvolvimento do sistema EID. Atualmente é membro do Comitê Técnico da Federação CAFe. É também arquiteto de software no Departamento de Ciência da Computação da UFMG. Lídia Aparecida O. Alixandrina é Bacharel em Sistemas de Informação pela PUC Minas. Atualmente é Analista de Sistemas na UFMG trabalhando na implantação de diretórios federados no projeto CAFe. Trabalhou também no desenvolvimento da ferramenta EID (Export Import Directory). Experiência em autenticação federativa com Shibboleth, LDAP, Apache Tomcat, Banco de Dados e Java para Web.

LIVRO DE APOIO AO CURSO

O Curso desenvolve competências para a implantação de um provedor de serviços na instituição. São apresentados os conceitos sobre Federação, protocolo SAML e Shibboleth, com ênfase na autorização ao uso dos serviços pelos membros da federação. O curso aborda desde a instalação até a configuração de um provedor de serviços na plataforma Shibboleth, além de apresentar algumas opções para federalizar aplicações e integrá-las a uma Federação.

ISBN 978-85-63630-39-1

9 788563 630391

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

Recommend Documents