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

(1)

LIVRO DE APOIO AO CURSO

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.

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

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 corpora-tivo da UFMG. Possui grande experiên-cia 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 certifi-cado 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 Com-putaçã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.

ISBN 978-85-63630-39-1

Federação CAFe:

Provedores de

Serviços de

Aplicações

Federadas

Edré Quintão Moreira

Lídia Aparecida O. Alixandrina

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.

(2)

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.

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

(3)

Federação CAFe:

Provedores de

Serviços de

Aplicações

Federadas

Edré Quintão Moreira

(4)

(5)

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

(6)

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 encon-trado 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 info@esr.rnp.br. 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

info@esr.rnp.br

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.

(7)

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

(8)

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

(9)

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

(10)

(11)

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 edu-cacionais 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ípi-cos 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 pro-blema, 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 apren-dizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

(12)

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 infraestru-tura, 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 insta-lação do software.

(13)

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

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.

(14)

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: info@esr.rnp.br

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 corpora-tivo 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 fede-rados 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.

(15)

Ca pí tu lo 1 - I nt ro du ção à a ut en tic aç ão e a ut or iz aç ão fe de ra da s

obj

et

ivo

s

co

nc

ei

to

s

1

Introdução à autenticação e

autorização federadas

Aprender sobre demandas para a implantação de uma infraestrutura de autenticação 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.

Infraestrutura de autenticação e autorização federada; Elementos de uma federação; 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; Federação CAFe.

Infraestrutura de autenticação e autorização federada

q

Motivação:

1 Disseminação de tecnologias e ferramentas que estimulam o compartilhamento de recursos, informações e serviços interinstitucionais.

Desafio para as instituições:

1 Desenvolver ambientes seguros e escaláveis para permitir que a colaboração visio-nada aconteça de fato.

Exemplos de serviços internos:

1 Cadastro de projetos, matrícula de alunos, registro de notas, compartilhamento de documentos etc.

Exemplos de serviços externos:

1 Acesso a bibliotecas digitais, compartilhamento de recursos (ciclos de CPU, espaço de armazenamento), ensino a distância etc.

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

(16)

Fe de ra çã o C AF e : P ro ve do re s d e S er vi ço s e A pl ic aç õe s F ed er ad as

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 Pes-quisa), 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

q

Cada usuário: 1 Múltiplas senhas. 1 Múltiplas contas.

1 Dificuldade de lembrar usuário ou senha. 1 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 com tantas contas para diversos serviços. Isso se agrava nos casos dos serviços que são uti-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

q

Autenticação centralizada.

1 Autenticação fica como recurso administrado por um único local. 1 Serviços tomam conhecimento das senhas.

Autenticação distribuída:

1 Autenticação distribuída entre vários domínios, formando um círculo de confiança. 1 Serviço não toma conhecimento do usuário e senha.

2 Vantagens da autenticação distribuída:

3 Credencial única compartilhada entre as instituições. 3 Credencial única para vários serviços.

3 Diminui a carga na administração de contas externas. 3 Menos senhas a serem recordadas pelos usuários.

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

(17)

Ca pí tu lo 1 - I nt ro du ção à a ut en tic aç ão e a ut or iz aç ão fe de ra da s Serviços Serviços Serviços Serviços Operador de Identidade

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.

Serviço 1 Serviço 2 Provedor de Identidade Provedor de Identidade Provedor de Identidade 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 pre-ocupe 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.

Figura 1.1 Autenticação centralizada. Figura 1.2 Autenticação distribuída.

(18)

Autenticação multi-institucional

q

1 Instituições possuem diretórios independentes para satisfazer necessidades internas. 1 Aplicações internas podem usar esses diretórios para autenticação.

2 Evita a criação de mais um cadastro de usuários.

1 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

q

O que é uma Federação?

1 Tipo de rede de confiança que permite facilitar contratos bilaterais entre usuários e provedores de serviços.

1 Implementa o princípio de identidade federada:

2 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 ser-viç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 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

man-tidas 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.

(19)

Ca pí tu lo 1 - I nt ro du ção à a ut en tic aç ão e a ut or iz aç ão fe de ra da s Universidade A Biblioteca Universidade B Correio eletrônico

Credenciais Autorização Recurso/Serviço Administração e autenticação do usuário I/S I/S I/S I/S I/S I/S I/S I/S I/S Cluster de servidores Biblioteca Digital I/S Administração EaD

Sist. Arq. Dist.

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.

Figura 1.3

Modelo usual de autenticação.

(20)

Fe de ra çã o C AF e : P ro ve do re s d e S er vi ço s e A pl ic aç õe s F ed er ad as Universidade A Biblioteca Universidade B Correio eletrônico

Credenciais Autorização Recurso/Serviço Administração e autenticação do usuário I/S I/S I/S Cluster de servidores Biblioteca Digital Administração EaD

Sist. Arq. Dist.

Elementos de uma federação

q

Uma federação inclui dois elementos: 1 Provedor de Identidade (IdP). 1 Provedor de Serviço (SP). Atores em uma federação:

1 Usuário: deseja usar um recurso protegido.

1 Provedor do recurso: aplicação com um SP instalado.

1 Instituição do usuário: possui um IdP e um processo interno de autenticação. Uma federação é constituída por dois componentes principais:

1 Provedores de identidade: armazenam e gerenciam as informações sobre pessoas; 1 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.

(21)

Ca pí tu lo 1 - I nt ro du ção à a ut en tic aç ão e a ut or iz aç ão fe de ra da s SP IdP IdP IdP IdP SP SP SP SP SP 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:

1 Serviços internos da instituição, como matrícula de alunos, e-mail, registro de notas, cadastro de projetos, entre outros exemplos;

1 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

q

Where Are You From (WAYF)/Discovery Service (DS).

1 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 identi-dade. 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.

(22)

Metadados da federação

q

Metadados:

1 Disponibilizado pela federação.

1 Informações relevantes sobre os IdPs e SPs. 2 Confiança: 3 Certificados. 3 Chaves públicas. 2 Comunicação: 3 IDs. 3 URLs. 3 Protocolos.

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

<md:EntityDescriptor entityID=”https://service.example.org/ shibboleth” validUntil=”2010-01-01T00:00:00Z”> <md:SPSSODescriptor protocolSupportEnumeration=”urn:oasis:names:t c:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0 :protocol”> <md:KeyDescriptor> <ds:KeyInfo xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”> <ds:X509Data> <ds:X509Certificate>

... base64-encoded certificate elided ... </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:SingleLogoutService Location=”https://service.example.org/ Shibboleth.sso/SLO/SOAP” Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP”/> <md:SingleLogoutService Location=”https://service.example.org/ Shibboleth.sso/SLO/Redirect” Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect”/> <md:SingleLogoutService Location=”https://service.example.org/ Shibboleth.sso/SLO/POST” A federação geral-mente 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.

l

(23)

Ca pí tu lo 1 - I nt ro du ção à a ut en tic aç ão e a ut or iz aç ão fe de ra da s Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST”/> <md:SingleLogoutService Location=”https://service.example.org/ Shibboleth.sso/SLO/Artifact” Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact”/> …. </md:SPSSODescriptor> <md:Organization>

<md:OrganizationName xml:lang=”en”>Example Organization, Ltd.</ md:OrganizationName>

<md:OrganizationDisplayName xml:lang=”en”>Example Organization</ md:OrganizationDisplayName> <md:OrganizationURL xml:lang=”en”>https://service.example.org/</ md:OrganizationURL> </md:Organization> </md:EntityDescriptor> SP SP IdP SP IdP SP SP SP SP IdP SP SP IdP Ficheiro de Metadados da Federação Identity Provider Service Provider Federação Organização Info. IdP Info. SP Info. SP Info. IdP Info. SP Info. SP Info. IdP Info. SP Info. SP Info. IdP Info. SP Info. SP Info. SP Info. SP Info. IdP Info. SP Info. SP Info. SP SP SP SP IdP SP SP IdP Figura 1.6 Ficheiro de Metadados da Federação.

(24)

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 compartilha-mento, mas não, necessariamente, força o relacionamento bilateral entre todas as partes.

Provedores de Identidade

q

Implementam a política interna de gestão de identidade de uma instituição. 1 Atributos dos usuários:

2 Nome, data do vínculo, cargo ocupado, matrícula etc. 1 Método de autenticação:

2 Login/senha, certificados etc.

1 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 esta-belece seu método de autenticação interno e deve garantir que cada pessoa da instituição tenha um identificador único.

Provedores de serviço

q

Implementam serviços que devem ser disponibilizados para pessoas vinculadas às insti-tuições. Requerem:

1 Autenticação:

2 Identificação dos usuários do serviço. 1 Autorização:

2 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, aluno matriculado em determinado curso, professor coordenador de curso etc.). Na imple-mentaçã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.

(25)

Interação entre os elementos de uma federação

Requisição/Resposta HTTP Redirecionamento HTTP Conexão servidor/servidor 7 5 2 3 4 6 1 Credenciais Handle Handle Atributos Instituição do usuário Recurso WAYF/DS

A interação entre os elementos (atores) de uma federação é mostrada na figura 1.7: 1 Passo 1: usuário acessa provedor de serviço (SP);

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

1 Passo 3: o usuário seleciona o Provedor de Identidade da sua instituição de origem; 1 Passo 4: o usuário é redirecionado para o seu provedor de identidade (IdP); 1 Passo 5: o IdP autentica o usuário com o método escolhido pela instituição; 1 Passo 6: o SP recebe garantia de autenticação do usuário pelo IdP;

1 Passo 7: se necessário, o SP requisita atributos adicionais desse usuário ao IdP; para garantir a privacidade do usuário, apenas são disponibilizados atributos previamente acordados entre o IdP e o SP;

1 Passo 8: o provedor de serviço decide sobre as autorizações e disponibiliza o serviço para o usuário.

SAML 2.0

q

Definição:

1 Security Assertion Markup Language – SAML.

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

1 V1.0 se tornou um padrão OASIS em novembro de 2002. 1 V1.1 surgiu em setembro de 2003.

1 V2.0 foi anunciado em março de 2005. Figura 1.7

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

(26)

Security Assertion Markup Language – SAML 2.0, permite cenários de autenticação e autori-zaçã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

1 É um pacote de informações que fornece uma ou mais declarações feitas por uma autori-dade SAML.

1 A Assertion (“b07b804c-7c29-EA16-7300-4f3d6f7928ac”) foi emitida no tempo “2004-12-05T09: 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). 1 Exemplo: <saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” ID=”b07b804c-7c29-EA16-7300-4f3d6f7928ac” Version=”2.0” IssueInstant=”2004-12-05T09:22:05”> <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer> <ds:Signature xmlns:ds=”https://www.w3.org/2000/09/xmldsig#”>...</ds:Signature> <saml:Subject> <saml:NameID Format=”urn:oasis:names:tc:SAML:2.0:nameid-format:transient”> 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method=”:oasis:names:tc:SAML:2.0:cm:bearer”> <saml:SubjectConfirmation InResponseTo=”aaf23196-1773-2113-47a-fe114412ab72” Recipient=”https://sp.example.com/SAML2/SSO/POST” NotOnOrAfter=”2004-12-05T09:2705”/>

(27)

Ca pí tu lo 1 - I nt ro du ção à a ut en tic aç ão e a ut or iz aç ão fe de ra da s </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore=”2004-12-05T09:17:05” NotOnAfter=”2004-12-05T09:27:05”> <saml:Audiencerestriction>

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 autenti-cação explícita ao provedor de identidade. Um elemento <samlp:AuthnRequest> é transmi-tido 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 men-sagem SAML é chamado de um artefato, onde o receptor de um artefato resolve a referência através do envio de um pedido <samlp:ArtifactResolve> diretamente para o emissor do artefato, que, em seguida, responde com a mensagem real referenciada pelo artefato.

Bindings

Definem como as mensagens do protocolo SAML 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 identidade usa “HTTP POST” para transmitir a resposta. As mensagens do protocolo SAML são frequentemente enviadas diretamente na URL de uma solicitação HTTP GET.

O “HTTP Redirect” é adequado para mensagens curtas, como <samlp:AuthnRequest>, já que o tamanho de uma URL é limitado. As mensagens mais longas (exemplo: aqueles que 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”:

<input type=”hidden” name=”SAMLRequest” value=”request” /> ... other input parameter....

(28)

Profiles

Como combinar os bindings, protocols e assertions SAML para casos de uso específicos.

Motivação/Vantagens

q

1 Neutralidade da plataforma. 1 Fraco acoplamento de diretórios.

1 Melhor experiência on-line para usuários finais. 1 Redução de custos administrativos para o SP. 1 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 iden-tidade 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 autenti-caçã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.

q

Implementações de SAML 2: 1 Shibboleth 2.0.

1 Google Apps APIs.

1 Oracle Identity Management. 1 Simple SAML php.

1 Python – SAML2. 1 ...

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.

(29)

User Agent Identity Provider

Service Provider Service Provider

Request target resource

Request target resource Respond with requested resource

Redirection to target resource Discover the IdP Redirect to SSO Service

Request SSO Service Request Artifact Resolution Service

Request with SAML Authn Request

(Identify the user)

Redirection to Assertion Consumer Service Request Assertion Consumer Service

Request Artifact Resolution Service Request with SAML Authn Request

1 2 3 4 5 6 7 8 9 10 11 12

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 Service Provider Login Ser reconhecido

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 soli-citar os atributos e decidir pela liberação de acesso ou não. Para o usuário, isso é transpa-rente, já que não precisa informar novamente seus dados para autenticação.

Figura 1.8 Diagrama Web Browser SSO Profile. Figura 1.9 Single Sign-On.

(30)

Single Logout

q

1 Logout de todas as aplicações iniciadas pelo usuário. 1 Problemas:

2 Ao acionar o “logout”, nem todas as aplicações são encerradas. 2 Problema com experiência do usuário.

2 Falta de segurança. 2 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

q

Handles disponíveis no Shibboleth SP:

1 São configurados no arquivo shibboleth2.xml. 1 Podem ser acessados via navegador. 1 Auxiliam em testes e debugs do SP. Handles disponíveis no Shibboleth SP. 1 Metadata Generation Handler:

2 Gera metadados de amostra com base na configuração do SP. 2 Type=“MetadataGenerator”.

2 URL para acesso: https://SERVIDOR/Shibboleth.sso/Metadata.

2 Entre os atributos disponíveis para configuração, vamos destacar o https (boolean). 2 Força ou desativa a geração de parâmetros de protocolo usando o esquema https,

independentemente de qual esquema é usado ao acessar o manipulador. 1 Handles disponíveis no Shibboleth SP:

2 Status Handler.

2 Gera um xml sobre o estado operacional do SP e algumas informações de configuração.

2 Type=“Status”.

2 URL para acesso: https://SERVIDOR/Shibboleth.sso/Status.

2 Informações retornadas podem ser consideradas confidenciais por alguns implan-tadores (versão do SP e S.O.).

2 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 <Handler> é 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.

(31)

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 é reco-mendado 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:

q

Handles disponíveis no Shibboleth SP: 1 Session Handler.

1 Exibe informações da sessão de um usuário específico para auxiliar no debug. 1 Type=“Session”.

1 URL para acesso: https://SERVIDOR/Shibboleth.sso/Session.

1 Um atributo importante é showAttributeValues (boolean). O padrão é false, que indica se os valores dos atributos serão exibidos.

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

Outro atributo disponível é o contentType no formato string, que seleciona o tipo de con-teú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 resul-tado seja uma estrutura JSON.

q

1 Discovery Feed Handler (A partir da versão 2.4).

2 Exibe informações dos IdPs disponíveis nos Metadados em uma estrutura JSON. 2 Type=“DiscoveryFeed”.

2 URL para acesso: https://SERVIDOR/Shibboleth.sso/DiscoFeed. 2 Discovery Service Embarcado utiliza-se desse Handler.

(32)

q

1 Attribute Checker Handler (A partir da versão 2.5).

2 Valida a sessão de um usuário com uma lista de atributos obrigatórios (e, opcional-mente, seus valores), pode retornar o usuário para completar o processo de login ou exibir uma página de erros personalizada.

2 type=”AttributeChecker”.

2 URL acesso: https://SERVIDOR/Shibboleth.sso/AttributeChecker.

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

<Handler type=”AttributeChecker” Location=”/AttrChecker” template=”attrChecker.html”

attributes=”eppn displayName” flushSession=”true”/>

Pela incorporação de uma política de controle de acesso válido dentro do elemento: <Handler type=”AttributeChecker” Location=”/AttrChecker” template=”attrChecker.html” flushSession=”true”> <AND> <Rule require=”eppn”/> <Rule require=”displayName”/> </AND> </Handler>

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 <OR> pode ser utilizada.

Atributos:

1 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 <shibmlp attrID />;

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

1 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 <RelyingParty> 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.

(33)

q

1 External Authentication Handler (a partir da versão 2.5).

2 Implementa uma interface REST loopback para a criação de sessões de usuário com base na lógica de autenticação externa.

2 Type=“ExternalAuth”.

2 URL acesso: https://SERVIDOR/Shibboleth.sso/ExternalAuth;

2 Por motivo de segurança, não deve ser exposto a qualquer interface de rede. 2 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

q

InCommon:

1 Federação nos EUA, 107 instituições, 2 milhões de usuários. Feide:

1 Federação na Noruega. Switch:

1 Federação na Suíça. SDSS:

1 Federação no Reino Unido.

Federações acadêmicas já são implementadas e mantidas em outros países. Alguns exem-plos: 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

q

Iniciativa da RNP para criar uma Federação Acadêmica no Brasil.

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

1 Integrar padrões e soluções de software utilizados por outras federações. 1 Desenvolver ferramentas auxiliares e definir políticas para a federação.

(34)

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 pes-quisa brasileiras. A metodologia adotada para a construção da infraestrutura básica da fede-raçã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). Diretório LDAP Metadado RNP

?

Recomendação para obtenção de atributos (e certiﬁcados para autenticação) Provedor de serviço (membro ou parceiro externo)

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 uma aplicação própria para localização da instituição de origem dos usuários. Os prove-dores 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 reco-mendaçã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.

q

1 Provedores de Serviços da CAFe: 2 Microsoft Dreamspark. 2 Atlases.

2 Gisela Science Gateway.

Figura 1.10

Estrutura Federação CAFe.

(35)

q

1 Portal de Periódicos da CAPES. 1 Portal de vídeo digital. 1 JEMS.

1 PADBR. 1 Readex. 1 GENI.

1 Portal RedCLARA.

1 eduGain (Vários provedores de serviços Internacionais).

Estatísticas Provedores de Serviços da CAFe

20

15

10

5

0

jul13 ago13 set13 out13 nov13 dez13 jan14 fev14 mar14 abr14 mai14 jun14

[un.]

13 13 14 14 14

18 18 18 18 19 19 19

q

Provedores de Identidade da CAFe:

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

70 60 50 40 30 75 65 55 45 35

jul13 ago13 set13 out13 nov13 dez13 jan14 fev14 mar14 abr14 mai14 jun14

[un.] ₄₅ 45 48 49 57 57 60 65 65 65 71 72

q

Como aderir à Federação CAFe: 1 Como Provedor de Identidade:

http://portal.rnp.br/web/servicos/adesao-a-cafe-como-provedor-de-identidade 1 Como Provedor de Serviços:

http://portal.rnp.br/web/servicos/adesao-a-cafe-como-provedor-de-servico Figura 1.11 Estatística Provedores de Serviço. Figura 1.12 Estatística Provedores de Identidade.

(36)

(37)

Ca pí tu lo 2 - I ns ta la çã o d o S hi bb ol et h S P e d o D is co ve ry S er vi ce

obj

et

ivo

s

co

nc

ei

to

s

2 Instalação do Shibboleth SP

e do Discovery Service

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

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

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

Shibboleth SP

q

Shibboleth Service Provider: 1 Implementa o protocolo SAML 2.

1 Independente de linguagem de implementação. 1 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 nativa-mente 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

q

1 Código aberto sob Licença Apache 2.

1 Pode ser compilado para diversas plataformas. 1 Binários disponíveis para algumas plataformas.

2 Instalador para Windows. 2 Instalador RPM.

(38)

q

1 Shibboleth Service Provider. 2 mod_shib.

3 Módulo do Apache. 2 shibd.

3 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: 1 Linux; 1 Mac OS X; 1 Solaris; 1 Windows; 1 Java Servlets. Recurso mod_shib shibd BD Shibboleth SP Apache Handle Atributos Handle

O shibboleth SP pode ser visto basicamente como dois componentes:

1 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; 1 shibd: é um deamon responsável por resolver artefatos como, por exemplo, requisitar

atributos do usuário autenticado.

Pré-requisitos para a instalação

q

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.

Informações publicadas na wiki.shibboleth.net em janeiro de 2014.

l

Figura 2.1 Arquitetura Shibboleth SP.

(39)

Ca pí tu lo 2 - I ns ta la çã o d o S hi bb ol et h S P e d o D is co ve ry S er vi ce

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

q

Visão Geral:

1 DS (Discovery Service) Versão 2.x. 1 WAYF (Where Are You From) Versão 1.x.

2 Protocolo diferente.

1 Permite a escolha do provedor de identidades para autenticação. 1 Normalmente passa por intermediário para listagem das possibilidades. 1 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 auxi-liar 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.

O protocolo do DS diferencia-se do protocolo do WAYF principalmente porque quem solicita autenticação ao IdP é o provedor de serviços (SP), e não o intermediário. Como esse proto-colo é implementado pelo SP Shibboleth, é viável construir URL que solicita autenticação diretamente a um IdP.

Implementações do Discovery Service

q

Discovery Service Embarcado:

1 Dentro do portal do próprio serviço é exibida a lista de instituições para escolha do usuário.

1 Usuário não é redirecionado para outra página. 1 Melhora a “experiência” do usuário.

1 Discovery Service Centralizado:

1 Usuário é redirecionado para fora da aplicação para escolha do IdP quando login é necessário.