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

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.

Provedor de Identidade

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.

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

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.

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

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.

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

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.



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

... base64-encoded certificate elided ... …. 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

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

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

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

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

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

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

12

3f7b3dcf-1674-4ecd-92c8-1544f346baf8



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

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

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.

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

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

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

     

 

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.

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



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

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



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

[...]

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



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

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

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.





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.



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.



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

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

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

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-

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

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.

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

Figura 4.6 Tela principal aplicação GMT.

59

60

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

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

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

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.

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

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

Capítulo 5 - Aplicações Federadas

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

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

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

Capítulo 5 - Aplicações Federadas

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

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



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.

Capítulo 5 - Aplicações Federadas

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.

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

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

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

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ê

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