Pentaho é um software de código aberto para inteligência empresarial, desenvolvido em Java. A solução cobre as tarefas de ETL (Extraction, Transformation and Load), reporting, OLAP e mineração de dados (data-mining). Desenvolvido desde 2004 pela Pentaho Corporation o software foi considerado uma das melhores aplicações para inteligência empresarial em 2008 pela InfoWorld.

Realiza análises de big data, trabalha nativamente com bancos de dados NoSQL e Hadoop, além de poder processar dados de forma distribuída nativamente em cluster, pode rodar sobre o Hadoop em cluster alcançando velocidades extremamente rápidas.

Jobs - pasta /Home/eid/cafe

full-job-atualizacao-diaria

Limpa a base EID ( tabelas do EID e tabelas de Stage)

Importa todos os registros da base de origem validando os CPFs e emails inválidos, carrega vínculos, emails e contas.

Exporta todos estes dados para o LDAP, comparando o que já existe para remover usuários que tenham sido desativados.

Caso apenas um vinculo do usuário seja desativado e a pessoa continue ativa, este vinculo não é apagado do LDAP, apenas do EID.

Usuários encontrados com CPFs duplicados são unificados sempre preservando o registro mais recente e/ou a base mais confiável (base com baseOrigem=1) e evidenciando a unificação no relatório de "Pessoas Duplicadas".

Contas duplicadas são unificadas escolhendo de acordo com o parâmetro configurado e/ou de acordo com o critério da base mais confiável. A unificação é evidenciada no relatório de "Contas duplicadas".

full-job-atualizacao-diaria-truncate

Faz exatamente as mesmas cargas que o full-jobs-atualizacao=diaria, porém antes de inserir os dados no LDAP, ele faz um truncate em toda a base LDAP para só então inserir os dados na base.

Lembrando que por apagar todos os usuários da base LDAP, este job deixa o serviço indisponível enquanto faz a nova carga dos usuários na base.

Por isso recomenda-se que este Job seja executado em horários que o uso dos serviços seja mínimo, por exemplo durante a madrugada.

atualizacao-contas-intradia

Um job mais leve e rápido para ser executado com pouco intervalo de tempo, por exemplo de hora em hora.

Este Job faz a carga apenas de Identificação e Conta. Para garantir que novos alunos, ou pessoas que trocaram a senha tenham esta mudança refletida no diretório LDAP rapidamente.

eid-truncate-logs

Limpa todas as tabelas de logs existentes na base EID.

Este Job pode ser executado para liberar armazenamento e melhorar o desempenho do Servidor Pentaho.

eid-truncate-tables

Limpa todas as tabelas da Base EID exceto os logs.

Pode ser executado quando se deseja zerar toda as exportações realizadas.

estatisticas-cubos

Limpa todas as tabelas de estatísticas do EID.

Como é gerado o atributo eppn (eduPersonPrincipalName) no PDI?

O atributo eppn é gerado a partir do atributo "uid" do usuário.

É gerado um hash do atributo uid e concatenado com o domínio da instituição. O formato sempre é escopado. Ex: xxx@rnp.br

Como fazer backup do servidor PDI?

O backup pode ser feito de toda a VM fazendo snapshots regulares e também é possível fazer o backup apenas de todas as transformações/ jobs e relatórios do servidor.

Como visualizar os logs de erros dos relatórios do Pentaho?

Acessar a interface de cliente do PDI Http://IP_SERVIDOR:8080

Logar com usuario e senha mesmos utilizados no login no cliente.

Acessar Browse Files/ Eid/Cafe/Visualização/Dashboards.

O PDI apaga usuários desativados da base LDAP?

O PDI sempre irá apagar da base LDAP usuários que não estão mais nas Views criadas.

Desta forma se o usuário desativado for removido da View ele será removido da base LDAP na próxima execução do PDI.

Os vínculos dos usuários são removidos?

Os vínculos depois de inseridos na base LDAP não são removidos.

O que pode ser feito é informar a data de fim do vinculo no atributo "brExitDate" ou remover todo o usuário caso ele não tenha mais nenhum vinculo ativo.

Como é feita a conciliação com duas bases de dados?

Os usuários são todos exportados para o metadiretório e depois os dados são cruzados analisando quem possui mesmo CPF estes são unificados e exibidos no relatório.

Apenas um registro com os dados daquele cpf é enviado para a base LDAP. Quando existem mais de uma base de dados a prioridade é enviar para o LDAP o registro que vem da base 1. Que deve ser a base com maior credibilidade.

Como é feita a conciliação com apenas uma base de dados?

Da mesma forma que com uma base, mas a prioridade para envio ao LDAP será do registro mais recente, considerado mais atualizado e por isso é o registro enviado para o LDAP.

Quais os critérios para unificação de pessoas encontradas com o mesmo cpf?

As pessoas serão agrupadas e o registro mais recente será o enviado para a base LDAP. Os demais registros serão descartados e exibidos no relatório de pessoas duplicadas.

Quais os critérios para unificação de contas de uma mesma pessoa?

Apenas uma conta pode ser enviada para a base LDAP. Quando um usuário possui mais de uma conta o sistema irá escolher entre uma delas para ser enviada a base LDAP, e as demais serão descartadas e exibidas no relatório de pessoas com contas duplicadas. É possível definir via parâmetro do sistema qual conta é enviarda para a base LDAP, a conta mais recente ou a conta mais antiga. Está análise é feita a partir do ID da conta.

Como registros com cpf inválidos são processados?

Os registros de pessoas que possuem CPFs inválidos são separados em uma lista de erros para serem exibidos para os usuários e não são exportados para a base LDAP até que o CPF esteja correto.

Como registros com emails inválidos são processados?

Os registros de email que são inválidos são separados em uma lista de erros para serem exibidos para os usuários e não são exportados para a base LDAP até que o email esteja correto.

Como limpar a base EID?

Existe um Job específico que limpa todas as tabelas da base EID.

Como escolher se vai ou não utilizar a conversão da senha para base64?

Através da configuração de parâmetros do job principal: full-job-atualizacao-diaria.

Parâmetro converter para base64.

Como configurar o envio de email em caso de erros no processamento?

Na configuração de parâmetros do job principal: full-job-atualizacao-diaria.

Como acessar os relatórios do PDI?

Acessar Browse Files/ Eid/Cafe/Visualização/Dashboards.

Como executar o PDI remotamente no servidor?

No momento de executar o job no PDI Cliente selecionar Executar no servidor na caixinha de execução.

Como limpar os logs do PDI?

Existe um Job específico que limpa todas as tabelas de log da base EID.

Como alterar a senha do user do PDI no navegador?

Na interface WEB do servidor Pentaho acessar o menu Administração/Users.

O que fazer quando o job é finalizado com erros ou abortado?

• Verificar nos logs as linhas vermelhas: Elas mostram a causa do erro;

• Verificar as conexões se estão todas corretas;

• Verificar as Views se contém os dados e se os previews funcionam em todas.

Objetivo

Importação do template de uma máquina virtual pré-configurada para ser o servidor do Pentaho Data Integration (PDI) 9.0.

Este será o aplicativo responsável pela importação dos dados das bases acadêmicas da instituição e exportação para a base LDAP que será utilizada na autenticação dos serviços da Federação CAFe.

Pré-requisitos

• Possuir um hypervisor que irá hospedar o host;

• Um endereço IP válido na internet;

Os requisitos mínimos de hardware informados pelo fornecedor da Suite Pentaho 8.0 são os seguintes:

• Processador: Intel EM64T ou AMD64 Dual-core

• Memória RAM: 10 GB, com 6 GB dedicados ao Pentaho Server 8.0

• Espaço em disco: 20 GB livres após a instalação.

Todavia, recomendamos como configuração ideal:

• Processador: para viabilizar o processamento paralelo, recomendamos utilizar processadores com pelo menos 4 núcleos.

• Memória RAM: 20 GB, com 10 GB dedicados ao Pentaho Server 9.0

• Espaço em disco: 50 GB livres após a instalação.

Especificação do template

• Sistema Operacional Ubuntu 18.04 LTS com instalação otimizada para ambientes de virtualização;

• Arquitetura de 64 bits;

Obs: Apesar da VM possuir essa configuração, a instituição pode adequar de acordo com a disponibilidade de recurso, respeitando os pré-requisitos.

Procedimento de importação

2. Importe o arquivo transferido para seu Hypervisor.

3. Ligue o servidor virtual recém importado, segue as informações de Login na VM:

4. Realizar as configurações de rede da VM.

5. Start no servidor Pentaho:

O serviço do Pentaho é inicializado automaticamente pelo sistema operacional. Todavia, pode-se utilizar os comandos abaixo para intervenções manuais, inicializando e parando, respectivamente:

ATENÇAO:

Certifique-se que na pasta /opt/pentaho-server/tomcat/lib/ não exista mais de uma versão do driver Mysql.

Se existir outro driver mysql em outra versão, como por exemplo, o mysql-connector-java-5.1.17-bin.jar ele deve ser apagado.

A versão correta do driver mysql que deve ficar na pasta é mysql-connector-java-5.1.45-bin.jar.

7. Verificar se o serviço do Mysql está rodando na VM:

9. Verificar se o login ocorreu com sucesso.

O EID PDI realiza a integração do cadastro de usuários das instituições que fazem parte da CAFe por meio da leitura de suas bases de dados e posterior sincronização com o servidor LDAP da comunidade.

A configuração padrão desse serviço realizar a integração das seguintes entidades:

• Identificação

• Conta

• Email

• Aluno

• Professor

• Técnico

Para cada entidade listada acima, a instituição precisa disponibilizar uma VIEW no seu banco de dados com as seguintes características:

OBS. : Caso a sua instituição não deseje importar para a base LDAP os dados de alguma das Views como por exemplo Professor, a estrutura da View deve ser criada mesmo assim e deverá ficará vazia sem nenhum dado.

01. IDENTIFICAÇÂO

Nome da view: Pessoas

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão"

02. CONTA

Nome da view: Conta

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

03. EMAIL

Nome da view: Email

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

04. ALUNO

Nome da view: Aluno

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

05. PROFESSOR

Nome da view: Professor

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

06. TÉCNICO

Nome da view: Tecnico

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

1. Introdução

Esse roteiro apresenta o conjunto de ações necessárias para a configuração de um servidor Linux Ubuntu, 18.04 LTS, com os aplicativos necessários para o funcionamento do EID-PDI.

2. Requisitos

Os requisitos mínimos de hardware informados pelo fornecedor da Suite Pentaho 9.0 são os seguintes:

• Processador: Intel EM64T ou AMD64 Dual-core

• Memória RAM: 10 GB, com 8 GB dedicados ao Pentaho Server 8.0

• Espaço em disco: 20 GB livres após a instalação.

Todavia, recomendamos como configuração ideal:

• Processador: Para viabilizar processamento paralelo, recomendamos utilizar processadores com pelo menos 4 núcleos.

• Memória RAM: 20 GB, com 10 GB dedicados ao Pentaho Server 9.0

• Espaço em disco: 50 GB livres após a instalação.

3. Roteiro de instalação

3.1. Atualização do sistema operacional.

3.2. Instalação da máquina virtual Java - JDK (1.8).

3.3. Instalação do unzip.

3.4 Instalação do Pentaho 9.0

3.5 Copiar o driver JDBC do MySQL para os diretórios do Pentaho (* incluir os driver dos SGBDS: SQL Server, Oracle, Postgres)

ATENÇAO:

Certifique-se que na pasta /opt/pentaho-server/tomcat/lib/ não exista mais de uma versão do driver Mysql.

Se existir outro driver mysql em outra versão, como por exemplo, o mysql-connector-java-5.1.17-bin.jar ele deve ser apagado.

A versão correta do driver mysql que deve ficar na pasta é mysql-connector-java-5.1.45-bin.jar.

Ao atualizar o pentaho ou o driver é necessário testar se o driver novo é compatível com a versão. O Driver mysql-connector-java-5.1.17-bin.jar dá erro na execução dos jobs.

3.6. Instalação do plugin Saiku Analytics

3.7 Iniciar o serviço do Pentaho BI Server

3.8 Instalação do Pentaho Data Integration

3.9 Configuração do Servidor Pentaho BI Server

Acesse a o Pentaho BI Server, por meio de um browser, na URL http://localhost:8080, utilizando o usuário Admin e a senha password.

O primeiro passo será a criação do usuário e o perfil EID, conforme os passos abaixo:

Criar usuário EID:

a) Clicar no menu superior à esquerda: (Home v).

b) Selecionar opção Administration

c) Selecionar opção Manage Roles

d) Selecionar New role (+)

e) Digitar o nome EID e clicar em OK.

f) Marcar as permissões:

• Schedule Content

• Read Content

• Publish Content

• Create Content

• Execute

• Manage Data Sources

g) Selecionar a aba Manage Users:

h) Mantenha a tecla CTRL pressionada e selecione os usuários abaixo:

• pat

• suzy

• tiffany

i) Preencher os dados do usuário EID, com a respectiva senha (na VM padrão: eidpdi) , e clicar em OK.

j) Selecione o usuário EID:

k) Selecione a Role EID e clique na sinal > :

l) Alterar a senha do usuário ADMIN, selecionando o usuário e clicando em EDIT Password.

m) Digite a nova senha no campo New Password. Repita a senha no campo Confirm Password. Digite a senha atual (cujo padrão é: password) no campo Administrator Password e clique em OK.

3.10 Acessar o PDI - Pentaho Data Integration

3.11 - Verificar se a conexão das bases com os dataSources no PDI estão configuradas corretamente tendo acesso a base Local Mysql, na interface Web do PDI.

3.12 Configurar o acesso ao repositório

a) Clique no menu superior à direita (Connect v) e selecione Repository Manager

b) Selecione ADD > Get Started e preencha:

• Display Name: EID - Repositório CAFe

• Selecione FINISH.

c) Clique no menu superior à direita (Connect v) e selecione EID - Repositório CAFe e digite o usuário EID e a respectiva senha. Clique em connect.

3.13 Importar transformações/Jobs/Relatórios EID-PDI para o Servidor Pentaho:

a) Acesse a VM Pentaho Server e via linha de comando baixe o arquivo abaixo e salve na pasta /opt/eid:

b) Execute o seguinte comando para importar as transformações e Jobs para o servidor Pentaho:

Acesse o cliente PDI e verifique se todos os Jobs, transformações e relatórios foram importados com sucesso.

É possível também fazer a importação das transformações via interface gráfica no Cliente PDI:

1) Clique na barra de menu TOOLS > Repositório > Import Repository

• Selecione o arquivo que contém as ETLS e Jobs e clique em OK.

• Na janela de confirmação para criação de regras, clique em Não.

• selecione a pasta / e clique em ok.

Fazer backup das transformações/Jobs/Relatorios do PDI:

a) Acesse a VM Pentaho Server e via linha de comando execute:

O arquivo de backup será gerado em: /opt/eid/backup_eid_full.zip

O PDI (Pentaho Data Integration) pode rastrear versões e comentários de trabalhos, transformações e informações de conexão quando você os salvar.

Você pode ativar ou desativar o controle de versão e o rastreamento de comentários modificando suas instruções relacionadas no arquivo de texto repository.spring.properties.

Por padrão, o controle de versão e o rastreamento de comentários estão desativados (definido como falso).

Para ativar o de controle de versão do PDI:

1- Saia e feche do cliente PDI (também chamado de Spoon).

2- Pare o servidor Pentaho:

3- Abra o arquivo pentaho-server/pentaho-solution/system / repository.spring.properties. Para habilitar o controle de versão

edite a instrução versioningEnabled e defina-a como true.

versioningEnabled = true

Caso deseje também habilitar a opção de inserir comentários a cada arquivo modificado altere também a propriedade versionCommentsEnabled = true

versionCommentsEnabled = true

Se você deseja controle de versão, mas não rastreamento de comentários:

Edite a instrução versioningEnabled e defina-a como true.

Edite a instrução versionCommentsEnabled e defina-a como false.

versioningEnabled = true

versionCommentsEnabled = false

Salve e feche o arquivo.

Se você desativar o controle de versão, o rastreamento de comentários também será desativado.

4- Inicie o servidor Pentaho:

cd /opt/pentaho-server

./start-pentaho.sh

Verificando a opção de controle de versão ativada no PDI:

Inicie o PDI Client (também chamado de Spoon).

Verifique se o controle de versão está definido como pretendido.

Conecte-se ao Repositório Pentaho

No PDI Client, clique em Tools > Repository > Explore

Na janela Repository Explorer, clique na guia Browse e clique no nome de um arquivo:

Verifique se o controle de versão está ativado ou desativado:

Ativado - Você pode ver a guia Controle de acesso e a guia Histórico da versão está visível.

Desativado - Você pode ver a guia Controle de acesso, mas a guia Histórico de versões está oculta.

Verifique se o rastreamento de comentários está ativado ou desativado:

Ativado - a guia Histórico da versão é exibida com o campo Comentários. Quando você salva uma transformação, job ou informações de conexão, uma caixa para inserir um comentário é exibida.

Desativado - a guia Histórico da versão é exibida e o campo Comentário está oculto. Quando você salva informações de transformação, job ou conexão, não é mais necessário inserir um comentário. O controle de versão está ativo, mas sem exibir comentários.

Procedimentos

Durante a instalação do Shibboleth IdP é gerado um arquivo que contêm o bloco de metadados do provedor. Para que um provedor faça parte de uma Federação, uma das providências necessárias é a inclusão do bloco de metadados do provedor no arquivo de metadados da federação. Os metadados da federação servem para informar aos seus participantes quais são os servidores "reconhecidos" e confiáveis.

O arquivo que possui o bloco de metadados do seu Provedor de Identidade é o /opt/shibboleth-idp/metadata/idp-metadata.xml

Envie o arquivo de metadados para o endereço atendimento@rnp.br (caso já tenha um processo em andamento, basta mandar em reposta ao e-mail da equipe).

A equipe de operação CAFe então fará a verificação da integridade desse metadado, tudo estando certo esse metadado será inserido na federação Chimarrão para que seja iniciado a homologação do IDP.

Instalação Cliente PDI no Windows:

1. Instalar Java JDK versão 8

2. Baixar o PDI( https://svn.cafe.rnp.br//arquivos/pdi-ce-9.0.0.0-423.zip )

3. Descompactar no diretório de preferência.

4. Setar variável JAVA_HOME e PENTAHO_JAVA_HOME com caminhos do JAVA JDK

5. Copiar o driver do Mysql disponível em https://svn.cafe.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/pdi-pentaho/mysql-connector-java-5.1.45-bin.jar para a seguinte pasta no cliente: pentaho/biclient/data-integration/lib

6. Baixar o driver correspondente a base de dados utilizada pela sua instituição (SQL Server, Oracle, Postgresql, etc) e disponibilizar na seguinte pasta no cliente PDI: pentaho/biclient/data-integration/lib

7. Executar o arquivo spoon.bat para iniciar o cliente PDI.

Instalação Cliente PDI no Linux:

1. Instalar Java JDK 8:

apt-get install openjdk-8-jdk

2. Configuração da JAVA_HOME:

export PENTAHO_JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

3. Criar diretório:

mkdir -p /opt/pentaho/biclient/

Entre no diretório criado:

cd /opt/pentaho/biclient/

4. Baixar PDI e descompactar:

wget "https://svn.cafe.rnp.br/arquivos/pdi-ce-9.0.0.0-423.zip"

unzip pdi-ce-9.0.0.0-423.zip

5. Copiar Driver Mysql para o cliente:

wget https://svn.cafe.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/pdi-pentaho/mysql-connector-java-5.1.45-bin.jar -O /opt/pentaho/biclient/data-integration/lib

6. inicializar o cliente PDI:

/opt/pentaho/biclient/data-integration/spoon.sh

Conectar Cliente ao Servidor PDI:

PDI - Pentaho Data Integration - Configuração da conexão com Pentaho BI Server

• Clique em Connect (canto superior direito)

• Clique em repository manager

Clique em ADD:

• Clique Get Started:

• Preencha

  • Display Name: EID-PDI Server

  • URL: http://IP_SERVIDOR:8080/pentaho

  • FINISH

• Clique em Connect Now

Digite usuário, senha e clique em connect:

• User: admin

• Senha: password

Versão 8 PDI Cliente: https://svn.cafe.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/pdi-pentaho/pdi-ce-8.0.0.0-28.zip

Introdução

Com a finalidade de facilitar e tornar mais ágil a instalação de Provedores de Identidade (IdP) na Federação CAFe, a RNP disponibiliza a vm-idp que é uma pre-instalação de um IdP em forma de máquina virtual.

Este tutorial apresenta a sequência de passos necessários para que o usuário faça a configuração inicial da vm-idp.

Pré Requisitos para instalação

Guia Passo a Passo:

Primeira execução da vm-idp

No primeiro boot da vm-idp será carregado um script que é responsável por fazer a configuração do IdP. Tal script fará uma sequência de questões que deverão ser respondidas corretamente pelo usuário. O script irá iniciar assim que você alterar para o usuário root.

Mude o usuário atual para um usuário root:

Caso queria cancelar a execução do script use o comando:

ctrl+c

Escolha "s"

Para executar o script posteriormente durante a mesma sessão em que cancelou faça como o comando abaixo:

DICA:

1. A cada pergunta realizada pelo script será solicitada uma confirmação de resposta. Pressione "s" para confirmar a resposta e "n" para corrigir o valor digitado.

2. O script de instalação pode ser finalizado a qualquer momento pressionando-se as teclas CTRL+C. Caso isto seja feito, as configurações feitas até tal momento serão descartadas e a vm-idp executará o script novamente na inicialização seguinte.

A seguir serão apresentadas as questões presentes no script e sua devida explicação:

• Esta é a primeira tela exibida após a inicialização da máquina virtual. Pressione "Enter" para prosseguir com a configuração.

1. Inicialmente serão solicitadas informações referentes ao hostname e domínio. O hostname deve ser preenchido apenas com o nome que será atribuído à máquina (ex.: idp-cafe). O hostname não deverá conter o domínio.

2. O domínio deve conter as informações para o domínio externo de sua instituição (ex.: cafe.rnp.br).

3. A seguir são cobradas informações referentes a configuração de endereçamento IP. Tal etapa presume a utilização de IP estático na vm-idp. A utilização de IP estático é uma boa prática uma vez que gera independência do servidor de DHCP. O script identificada a placa de rede de sua máquina e a opção de escolha será fornecida como mostra o exemplo abaixo:

Uma simulação de respostas às questões acima é apresentada nas linhas abaixo.

Digite o endereco IP: 123.123.123.123

Digite a mascara: 24

Digite o gateway: 123.123.123.1

Digite o IP do DNS: 123.200.113.11

Após inserir o primeiro servidor DNS o script irá perguntar que gostaria de configurar um segundo servidor DNS, digite "1" para prosseguir com a configuração do segundo DNS ou apenas "2" para deixar somente um servidor DNS configurado.

4. Leitura de váriaveis e geração de chaves RSA para o SSH

Após realizar o termino da configuração inicial, hostname e IP o script irá iniciar as etapas seguintes, que precisam de acesso a internet para continuar. Se tudo der certo você verá a seguinte saída:

Nesse momento o script conseguiu gerar as chaves a partir das informações inseridas, aproveite para verificar as variáveis e se todas as informações estão corretas. Caso perceba algo errado, espere o script terminar sua execução e na próxima tela de pergunta digite "ctrl+c" para sair e iniciar o script novamente.

5. apt update e apt upgrade

Agora que o script possui acesso a rede ele irá iniciar a tarefa de atualização do sistema operacional. Fará de forma automática e executará um apt update + apt upgrade, apenas aguarde.

6. Baixando o script fristboot-complement.sh

Nesse momento o script irá acessar o repositório da CAFe para baixar o script que fará a segunda etapa de configuração do IDP.

7. Configuração do acesso e comunicação com diretório (AD / LDAP)

8. As opções a seguir devem ser escolhidas de acordo com o tipo de diretório da instituição, as questões seguintes tratam sobre o acesso ao diretório da instituição. Presume-se que tal diretório está adequadamente configurado

Aonde é perguntado o domínio do seu AD ou LDAP inserir o seu domínio local.

Endereço do servidor digitar o nome ou ip do seu diretório.

Digitar porta, inserir porta de comunicação com seu diretório, normalmente 389 e 636.

Dizer para o script se o seu diretório usa SSL ou não.

9. O bloco seguinte se refere às definições da base de usuários da instituição:

Digitar o Base DN aonde deve ocorrer a consulta do Shibboleth para validar os seus usuários.

Digitar o DN da conta que fará a consulta no Base DN inserido acima.

DIgitar a senha da conta informada acima.

10. Preencha as informações referentes aos responsáveis pelo serviço na instituição:

11. Após o preenchimento das configurações acima, o sistema irá proceder com a configuração automática do IDP. Esta configuração pode levar alguns minutos.

12. Por fim é solicitada a criação de uma nova senha para o usuário cafe. Lembre-se que é importante a criação de um senha complexa para garantir a segurança de seu servidor:

Também será solciitado uma senha para o usuário root.

13. Após confirmação da senha de root, o sistema será reiniciado

14. Visualização de logs:

Caso você deseje visualizar os logs gerados pela Shibboleth é possível utilizar o seguinte comando (já possui um filtro para mostrar apenas mensagens com WARN ou ERROR):

Homologação parcial

1. Para garantir que os passos descritos acima foram corretamente seguidos é necessário a execução de um script de homologação. Para fazer download desde script utilize a linha de comando abaixo:

2. Após fazer download, execute este script com permissão de root.

3. Se todas as checagens forem bem sucedidas você deverá receber a mensagem abaixo. Envie o arquivo de log gerado pelo script para o Service Desk e aguarde instruções para continuidade do processo de adesão.

Envie o arquivo de log gerado (XYZ.log) para o Service

Desk da RNP para dar continuidade ao atendimento.

4. Se ocorrer alguma falha na checagem você deverá receber a mensagem abaixo. Identifique qual/quais checagem não foram bem sucedidas e faça a devida correção. Em caso de dúvidas entre em contato com o Service Desk.

Verifique e corrija os erros e então execute novamente este script.

Ao acessar o Client Web do Pentatho, a tela acima será exibida, solicitando login e senha.

Efetuado o login, entraremos na página inicial da aplicação, onde teremos algumas opções de gerenciamento.

Vá em Home > Administration

Dentro desta sessão, teremos o gerenciamento dos Usuários (criação), Roles e perfis do Pentaho Server, conforme imagem abaixo:

Gerenciamento de Roles:

Configuração do SMTP para envio de e-mail:

Configuração relacionada a remoção de arquivos antigos, como os logs gerados após so agendamentos nas execuções dos Jobs:

-Log de execução de Jobs e Transformações:

Todo processo executado no PDI terá informações de saída relacionadas ao log do fluxo de trabalho. Isso fornece detalhes sobre o que está acontecendo durante a execução. Os logs podem ser monitorados através do cliente PDI ou da interface online do PDI via navegador: IP_SERVIDOR:8080

Aqui está uma lista de itens com os quais o log pode ajudar:

• Fornece informações relevantes sempre que uma execução do processo apresenta um erro, como etapas que estão falhando e rastreiam com a descrição principal do erro

• Fornece informações sobre um fluxo de trabalho se houver divisão de decisão

• Detecta gargalos e etapas de desempenho abaixo do padrão com base na duração de um procedimento; por exemplo, os tempos de execução armazenados podem ser usados ​​para detectar se um processo está demorando mais do que habitual

• Mostra o status dos processos atualmente em execução. Os logs fornecem informações sobre quando o processo iniciado, onde está atualmente, e dados relacionados ao seu status.

• Rastreia o que foi feito e quando.

Durante a execução dos jobs e transformações no PDI Cliente conseguimos verificar o log de execução da ferramenta.

Neste log conseguimos visualizar os detalhes sobre a execução como tempo restante, número de registros, erros de conexão com as bases de origem ou destino, erros na transformação de dados, excessões, etc

Para acessar este log basta clicar no ícone de engrenagem disponível logo abaixo a tela de exibição do Job:

Existem 7 configurações possíveis para o detalhamento de logs no Spoon:

Nothing - O log está ativado, mas não registra nenhuma saída.

Error - Mostra apenas linhas de erro.

Minimal - Usa apenas o log mínimo. Fornece informações sobre o status dos fluxos de trabalho.

Basic- Recomendação: Use o nível de log Básico (padrão). Ele mostra informações relacionadas a cada etapa.

Detailed - Use isto para solução de problemas: fornece uma saída detalhada de login.

Debug- Uma saída detalhada para fins de depuração. O nível de log de depuração nunca deve ser usado em um ambiente de produção.

Row Level (Very Detailed) - Registrando em um detalhe no nível da linha. Isso gera uma enorme quantidade de dados de saída de log.

Recomendamos usar o log Basic que registra basicamente as informações mais importantes da execução do Job.

Já quando existem erros no processo o tipo Error pode ser útil para identificar o problema rapidamente, e o tipo Row Level para identificar a linha que gerou o erro.

- Log Tomcat e PDI Server

O PDI Server roda no servidor de aplicação Tomcat. O Tomcat possui logs próprios, desta forma quanto o PDI não está disponível o primeiro log que devemos verificar é o do Tomcat.

/opt/pentaho-server/tomcat/logs

Logs disponíveis:

Catalina.out - Loga a maioria dos erros que acontecem na administração da ferramenta WEB

localhost.log -

localhost_access_log.2020-07-31.txt - Logs de acesso

host-manager.2018-08-07.log

manager.data.log

pentaho.log - O log próprio do PDI Server (pentaho.log) também disponível na pasta pode ser consultado para verificar problemas na ferramenta.

- Log do cliente Spoon:

O Spoon (cliente utilizado para acessar o PDI Server) também possui um log onde é possível verificar problemas que impedem a ferramenta de funcionar. Este log fica localizado em: /opt/dataintegration/logs/spoon.log

-Práticas recomendadas para níveis de log:

Os níveis de log devem ser mais baixos em um ambiente de produção ou controle de qualidade, mas podem ser mais altos em um ambiente de desenvolvimento ou não de produção.

O nível de log de depuração nunca deve ser usado em um ambiente de produção.

Os níveis de log também podem ser especificados quando o processo é executado com o PDI Client ou qualquer outra ferramenta de linha de comando.

O desempenho do processo pode ser afetado se o nível de registro de log form muito detalhado. Isso também aumentara a quantidade de informações armazenadas no log.

- Relatório de Erros:

Acesso via IP:8080

O agendamento é efetuado para automatizar a execução de um Job em específico. No exemplo, utilizamos o full-job-atualizacao-diaria.

Segue abaixo o caminho dos Jobs:

Home > eid > cafe (selecionar o job no qual sera feito o agendamento)

Após selecionar o Job, vá na opção Schedule, aparecerá a imagem abaixo:

Marque a opção "Append timestamp to generated content", as opções abaixo irão aparecer:

Indo em "Next" será apresentada a tela abaixo:

Nela podemos escolher o tipo de recorrência na execução do Job.

Feita a escolha de agendamento, é só ir em "Next".

Os parâmetros foram definidos durante a configuração do Client Pentaho. O "Finish" encontra-se indisponível pois neste servidor já existe esse Schedule cadastrado, portanto o Pentaho nao permite cadastrar outro, apenas alterar o mesmo Schedule para evitar duplicata.

Tela de Agendamento

Para verificar os agendamentos, basta ir no caminho abaixo:

Browser Files > Schedules

Esta opção nos permite gerenciar os agendamentos configurados no servidor Pentaho.

Abaixo é exibida a tela para configuração dos parâmetros disponíveis no PDI/EID:

Para chegar a esta tela é necessário abrir um job e clicar duas vezes na área em branco, depois selecionar a aba "Parâmetros":

OBS: Estes parâmetros precisam ser configurados nos seguintes jobs:

• full-job-atualizacao-diaria

• full-job-atualizacaoo-diaria-truncate

• job-atualizacao-contas-intradia

Antes de executar estes jobs no PDI é necessário preencher os parâmetros obrigatórios.

Os parâmetros configuráveis nesta tela se dividem em :

Parâmetros para configuração de envio de email com alertas e erros na execução dos Jobs:

• indicadorEnvioEmailAtivo - Quando informado com o valor "True" os alertas gerados serão enviados para o email configurado, caso configurado com o valor "False" nenhum email de alertas será enviado. Obrigatório.

• AuthenticationPassword - Senha do usuário no servidor SMTP em texto plano.

• AuthenticationUser - Usuário de autenticação no servidor SMTP, com endereço completo. Ex.: eidpdi@cafe.rnp.br

• destinationAddress - Email que receberá os alertas quando o PDI encontrar erros. Caso queira enviar para mais de um email , informar separados por vírgula. Ex.: alerta.eid@cafe.rnp.br, alerta2@cafe.rnp.br

• pentahoAddress - Ip público e porta do servidor pentaho. Ex.: 138.121.71.89:8080 , necessário para enviar o link do relatório de inconsistências encontradas durante o processamento no email de alerta.

• senderAddress - Email que enviará as alertas. . Ex.: eidpdi@cafe.rnp.br

• serverSMTPPort - Porta do servidor SMTP da Instituição. Ex.: 587

• serverSMTPServer - Endereço do servidor SMTP da Instituição. Exemplo: smtp.rnp.br Estes parâmetros informados acima serão obrigatórios apenas se o parâmetro "indicadorEnvioEmailAtivo" for informado com o valor "True".

Parâmetros para conexão com a base LDAP:

• host_address_ldap - Incluir o IP ou nome do servidor LDAP. Ex.: 138.121.71.89 ou ldap.rnp.br. (Obrigatório)

• host_port_ldap - Incluir a porta do servidor LDAP. Ex.: 389 (Obrigatório)

• raiz_base_ldap - Incluir a raiz do LDAP configurada no servidor. Ex.: dc=rnp,dc=br (Obrigatório)

• admin_ldap - Usuário configurado na base Ldap com permissão de leitura e escrita na base. Ex: cn=admin,dc=rnp,dc=br (Obrigatório)

• senha_admin_ldap - Senha em texto plano do usuário configurado no parâmetro "admin_ldap". (Obrigatório)

• dominio_Instituicao - Incluir o domínio da instituição. Ex.: rnp.br, utilizado para gerar atributos escolados como "Eppn" por exemplo. (Obrigatório)

Parâmetro para escolher forma de unificação de Conta:

• manterContaMaisRecente - Quando o PDI detecta mais de uma conta cadastrada para o mesmo usuário é necessário escolher apenas uma para ser enviada ao servidor LDAP. Ao preencher este parâmetro com "True" a conta mais recente será enviada ao LDAP, para detectar que a conta é mais recente o PDI verifica o ID do registro importado e compara qual é maior. No caso de mais de uma base de dados é possível também definir a prioridade pela base configurada como mais confiável, que no caso é sempre a primeira a ser importada com o campo "baseOrigem=1" . (Obrigatório)

Parâmetro para converter a senha para base64:

• castToB64 - Em algumas situações, o hash SHA e MD5 das senhas é armazenado como uma sequência de caracteres hexadecimais nas bases institucionais. Para envio da senha para o LDAP via LDIF é necessário que esse hash esteja em base64. Ao informar este parâmetro como "True" um algoritmo é usado durante a importação dos dados para transformar o valor hexa em base64, de forma a preservar o hash original da senha no diretório. Caso a senha já esteja no formato base64, ou esteja em texto plano o parâmetro deve ser informado com o valor "false". (Obrigatório) É importante ressaltar que o campo algoritmoSenha, configurado na transformação de "Conta" deve estar preenchido corretamente:

  • SHA, para senhas com hash SHA

  • MD5, para senhas com hash MD5

  • CRYPT, para senhas crypt

  • vazio, para senhas em texto plano

Os relatórios são usados para gerenciamento da base através do Pentaho, auxiliando na identificação de contas duplicadas, monitoramento de cadastro e agendamento dos Jobs.

O painel de relatório pode ser encontrado no caminho abaixo:

Home > eid > cafe > visualizacao > dashboards

Segue abaixo a imagem ilustrando a localização dos painéis de monitoramento:

PainelPessoas.wcdf

Para abrir o relatório, selecione-o e vá na opção "Open in a new window", conforme abaixo:

O relatório PainelPessoas.wcdf nos mostram os usuários que foram importados para a nova base, utilizando o Pentaho. Na listagem, é exibida as pessoas e seus vínculos.

PainelMonitoramentoJobs.wcdf

O relatório a seguir nos mostra os Jobs que foram executados, resultados e se houve erro durante o processo.

Para abrir o relatório, selecione-o e vá na opção "Open in a new window", conforme abaixo:

Podemos verificar o histórico de Jobs executados, os concluídos e abortados. No exemplo abaixo, mostra que tivemos uma ocorrência, indicando que um usuário em específico não foi migrado devido a um erro de formato no e-mail. Neste caso, o e-mail possui um espaço.

PainelCadastroPessoasDuplicadas.wcdf

O relatório a seguir, exibe as pessoas com o mesmo CPF na base.

Para abrir o relatório, selecione-o e vá na opção "Open in a new window", conforme abaixo:

No exemplo de base abaixo, não temos evidências de cadastros com CPF's duplicados. Mas caso exista na base do cliente, o Pentaho mostrará a lista na tela abaixo.

PainelPessoasContasDuplicadas.wcdf

O relatório a seguir funciona de forma similar ao anterior, porém, o resultado nos trás as contas duplicadas na base.

Para abrir o relatório, selecione-o e vá na opção "Open in a new window", conforme abaixo:

No exemplo abaixo, a base não possui contas duplicadas. Mas caso exista na base do cliente, o Pentaho mostrará a lista na tela abaixo.

Para aderir a CAFe a instituição precisa:

• Estar credenciada à RNP

• Solicitar a adesão ao Service Desk

Em linhas gerais o processo consiste em:

1. Realizar uma entrevista técnica para apresentação do serviço e sanar dúvidas da instituição

2. A instituição realizar a instalação do servidor do serviços e quando necessário, a configuração da base de usuários.

O tempo total do processo vai depender da disponibilidade da realização da entrevista e o tempo que a instituição vai levar para instalação.

Apache Directory Studio (ApacheDS) é uma ferramenta gráfica para manipulação de bases LDAP. O ApacheDS possui uma série de funcionalidade como por exemplo manipulação de entradas, atributos, arquivos LDIF, etc. Essa ferramenta é baseada na IDE Eclipse e possui versões para Linux, MacOS e Windows. O download pode ser feito através do seguinte link Neste tutorial básico serão apresentadas algumas das funcionalidades básicas desta ferramenta que serão úteis para o projeto E-AA.

Configuração Básica para Acesso a um Diretório LDAP

Para que o ApacheDS possa manipular um diretório LDAP deve-se inicialmente configurar o acesso a tal diretório na ferramenta. Para fazer tal configuração deve-se executar o seguinte roteiro:

1. Estando o ApacheDS em execução, clique em FILE > NEW. Expanda a o item LDAP Browser, selecione a opção LDAP Connection e clique em NEXT . A Figura 1 apresenta a tela descrita.

1. Tão logo a tela Network Parameter seja exibida informe um nome para esta conexão LDAP (campo Connection name), o endereço IP ou hostname do servidor LDAP (campo Hostname) e utilize os valores padrões para os campos porta (Port: 389) e método de encriptação (Encryption method: no encryption). A Figura 2 apresenta a tela descrita.

1. Uma vez preenchido os campos, clique sobre o botão Check Network Parameter a fim de verificar se existe conectividade entre o ApacheDS e o servidor LDAP. Se tudo ocorrer de forma adequada, será exibida uma tela conforma ilustrada na Figura 3. Clique sobre OK para fechar a tela e clique em NEXT na tela Network Parameter.

1. Na tela Authentication deverão ser preenchidos os campos relativos a autenticação no diretório LDAP. O método de autenticação deverá ser o padrão (Authentication Method: Simple Authentication), o Bind DN ou usuário deverá ser o administrador (i.e.: Bind DN or User: cn=admin,dc=cpd,dc=ufrgs,dc=br) já a senha deverá ser a senha do administrador informada durante a instalação do LDAP. A Figura 4 apresenta a tela descrita.

1. Uma vez preenchido os campos, clique sobre o botão Check Authentication a fim de verificar se existe a autenticação com o LDAP está correta. Se tudo ocorrer de forma adequada, será exibida uma tela conforma ilustrada na Figura 5. Clique sobre OK para fechar a tela e clique em NEXT na tela Au thentication.

1. Na tela Browser Options utilize os valores padrões e clique sobre NEXT. A Figura 6 apresenta a tela descrita.

1. Na tela Edit Options utilize os valores padrões e clique sobre FINISH. A Figura 7 apresenta a tela descrita.

1. Após seguir os passos anteriores a conexão ao Diretório LDAP estará configurada e será exibida uma tela conforma ilustrada na Figura 8.

Entradas

Entradas são tidas como a unidade básica na qual uma informação é armazenada em um diretório. Entradas representam objetos do mundo real e são compostas por uma coleção de atributos. A seguir será apresentado como fazer a manipulação básica de entradas através do ApacheDS. Vale lembrar que para realizar as tarefas a seguir presume-se que o ApacheDS já possua uma conexão configurada e ativa junto ao diretório LDAP.

Inserção de entrada

1. Para fazer a inserção de uma entrada, clique com o botão direito no mouse sobre algum item já existente no Diretório e selecione NEW > NEW ENTRY.

2. Na janela Entry Creation Method selecione a opção Create entry from scratch e clique sobre NEXT. A Figura 9 apresenta a ação descrita.

1. Na janela Object Classes selecione a(s) classe(s) de objeto(s) que irão compor a entrada. Para fazer a seleção, você deverá escolher um item presente na lista Avaliable Object Classes e depois clicar sobre Add. Feito isto, o referido item passará a compor a lista Selected Object Classes. Repita este processo até adicionar todas as classes de objetos necessárias. Clique sobre NEXT para avançar para próxima tela. A Figura 10 apresenta a tela descrita.

1. Na janela Distinguished Name deverá ser informado a entrada pai (Parent) bem como o RDN. Ao concluir a preenchimento desta janela clique em NEXT. Um exemplo desta configuração é apresentada na Figura 11.

1. Caso seja selecionada alguma classe de objeto que possua atributos de preenchimento obrigatório, estes serão exibidos na janela Attributes conforme ilustrado pela Figura 12. Para mudar o valor de algum atributo, clique sobre o campo Value na linha correspondente ao atributo em questão.

1. Caso algum destes atributos seja uma senha, será exibida a tela Password Editor (conforme ilustrado pela Figura 13). Preencha o campo Enter new password e selecione o método de Hash SHA. Após clique em OK.

1. Concluso o preenchimento dos atributos obrigatórios clique em FINISH.

2. Neste momento a entrada estará inserida no diretório LDAP.

Renomear entrada

A funcionalidade de renomear entrada é útil uma vez que se deseje alterar o nome de uma entrada já presente no diretório. O roteiro para renomear uma entrada é o seguinte:

1. Clique com o botão direito do mouse sobre a entrada e clique na opção Rename Entry.

2. Será exibida uma tela onde será possível alterar o RDN. Através desta alteração é que é possível renomear uma entrada. Altere o RDN para o novo nome da entrada e clique em OK. A Figura 14 apresenta a tela descrita.

1. Concluso este roteiro, a entrada estará renomeada.

Exclusão de entrada

A funcionalidade de exclusão de entrada é útil uma vez que se deseje excluir uma entrada presente no diretório. O roteiro para exclusão de uma entrada é o seguinte:

1. Clique com o botão direito do mouse sobre a entrada e clique na opção Delete Entry.

2. Será exibida uma tela solicitando a confirmação da exclusão e advertindo que eventuais entradas filho da entrada em questão também serão excluídas. Clique em OK para confirmar a exclusão. A Figura 15 apresenta a tela descrita.

1. Concluso este roteiro, a entrada estará excluída.

Atributos

Atributos contêm as informações sobre um dado objeto. Todo atributo deve possuir um tipo e pode ser multi-valorado. A seguir será apresentado como fazer a manipulação básica de atributos através do ApacheDS. Vale lembrar que para realizar as tarefas a seguir presume-se que o ApacheDS já possua uma conexão configurada e ativa junto ao diretório LDAP.

Inserção de atributo

1. Para fazer a inserção de um atributo, selecione a entrada a qual pertencerá o atributo e clique sobre o botão New Attribute conforme ilustrado na Figura 16.

1. Na janela Attribute Type selecione o tipo de atributo a ser inserido e clique em FINISH conforme ilustrado na Figura 17.

1. Ao retornar para a janela principal do ApacheDS, clique no campo VALUE e insira o valor do novo atributo conforme conforme ilustrado na Figura 18.

1. Concluso este roteiro, o atributo estará inserido.

Edição de atributo

A edição de um atributo presta-se a alterar as caracteristicas de um atributo já existente e pode ocorrer de duas formas distintas

Valor do atributo

1. Para editar o valor do atributo clique sobre uma entrada e depois clique sobre o campo VALUE do atributo em questão, conforme já exemplificado através da Figura 18.

2. Concluso este roteiro, o valor do atributo estará editado.

Descrição do atributo

1. Para editar a descrição do atributo, ou seja, o tipo de atributo, clique com o botão direito do mouse sobre o atributo e clique na opção Edit Attribute Description.

2. Na janela Attribute Type selecione o novo tipo do atributo e depois clique em FINISH. Tal janela já foi ilustrada através da Figura 17.

3. Concluso este roteiro, a descrição do atributo estará editado.

Exclusão de atributo

A funcionalidade de exclusão de atributo é útil uma vez que se deseje excluir um atributo presente em uma entrada no diretório. O roteiro para exclusão de uma atributo é o seguinte:

1. Clique com o botão direito do mouse sobre o atributo e clique na opção Delete Value.

2. Será exibida uma tela solicitando a confirmação da exclusão. Clique em OK para confirmar a exclusão. A Figura 19 apresenta a tela descrita.

1. Concluso este roteiro, o atributo estará excluído.

LDIF

LDIF é um formato de arquivo aceito pelo LDAP no qual pode ser descrito um conjunto de entradas ou sentenças de atualização. A seguir será apresentado como como executar LDIF já existentes através do ApacheDS.

1. Clique sobre o menu FILE > NEW

2. Expanda o item LDAP BROWSER, selecione o item LDIF FILE e clique em FINISH conforme ilustrado na Figura 20.

1. Feito isto, será exibida uma tela similar a da Figura 21.

1. Clique sobre BROWSE... para selecionar o conexão ao LDAP conforme ilustrado na Figura 22. Clique sobre a conexão desejada e depois clique em OK.

1. Na área de edição, insira o conteúdo do LDIF e posteriormente clique sobre o botão EXECUTE LDIF conforme ilustrado na Figura 23.

1. Se tudo ocorrer corretamente, o LDIF será executado e o diretório sofrerá as modificações que constam no LDIF. No caso deste exemplo o LDIF prestava-se a inserção de uma entrada chamada ou=people. Como pode ser visto, a inserção de tal entrada ocorreu perfeitamente e pode ser visualizada na Figura 24.

Efetue o download do Apache referente ao seu sistema operacional.

Efetue a instalação do Java JDK 11:

O próximo passo será configurar o Java na variável de ambiente no Windows. Indo em Propriedades;

Selecione Configurações avançadas do sistema;

Selecione Variáveis de Ambiente...

Dois cliques na opção Path nas Variáveis do sistema;

Clique em Novo e cole o caminho da pasta Bin do Java, conforme imagem abaixo, e dê OK;

Instalação do Apache DS

Clique em Next;

Clique em I Agree;

Clique em Install;

Clique em Next;

Clique em Finish.

Instalação finalizada.

Especificação Recomendada:

• Criado no formato OVF ()

• Sistema Operacional Ubuntu 22.04.3 LTS com instalação otimizada para ambientes de virtualização;

• Arquitetura de 64 bits;

• 8Gb RAM;

• 4 vCPU;

• 1 Disco rígido de 160 GBytes;

• 1 Adaptador de rede pré-configurado para usar ip fixo;

Especificação Mínima:

• Criado no formato OVF ()

• Sistema Operacional Ubuntu 22.04.3 LTS com instalação otimizada para ambientes de virtualização;

• Arquitetura de 64 bits;

• 4Gb RAM;

• 2 vCPU;

• 1 Disco rígido de 80 GBytes;

• 1 Adaptador de rede pré-configurado para usar ip fixo;

Requisitos para MFA:

Procedimento de importação

Baixe o template da máquina virtual através do link:

Descompactar o arquivo. Importe o arquivo transferido em seu ambiente de virtualização.

Ligue o servidor virtual recém importado.

SSH na porta 22 padrão.

Informações para Login na VM:

Procedimento de instalação Automatizada

Para os clientes que farão o uso do nosso template da CAFe o roteiro de instalação a ser seguido segue no link abaixo. Esse roteiro contempla todas as etapas de configuração auxiliadas pelo nosso instalador do IDP CAFe.

1. Copiar o arquivo da logo para o servidor IDP

Copie o arquivo pronto em formato .png para dentro do diretório /home/cafe do seu IDP.

2. Copie o arquivo para o diretório do Shibboleth

Uma vez com o arquivo correto em seu /home/cafe copie para o seguinte diretório:

cp /home/cafe/NOME_DO_SEU_ARQUIVO.png /opt/shibboleth-idp/edit-webapp/images/

3. Alterar o arquivo para o nome padrão do shibboleth

Após copiar o seu arquivo de logo para dentro do diretório /images do shibboleth, vamos agora alterar para o nome padrão que o shibboleth utiliza para carregar a imagem da logo na tela de login

cd /opt/shibboleth-idp/edit-webapp/images/
ls -l
-rw-r--r-- 1 root root  8208 Dec  5 23:54 dummylogo-mobile.png
-rw-r--r-- 1 root root 13742 Dec  5 23:54 dummylogo.png
-rw-r--r-- 1 root root  2580 Dec  5 23:54 failure-32x32.png
-rw-r----- 1 root root 11042 Dec  5 23:54 logo-instituicao.png
-rw-r--r-- 1 root root  6071 Dec  6 00:48 NOME_DO_SEU_ARQUIVO.png
-rw-r--r-- 1 root root  2448 Dec  5 23:54 success-32x32.png
mv NOME_DO_SEU_ARQUIVO.png logo-instituicao.png

4. Executar o script de rebuild do shibboleth para carregar a nova logo

Agora vamos acessar o script do shibboleth para executar um rebuild com a nova imagem da logo, para isso faça:

cd /opt/shibboleth-idp/bin
./build.sh
Buildfile: /opt/shibboleth-idp/bin/build.xml

build-war:
Installation Directory: [/opt/shibboleth-idp] ?
aperte [ENTER]

INFO [net.shibboleth.idp.installer.BuildWar:103] - Rebuilding /opt/shibboleth-idp/war/idp.war, Version 4.1.4
INFO [net.shibboleth.idp.installer.BuildWar:113] - Initial populate from /opt/shibboleth-idp/dist/webapp to /opt/shibboleth-idp/webpapp.tmp
INFO [net.shibboleth.idp.installer.BuildWar:92] - Overlay from /opt/shibboleth-idp/edit-webapp to /opt/shibboleth-idp/webpapp.tmp
INFO [net.shibboleth.idp.installer.BuildWar:125] - Creating war file /opt/shibboleth-idp/war/idp.war

BUILD SUCCESSFUL
Total time: 11 seconds

5. Reiniciar o serviço do Jetty9

systemctl restart jetty9.service

6. Testar sua alteração de logo

Acesse agora o portal https://sp.rnp.br/chimarrao e escolha a sua instituição, a sua tela de login agora deverá apresentar a sua nova logo !

Procedimentos

Durante a instalação do IDP é gerado um arquivo que contêm o bloco de metadado do provedor de identidade. Para que um provedor faça parte de uma Federação, uma das providências necessárias é a inclusão do bloco de metadado do provedor no arquivo de metadados da federação.

Os metadados da federação servem para informar aos seus participantes quais são os servidores "reconhecidos" e confiáveis.

O arquivo que possui o bloco de metadado do seu Provedor de Identidade IDP é o /opt/shibboleth-idp/metadata/idp-metadata.xml

Envie o arquivo de metadado para o endereço atendimento@rnp.br (caso já tenha um processo em andamento, basta mandar em reposta ao e-mail da equipe).

A equipe de operação CAFe então fará a verificação da integridade desse metadado, tudo estando certo esse metadado será inserido na federação Chimarrão para que seja iniciado a homologação do IDP.

Para que a receita possa funcionar de acordo com as informações da sua instituição, por exemplo, dados e informações necessárias e exclusivas da usa rede e infraestrutura, o RPilot fornece uma opção de inserção de variáveis específicas que a receita entende como sendo os parâmetros da instalação.

No caso do IDP da CAFe existem 26 variáveis necessárias para a instalação correta do IDP. Que podemos dividir em 3 subclasses:

• Informações para certificado Shibboleth e metadado

• Informação para conexão e configuração com base de diretório

• Informações para configuração de um <virtualhost> Apache

Shibboleth e Metadado

ORGANIZATION -> Nome da Instituição por extenso. Exemplo: Rede Nacional de Ensino e Pesquisa

INITIALS -> A sigla da instituição. Exemplo: RNP

CITY -> Cidade da instituição. Exemplo: Brasília

STATE -> Unidade Federativa da instituição. Exemplo: DF

URL -> Endereço da página institucional. Exemplo: https://www.rnp.com

OU -> Sigla do setor técnico. Exemplo: DTI

CONTACTGIVEN -> Nome do responsável técnico. Exemplo: João Silva

CONTACTMAIL -> Endereço de email do contato. Exemplo: joao.silva@rnp.br

CONTACTSUR -> Sobrenome do contato apenas. Exemplo: Silva

Conexão e configuração com Diretório LDAP/AD

LDAPATTR -> Atributo para autenticação na CAFe. Exemplo: uid, mail ou sAMAccountName

LDAPDN -> DN onde consulta os usuários na base LDAP. Exemplo: ou=pessoas,dc=rnp,dc=local

LDAPFORM -> Formato para construção das consultas na base LDAP. Exemplo: uid=%s,dc=rnp,dc=local

LDAPPWD -> Senha do usuário de BIND da base LDAP.

LDAPSERVER -> Endereço do servidor LDAP. Exemplo: 192.168.1.20

LDAPSERVERPORT -> Porta usada para conexão LDAP. Exemplo: 389 ou 636

LDAPSERVERPROTO -> Protocolo de comunicação LDAP. Exemplo: ldap:// ou ldaps://

LDAPSERVERSSL -> Valor 0 para SEM SSL e valor 1 para COM SSL.

LDAPSUBTREESEARCH -> Permitir consulta vertical abaixo do DN LDAP informado, por padrão essa opção deve estar 'true'. Exemplo: true

LDAPUSER -> Usuário de BIND para consulta no LDAP. Exemplo: uid=leitor-shib,ou=pessoas,dc=rnp,dc=local

Configuração para o Apache

DOMAIN -> Apenas o domínio da instituição. Exemplo: rnp.br

HN -> Apenas o nome do servidor, sem domínio. Exemplo: idp

HN_DOMAIN -> Apenas o domínio. Exemplo: cafe.rnp.br

INTERFACE -> Digitar o valor da Interface de rede do servidor. Exemplo: eth2, ens160, eth0, etc...

IP -> Digitar o IP do servidor IDP. Se estiver usando NAT digitar o IP NAT.

Preencher os valores dos parâmetros de acordo com a suas informações

Ao terminar de preencher todos os campos clicar no botão "Próximo" ao final do rodapé.

Antes uma breve introduação ao serviço do RPilot. O RPilot funciona com um automatizador de processos, para o produto da CAFe ele irá auxiliar e executar para nossos clientes as ações de instalação do IDP, sua configuração e sua atualização. Ele conta com um motor shell script para executar suas receitas.

Etapas

Necessário solicitar ao sistema RNP sua adesão ao serviço do RPilot, para isso você deve entrar em contato através do canal do nosso atendimento@rnp.br, nós envie um email com o assunto 'Adesão ao RPilot', lembrando que será apenas aceito aquelas instituições que já foram homologadas como aderentes ao sistema RNP.

• Enviar um email para atendimento@rnp.br com assunto Adesão RPilot

• Aguardar o retorno dos acessos para RPilot

• Após receber os credencias realizar o primeiro acesso ao sistema RPilot

Guia deste roteiro

• Servidores

• Produtos

• Receitas

Como associar o seu servidor ao RPilot

Após seu autenticar no sistema você será encaminhado a tela de gerenciamento da sua instituição dentro do RPilot. Será apresentado um Menu lateral esquerdo conforme figura abaixo:

O nome da sua instituição será mostrado logo acima.

No menu procure por "Servidores", clique para acessar essa opção.

Servidores

Na tela que será apresentada clique no botão azul "+ Adicionar Servidor", ele aparece ao lado direito da tela, veja figura abaixo:

Nesse momento será necessário passar os dados do servidor para que o sistema RPilot o identifique. Preencha os dados ali solicitados:

• Nome do Servidor - "Use um nome fácil para sua identificação, sugiro que seja o nome usado em seu virtualizador, assim você saberá de qual máquina se trata"

• Domínio - "Use o domínio que será usado para o DNS desse serviço, por exemplo rnp.br"

• Host - "Use o nome que será usado para o DNS dese serviço, por exemplo cafe ou idp, sem o domínio apenas o nome"

• Nome da interface de rede - "Colete o nome da sua inteface de rede do seu servidor, para isso use o comando em seu sistema Linux, por exemplo eth0, ens160, etc"

• Endereço IP - "Passar o endereço IP do seu servidor, se estiver usando NAT passar o endereço NAT"

• Máscara de Rede - "Passar a máscara de rede onde o servidor esta configurado, passar no formato de quatro octetos, por exemplo 255.255.255.0"

• Ao final clicar no botão azul "Salvar"

Figura abaixo:

Detalhes do Servidor

Após fazer o cadastro correto do seu serivdor no RPilot você será direcionado para a tela de detalhes do servidor, use essa tela para rever sua configurações e caso perceba algo de errado em sua configurações use o botão Editar no campo superior direto.

Nesse momento também será feita a instalação do agente do RPilot no seu servidor configurado. Para isso você vai precisar copiar o comando que aparece indicado em "Instrução de Instalação do Agente".

Estando com os requsitos prontos basta executar o comando dentro do seu servidor e aguardar o fim da instalação. Quando o processo estiver terminado aguarde o campo "Status" ser alterado para agente instalado e ficar na cor verde.

Pronto! Nesse momento concluímos a instalação do Agente do Rpilot no seu servidor IDP. Agora iremos para as próximas etapas:

• Escolha do Produto

• Execução da Receita

Após seguir para o próximo passo de execução uma tela de revisão dos parâmetros será apresentado para que você possa verificar se as informações passadas para a receita de instalação estão corretas.

Se algo estiver incorreto você pode clicar no botão "Voltar" para corrigir. Se tudo estiver correto você pode então confirmar a execução da receita de instalação do IDP.

Nessa roteiro iremos aprender o processo de solicitar a execução de uma ação dentro do nosso servidor usando o RPilot. Nosso foco aqui será a instalação do IDP da CAFe então esse processo será direcionado para isso não dando ênfase em outros pontos. Caso tenha interesse em saber mais sobre a ferramenta RPilot acesse o manual do usuário através desse Link.

Esse é o painel de execuação. Nele podemos executar a receita de instalação do IDP da CAFe.

Repare que nele podemos confirmar o nosso servidor através das informações do servidor como Nome , Chave de registro , ID do Registro único, Domínio, Hostname e IP.

Também pode verificar o Status do agente RPilot instalado no seu servidor, confirme se ele está com o Status em verde com a informação "Agente Instalado".

Passos para execução:

• Escolher o tipo de execução

• Escoher a opção "Executar Receita"

• Clicar no botão "Próximo"

Será mostrada uma tela para que você possa escolher seu "Produto" e abaixo você deve escolher qual "Receita" deseja executar:

Escolha o produto CAFe e a receita de Instalação do IDPvX.X.X conforme figura acima.

Você será apresentado em uma painel com um formato em tabela, sendo ele dividio da seguinte forma:

6 colunas

Nome do Servidor -> Servidor no qual foi executado aquela receita.

Tipo de execução -> Se foi executado uma Receita, um Comando Avulso ou uma Geração de Certificado.

Data da Solicitação -> Data e hora da solicitação, início.

Data da execução -> Data e hora da execução, término.

Status -> Executando, Sucesso ou Erro.

Ações -> Log

Após a execução terminar, seja com Sucesso ou Erro você pode clicar emcima da linha ou ir em Ações nas 3 bolinhas e clicar em Log para verificar o log de execução da Receita.

Dashboard Servidor

Para acessar o dashboard do seu servidor dentro do RPilot você precisa acessar a opção "Servidores" no menu de funcionalidades lateral esquerdo. Figura abaixo:

Para acessar o dashboard do seu servidor você pode ou clicar em cima da linha referente ao seu servidor, ele é clicável, ou clicar no ícone das 3 bolinhas dentro da coluna "Ações", Figura abaixo:

Após acessar o painel do dashboard será apresentado um pequeno painel de monitoramento e gerenciamento. Será nesse painel que você irá encontrar o caminho para as solicitações de execução das receitas dos seus produtos vinculados, conforme figura abaixo:

No canto superior esquerdo o indicativo do nome do servidor que está aberto, todas as suas ações dentro desse painel será para esse servidor.

No canto inferior esquerdo é possível ver o status do agente para esse servidor.

No canto superior direito temos o botão para solicitar a execução de uma ação em seu servidor.

Para disponibilizar um serviço via federação (CAFe) basta a instituição entrar em contato com o Service Desk da RNP para iniciar o processo.

Em linhas gerais o processo consiste em:

1. Coleta de informações sobre o serviço por parte da RNP.

2. Coleta de metadados da instituição

3. Inserção dos metadados na federação

Preparando o certificado !

Preparar o seu certificado válido para a substituição no seu IdP:

Pré-requisitos:

Instalar o programa dos2unix em seu IdP.

sudo apt install dos2unix

salvar o arquivo do seu certificado no /home/cafe

sudo dos2unix arquivo_certificado.cer
sudo cat arquivo_certificado.cer > arquivo_certificado.crt

Pronto, agora você pode seguir o guia passo a passo logo abaixo.

Caso o seu certificado possua mais de um arquivo, como intermediate.pem e GlobalSignR3.pem, preparar o arquivo conforme instruções abaixo:

sudo dos2unix arquivo_certificado.cer intermediate.pem GlobalSignR3.pem
sudo cat arquivo_certificado.cer > arquivo_certificado.crt
sudo cat intermediate.pem >> arquivo_certificado.crt
sudo cat GlobalSignR3.pem >> arquivo_certificado.crt

Pronto, agora você pode seguir o guia passo a passo logo abaixo.

Guia passo a passo

Roteiro passo a passo para troca de certificado web em um IdP institucional:

Após preparar o arquivo (*.CRT) que deseja inserir no seu IdP, vá até o diretório desejado e substituia pelo certificado que atualmente está lá. Por Exemplo:

cd /etc/ssl/certs

Encontre o arquivo "certificado-apache.crt" e renomeie. Por Exemplo:

sudo cp certificado-apache.crt certificado-apache.crt.old

Agora vamos copiar o contéudo do arqruivo_certificado.crt que está em seu diretório /home/cafe para o arquivo certificado-apache.crt que está no diretório /etc/ssl/certs

sudo cat arquivo_certificado.crt > /etc/ssl/certs/certificado-apache.crt

Agora vamos substituir o .key no diretório /etc/ssl/private, antes vamos fazer o backup.

sudo cp chave-apache.key chave-apache.key.old

Substituir o arquivo .key

sudo cat arquivo_certificado.key > /etc/ssl/private/chave-apache.key

Após copia-lo para esse diretório é o momento de reiniciar o serviço do apache, para isso execute o seguinte comando:

systemctl restart apache2.service

Altere as seguintes linhas:

Por exemplo:

Guia passo a passo

Seguir o passos abaixo:

Esse é o link para o download do script de geração dos certificado para o Shibboleth:

wget /tmp/https://svn.cafe.rnp.br/repos/CAFe/scripts/gerar-certificado-shibboleth.sh
sudo chmod +x /tmp/gerar-certificado-shibboleth.sh
cd /tmp
sudo ./gerar-certificado-shibboleth.sh

Se tudo der certo, o novo certificado será gerado e já gravado no devido diretório.

Após finalizar com sucesso o script o novo certificado foi gravado no seu novo arquivo de metadado, acesse o diretório /opt/shibboleth-idp/metadata e copie o arquivo "idp-metadata.xml". Esse arquivo deve ser enviado para equipe técnica da CAFe RNP para a atualização na Federação CAFe.

Esse roteiro visa ajudar na configuração do seu IdP para que os acessos federados sejam realizados com mais um critério a ser atendido no momento do login. As configurações serão realizadas no arquivo ldap.properties, esse arquivo contêm toda a informação de conexão do seu IdP com sua base de diretório OpenLDAP.

Esse procedimento tem como requisito a criação do grupo, que deseja usar, no seu LDAP. Antes de começar crie seu grupo em sua base OpenLDAP.

Esse roteiro não irá esclarecer a forma como deve ser feita a criação de grupos em seu OpenLDAP ou AD.

Guia passo a passo

Faremos abaixo as etapas de configuração do arquivo "ldap.properties" para que as contas em seu OpenLDAP atendam um critério maior na consulta pelo Shibboleth em seu IdP:

Vamos abrir o arquivo "ldap.properties" dos seu IdP, use um editor de sua preferência, é recomendado o uso do VI ou VIM. O caminho é /opt/shibboleth-idp/conf :

# LDAP authentication configuration, see authn/ldap-authn-config.xml
## Authenticator strategy, either anonSearchAuthenticator, bindSearchAuthenticator, directAuthenticator, adAuthenticator
#idp.authn.LDAP.authenticator = anonSearchAuthenticator
idp.authn.LDAP.authenticator = bindSearchAuthenticator
## Connection properties ##
idp.authn.LDAP.ldapURL = ldaps://Openldap.homolog.rnp:636
idp.authn.LDAP.useStartTLS = false
idp.authn.LDAP.useSSL = false
idp.authn.LDAP.connectTimeout = 3000
## SSL configuration, either jvmTrust, certificateTrust, or keyStoreTrust
idp.authn.LDAP.sslConfig = certificateTrust
## If using certificateTrust above, set to the trusted certificate's path
idp.authn.LDAP.trustCertificates = %{idp.home}/credentials/ldap-server.crt
## If using keyStoreTrust above, set to the truststore path
idp.authn.LDAP.trustStore = %{idp.home}/credentials/ldap-server.truststore
## Return attributes during authentication
## NOTE: this is not used during attribute resolution; configure that directly in the
## attribute-resolver.xml configuration via a DataConnector's <dc:ReturnAttributes> element
idp.authn.LDAP.returnAttributes = uid
## DN resolution properties ##
# Search DN resolution, used by anonSearchAuthenticator, bindSearchAuthenticator
# for AD: CN=Users,DC=example,DC=org
idp.authn.LDAP.baseDN = ou=RNP,dc=homolog,dc=rnp
idp.authn.LDAP.subtreeSearch = true
idp.authn.LDAP.userFilter = (uid={user})
# bind search configuration
# for AD: idp.authn.LDAP.bindDN=adminuser@domain.com
idp.authn.LDAP.bindDN = uid=leitor-shib,ou=Admins,dc=homolog,dc=rnp
idp.authn.LDAP.bindDNCredential = XXXXXXXX
# Format DN resolution, used by directAuthenticator, adAuthenticator
# for AD use idp.authn.LDAP.dnFormat=%s@domain.com
idp.authn.LDAP.dnFormat = uid=%s,ou=RNP,dc=homolog,dc=rnp
# LDAP attribute configuration, see attribute-resolver.xml
idp.attribute.resolver.LDAP.ldapURL = %{idp.authn.LDAP.ldapURL}
idp.attribute.resolver.LDAP.baseDN = %{idp.authn.LDAP.baseDN}
idp.attribute.resolver.LDAP.bindDN = %{idp.authn.LDAP.bindDN}
idp.attribute.resolver.LDAP.bindDNCredential = %{idp.authn.LDAP.bindDNCredential}
idp.attribute.resolver.LDAP.useStartTLS = %{idp.authn.LDAP.useStartTLS:true}
idp.attribute.resolver.LDAP.trustCertificates = %{idp.authn.LDAP.trustCertificates}
idp.attribute.resolver.LDAP.searchFilter = (uid=$requestContext.principalName)
# LDAP pool configuration, used for both authn and DN resolution
#idp.pool.LDAP.minSize = 3
#idp.pool.LDAP.maxSize = 10
#idp.pool.LDAP.validateOnCheckout = false
#idp.pool.LDAP.validatePeriodically = true
#idp.pool.LDAP.validatePeriod = 300
#idp.pool.LDAP.prunePeriod = 300
#idp.pool.LDAP.idleTime = 600
#idp.pool.LDAP.blockWaitTime = 3000
#idp.pool.LDAP.failFastInitialize = false

# LDAP authentication configuration, see authn/ldap-authn-config.xml
## Authenticator strategy, either anonSearchAuthenticator, bindSearchAuthenticator, directAuthenticator, adAuthenticator
#idp.authn.LDAP.authenticator = anonSearchAuthenticator
idp.authn.LDAP.authenticator = bindSearchAuthenticator
## Connection properties ##
idp.authn.LDAP.ldapURL = ldaps://Openldap.homolog.rnp:636
idp.authn.LDAP.useStartTLS = false
idp.authn.LDAP.useSSL = false
idp.authn.LDAP.connectTimeout = 3000
## SSL configuration, either jvmTrust, certificateTrust, or keyStoreTrust
idp.authn.LDAP.sslConfig = certificateTrust
## If using certificateTrust above, set to the trusted certificate's path
idp.authn.LDAP.trustCertificates = %{idp.home}/credentials/ldap-server.crt
## If using keyStoreTrust above, set to the truststore path
idp.authn.LDAP.trustStore = %{idp.home}/credentials/ldap-server.truststore
## Return attributes during authentication
## NOTE: this is not used during attribute resolution; configure that directly in the
## attribute-resolver.xml configuration via a DataConnector's <dc:ReturnAttributes> element
idp.authn.LDAP.returnAttributes = uid
## DN resolution properties ##
# Search DN resolution, used by anonSearchAuthenticator, bindSearchAuthenticator
# for AD: CN=Users,DC=example,DC=org
idp.authn.LDAP.baseDN = ou=RNP,dc=homolog,dc=rnp
idp.authn.LDAP.subtreeSearch = true
idp.authn.LDAP.userFilter = (&(uid={user})(memberof=cn=GRP_SRV_CAFE,ou=GRUPOS,dc=homolog,dc=rnp))
# bind search configuration
# for AD: idp.authn.LDAP.bindDN=adminuser@domain.com
idp.authn.LDAP.bindDN = uid=leitor-shib,ou=Admins,dc=homolog,dc=rnp
idp.authn.LDAP.bindDNCredential = XXXXXXXX
# Format DN resolution, used by directAuthenticator, adAuthenticator
# for AD use idp.authn.LDAP.dnFormat=%s@domain.com
idp.authn.LDAP.dnFormat = uid=%s,ou=RNP,dc=homolog,dc=rnp
# LDAP attribute configuration, see attribute-resolver.xml
idp.attribute.resolver.LDAP.ldapURL = %{idp.authn.LDAP.ldapURL}
idp.attribute.resolver.LDAP.baseDN = %{idp.authn.LDAP.baseDN}
idp.attribute.resolver.LDAP.bindDN = %{idp.authn.LDAP.bindDN}
idp.attribute.resolver.LDAP.bindDNCredential = %{idp.authn.LDAP.bindDNCredential}
idp.attribute.resolver.LDAP.useStartTLS = %{idp.authn.LDAP.useStartTLS:true}
idp.attribute.resolver.LDAP.trustCertificates = %{idp.authn.LDAP.trustCertificates}
idp.attribute.resolver.LDAP.searchFilter = (uid=$requestContext.principalName)
# LDAP pool configuration, used for both authn and DN resolution
#idp.pool.LDAP.minSize = 3
#idp.pool.LDAP.maxSize = 10
#idp.pool.LDAP.validateOnCheckout = false
#idp.pool.LDAP.validatePeriodically = true
#idp.pool.LDAP.validatePeriod = 300
#idp.pool.LDAP.prunePeriod = 300
#idp.pool.LDAP.idleTime = 600
#idp.pool.LDAP.blockWaitTime = 3000
#idp.pool.LDAP.failFastInitialize = false

idp.authn.LDAP.userFilter = (&(uid={user})(mail=*@domínio))

idp.authn.LDAP.userFilter = (|(uid={user})(mail={user}))

Ao final da configuração, você deve salvar as alterações no arquivo e então reiniciar o serviço do tomcat utilizando o seguinte comando:

systemctl restart jetty9.service

Você pode usar o SP da RNP → https://sp.rnp.br/ escolher a opção CAFe e validar a sua configuração tentando um acesso pelo seu IdP.

Guia passo a passo

Vamos agora baixar o script de modificação e gerar novos arquivos com o novo hostname e novo dominio:

Baixar o script para o diretorio /tmp

1. Quando iniciar o script o mesmo irá te perguntar algumas informações, que precisam ser passadas para a exceução do script, tenha atenção neste etapa:

2. "Digite apenas o nome do host antigo: " Digitar aqui apenas o hostname antigo do seu IdP Ex: cafe-idp-antigo

3. "Digite apenas o dominio do host antigo: " Digitar aqui apenas o dominio antigo do seu IdP Ex: org.edu.antigo.br

4. "Digite apenas o nome do host novo: " Digitar aqui apenas o novo hostname do seu IdP Ex: cafe-idp-novo

5. "Digite apenas o dominio do host novo: " Digitar aqui apenas o novo dominio do seu IdP Ex: org.edu.novo.br

6. "Digite o nome do contato tecnico do servico (ex.: Joao da Silva): " Digitar o nome do contato técnico

7. "Digite o e-mail do contato tecnico do servico (ex.: joao.silva@instituicao.br): " Digitar o email do contato técnico

8. "Digite o nome da instituicao por exetenso (ex.: Rede Nacional de Ensino e Pesquisa): " Digitar por extenso o nome da instituição

9. "Digite a sigla da instituicao (ex.: RNP): " Digitar a SIGLA da instituição em maiusculo

10. "Digite o endereco do site da instituicao (ex.: www.instituicao.br):" Digitar a Url da instituição

11. "Digite o nome departamento da instituicao que eh responsavel por este servico (ex.: CPD): " Digitar o departamento resposável pelo IdP na instituição

12. "Digite o nome da cidade onde esta sediada a instituicao (ex.: Porto Alegre): " Digitar a cidade

13. "Digite por extenco o nome da Unidade Federativa onde esta sediada a instituicao (ex.: Rio Grande do Sul): " Digitar o nome da unidade federativa da instituição

Se tudo ocorrer sem problemas o script ira realizar as modificações necessárias e o seu IdP estará com o novo hostname e dominio configurados, porém no final do processo será necessário enviar para equipe técnica da CAFe RNP o novo "idp-metadado.xml" para o cadastro na CAFe produção. Esse arquivo você encontra no seguinte caminho:

Copiar o arquivo "idp-metadata.xml" e enviar o arquivo em anexo para equipe da RNP, para o cadastro do IdP com o novo hostname e dominio.

Guia passo a passo

Seguir as etapas abaixo para a remoção do serviço fail2ban da execuação do seu servidor IdP.

Primeiro logar em seu Idp e se tornar "root"

Executar o comando "systemctl status" e verificar se o serviço fail2ban está iniciado.

Executar o comando "systemctl stop fail2ban.service" e parar o serviço. Você pode executar novamente o comando da etapa 1 e verificar se o serviço foi parado.

Agora vamos desabilitar o serviço na inicialização do servidor, assim quando o mesmo for reiniciado o serviço não voltará a subir novamente.

Executar o comando "systemctl disable fail2ban.service", isso irá tirar o serviço da inicialização automática do servidor.

Pronto! O fail2ban não será mais iniciado no servidor.

Esse artigo foi criado para ajudar aquelas instituições que já possuem um serviço de segurança mais robusto e o fail2ban não é necessário, caso não saiba ou não esteja certo de como sua infraestrutura esteja configurada nós não recomendamos o desligamento deste serviço do seu IdP.

Essa responsabilidade será toda da equipe responsável pelo IdP institucional, a RNP não se responsabiliza por qualquer dano ao serviço ou a instituição causada pela escolha do desligamento do fail2ban do servidor IdP institucional.

Guia passo a passo para AD:

O shibboleth IDP em sua versão 4.2.x veio com algumas alterações na configuração de atributos, configurações essas que vieram para melhorar a manutenção e customização do IDP pelos responsáveis do serviço. Nessa versão tivemos a inlcusão de um novo recurso dentro do diretório /conf agora dentro desse diretório encontramos o sub diretório /attributes.

Esse sub diretório /attributes agora fica responsável por conter arquivos de configuração .xml que tratam sobre as especificações dos atributos suportados pelo IDP. Dentro desse diretório você verá os arquivos dividídos pelos seus respectivos schemas.

Para essa adequação do CPF e Data de Nascimento foi usado atributos que já estão mapeados pelo IDP dentro do schema .../conf/attributes/inetOrgPerson.xml e também já são atributos presentes no Microsoft AD.

Optamos por usar os atributos employeeNumber e employeeType

Seguir as etapas abaixo:

Dentro do seu Microsoft AD você precisa abrir o Editor de Atributos dos usuários e procurar pelos atributos employeeNumber e employeeType, veja figura abaixo:

Faça o preenchimento desses atributos seguindo a orientação de usar valores para Data de Nascimento em employeeNumber, sempre no formato AAAAMMDD e os valores para o CPF em employeeType, sempre no formato inteiro sem pontos e hífen.

Uma vez os valores populados em seu AD podemos agora configurar o shibboleth para que ele leia esse valores e entregue como se fosse o sachDateOfBirth e o brPersonCPF, passo a passo logo abaixo:

Abrir e editar o arquivo "attribute-resolver.xml", caminho: /opt/shibboleth-idp/conf e procure pelas entradas com id=brPersonCPF e id=schacDateOfBirth eles estão perto um do outro.

Vamos nesse momento alterar os valores de referencia desses dois atributos, temos que alterar a entrada da variável attributeNames="brPersonCPF" e attributeName="schacDateOfBirth" para os seguintes valores:

attributeNames="employeeType"

attributeNames="employeeNumber"

Procurar no arquivo de configuração na secção de Data Connectors a entrada <dc:ReturnAttributes>...</dc:ReturnAttributes>, ela faz referência aos atributos que serão retornados pelo seu IdP, essa configuração ainda deve ser feita no arquivo attribute-resolver.xml.

Nessa parte do bloco você deve acrescentar os dois novos atributos na linha de entrega, veja como deve ficar após sua alteração:

<ReturnAttributes>%{idp.authn.LDAP.returnAttributes} mail cn givenName sn brPersonCPF schacDateOfBirth employeeType employeeNumber </ReturnAttributes>

Muito importante que você inclua os dois atributos referenciados pelo seu AD para serem usados como CPF e Data de Nascimento, dentro desta linha do código, pois é ela quem irá liberar esses atributos e entrega-los ao serviço.

Faça a modificação, caso necessário, adicione a regra para a libração dos atributos CPF e Data de Nascimento para o ICPedu, salve o arquivo e feche.

Faça o restart do serviço:

Criando certificados csr e key

Substituir o termo {exemplo.rnp.br} pelo nome do seu host de aplicação, por exemplo:

Criando certificado crt

Permissao para os arquivo

Imprimindo certificados para envio ao MOKA da CAFe

O resultado irá aparecer na tela, copie APENAS os valores que irão aparecer entre as TAGs

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

Após copiar esse valor substitua no arquivo de metadado aonde aparecer as TAGs

Metadado do SP gerado manualmente

Legenda

Substituir $HOSTNAME, $NOME_SERVICO, $SIGLA_SERVICO, $DESCRICAO_SERVICO, $URL_SERVICO, $CONTATO e $EMAIL_CONTATO

Pronto ao final salve suas modificações no arquivo e envie o metadado para a equipe de operação da CAFe GTI/RNP através de um chamado pelo nosso canal de atendimento.

Seu metadado será inserido na federação Chimarrão para homologação e se aprovado será migrado para a federação CAFe.

Procedimento para atualização de certificado em um SP

Encontrar onde estao os certificados

Fazendo backup dos certificados atuais

Removendo certificados atuais

Testando e resetando shibboleth

• Ajustar as mensagens na tela de login

Ajustar as mensagens na tela de login

Guia Passo a Passo:

Esse roteiro ira ajudar na customização das mensagens da tela do login do seu IdP:

Todas as alterações serão feitas no arquivo messages_pt_BR.properties, para isso abra o arquivo com um editor de sua preferência, o caminho é /opt/shibboleth-idp/messages

1. Campo Username, alterando a mensagem:

Altere as entradas idp.login.username.label para alterar a mensagem do campos Username respectivamente, pode ser usado para informar aos clinetes que irão usar o seu IdP como devem proceder com o acesso a CAFe.

Para inserir uma nova mensagem basta apagar a mensagem atual em vermelho e escrever sua nova mensagem ao usuário, lembrando que a formatação deve ser respeitada, mantenha um espaço entre o valor = e o inicio da sua nova mensagem.

Feita a alteração basta salvar o arquivo com seu editor e executar o comando build.sh do shibboleth para que ele possa carregar as novas alterações. Para isso faça:

Nesse momento o script estará te perguntando em qual diretório padrão está a instalação do Shibboleth, por padrão é esse mesmo /opt/shibboleth-idp então basta apertar a tecla [Enter]

Aguarde a seguinte mensagem:

Essa mensagem indica que o rebuild ocorreu como esperado !

Agora vamos reinicar o shibboleth, faça:

Pronto ! Agora você pode verificar como ficou sua modificação, acesse o portal https://sp.rnp.br/chimarrao escolha sua instituição e clique em "Prosseguir" na próxima tela será apresentado a caixa de login e senha da sua instituição e se tudo deu certo a sua nova mesnagem estará aparecendo.

Introdução

Este tutorial apresenta os passos necessários para se fazer a instalação do Shibboleth Service Provider (SP). Tal ferramenta será utilizada para atuar como provedor de serviços dentro da Federação CAFe.

A seguir serão apresentados os requisitos bem como roteiro para a referida instalação. É importante ressaltar que ao longo da instalação existem variáveis (que estão destacadas em negrito) que devem ser substituídas manualmente pelos seus respectivos valores.

Requisitos

Para executar este roteiro, espera-se que já tenham sido executados os seguintes roteiros anteriormente:

Clique aqui: Geração de Chave e Certificado para atender os itens 1, 2.1 e 2.4

Glossário de Variáveis

Ao longo deste roteiro serão utilizadas algumas variáveis que deverão ser substituídas para que ocorra o perfeito funcionamento dos arquivos de configuração. A seguir é apresentado um glossário para substituição das variáveis:

Roteiro

Inicialmente faça a instalação do Apache 2 bem como dos módulos para PHP5 e Shibboleth 2. Para tanto execute a linha de comando a seguir:

apt-get -y install apache2 libapache2-mod-php5 libapache2-mod-shib2

Verifique o arquivo /etc/apache2/ports.conf para constatar a presença das linhas Listen 80 e Listem 443. Caso tais linhas não existam ou estejam comentadas, adicione-as ao final do arquivo.

Faça a liberação do Shibboleth no arquivos de regras do firewall. Para tanto adicione as linhas abaixo no arquivo /etc/default/firewall.

# Liberação do Apache (Shibboleth-SP) 
#SHIB-SP
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT #SHIB-SP
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT #SHIB-SP
#SHIB-SP

Substitua o conteúdo do arquivo /etc/apache2/sites-available/default pelas linhas a seguir:

NameVirtualHost *
<VirtualHost *>
 ServerName $HOSTNAME
 ServerSignature Off
 # Redirecionamento para SSL
 RewriteEngine on
 RewriteCond %{HTTPS} !=on
 RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [R,L]
 DocumentRoot /var/www/
 <Directory /var/www/>
 Options Indexes FollowSymLinks MultiViews
 AllowOverride None
 Order allow,deny
 allow from all
 </Directory>
 ErrorLog /var/log/apache2/error.log
 # Possible values include: debug, info, notice, warn, error, crit,
 # alert, emerg.
 LogLevel info
 CustomLog /var/log/apache2/sp-access-80.log combined
</VirtualHost>

É possível fazer o download do arquivo acima através da seguinte linha de comando:

wget https://svn.rnp.br/repos/CAFe/ubuntu/lucid/shibboleth-sp/default -O /etc/apache2/sites-available/default --no-check-certificate

Substitua o conteúdo do arquivo /etc/apache2/sites-available/shibboleth-sp2.conf pelas linhas a seguir:

<VirtualHost $ENDERECO_IP:443>
 ServerName $HOSTNAME
 ServerSignature Off
 SSLEngine on
 SSLCertificateFile /etc/ssl/certs/$HOSTNAME.crt
 SSLCertificateKeyFile /etc/ssl/private/$HOSTNAME.key
 #ShibURLScheme https
 DocumentRoot /var/www/
 <Directory /var/www/>
 Options -Indexes -FollowSymLinks -MultiViews
 AllowOverride None
 Order deny,allow
 Allow from all
 </Directory>
 <Location /secure>
 AuthType shibboleth
 ShibRequireSession On
 require valid-user
 Order allow,deny
 allow from all
 </Location>
# <Location /moodle/auth/shibboleth>
# AuthType shibboleth
# ShibRequireSession On
# require valid-user
# </Location>
 ErrorLog /var/log/apache2/error.log
 # Possible values include: debug, info, notice, warn, error, crit,
 # alert, emerg.
 LogLevel info
 CustomLog /var/log/apache2/sp-access-443.log combined
</VirtualHost>

É possível fazer o download do arquivo acima através da seguinte linha de comando:

wget https://svn.rnp.br/repos/CAFe/ubuntu/lucid/shibboleth-sp/shibboleth-sp2 -O /etc/apache2/sites-available/shibboleth-sp2.conf --no-check-certificate

Ative o módulo Rewrite, Shibboleth e SSL no Apache através das seguintes linhas de comando:

a2enmod shib2
a2enmod ssl
a2enmod rewrite

Habilite o site bem como faça a exclusão dos arquivos desnecessários. Para tanto, execute as linhas de comando a seguir:

a2ensite shibboleth-sp2
rm -rf /var/www/index.html
rm -rf /etc/shibboleth/IQ-metadata.xml

Substitua o conteúdo do arquivo /etc/shibboleth/shibboleth2.xml pelas linhas a seguir:

<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
 xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
 xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
 logger="syslog.logger" clockSkew="180">
 <OutOfProcess logger="shibd.logger">
 </OutOfProcess>
 <InProcess logger="native.logger">
 <ISAPI normalizeRequest="true" safeHeaderNames="true">
 <Site id="1" name="sp.example.org"/>
 </ISAPI>
 </InProcess>
 <UnixListener address="shibd.sock"/>
 <StorageService type="Memory" id="mem" cleanupInterval="900"/>
 <SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
 <ReplayCache StorageService="mem"/>
 <ArtifactMap artifactTTL="180"/>
 <RequestMapper type="Native">
 <RequestMap applicationId="default">
 <Host name="$HOSTNAME">
 <Path name="secure" authType="shibboleth" requireSession="true"/>
 </Host>
 </RequestMap>
 </RequestMapper>
 <ApplicationDefaults id="default" policyId="default"
 entityID="https://$HOSTNAME/shibboleth-sp2"
 REMOTE_USER="eppn persistent-id targeted-id"
 signing="false" encryption="false">
 <Sessions lifetime="28800" timeout="3600" checkAddress="false"
 handlerURL="/Shibboleth.sso" handlerSSL="false"
 exportLocation="http://localhost/Shibboleth.sso/GetAssertion" exportACL="127.0.0.1"
 idpHistory="false" idpHistoryDays="7">
 <SessionInitiator type="Chaining" Location="/DS" id="DS" relayState="cookie">
 <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
 <SessionInitiator type="Shib1" defaultACSIndex="5"/>
 <SessionInitiator type="SAMLDS" URL="https://ds.chimarrao.cafe.rnp.br/WAYF"/>
 </SessionInitiator>
 <md:AssertionConsumerService Location="/SAML2/POST" index="1"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
 <md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
 <md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
 <md:AssertionConsumerService Location="/SAML2/ECP" index="4"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
 <md:AssertionConsumerService Location="/SAML/POST" index="5"
 Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
 <md:AssertionConsumerService Location="/SAML/Artifact" index="6"
 Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>
 <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
 <LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
 <LogoutInitiator type="Local"/>
 </LogoutInitiator>
 <md:SingleLogoutService Location="/SLO/SOAP"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
 <md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
 <md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
 <md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
 <md:ManageNameIDService Location="/NIM/SOAP"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
 <md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
 <md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
 <md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
 <md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
 Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
 <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
 <Handler type="Status" Location="/Status" acl="127.0.0.1"/>
 <Handler type="Session" Location="/Session" showAttributeValues="false"/>
 </Sessions>
 <Errors supportContact="root@localhost"
 logoLocation="/shibboleth-sp2/logo.jpg"
 styleSheet="/shibboleth-sp2/main.css"/>
 <MetadataProvider type="Chaining">
 <MetadataProvider type="XML" uri="https://ds.chimarrao.cafe.rnp.br/metadata/chimarrao-metadata.xml"
 backingFilePath="/etc/shibboleth/chimarrao-metadata.xml" validate="true" reloadInterval="300">
 </MetadataProvider>
 </MetadataProvider>
 <TrustEngine type="Chaining">
 <TrustEngine type="ExplicitKey"/>
 <TrustEngine type="PKIX"/>
 </TrustEngine>
 <AttributeExtractor type="XML" validate="true" path="attribute-map.xml"/>
 <AttributeResolver type="Query" subjectMatch="true"/>
 <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
 <CredentialResolver type="File" key="/etc/ssl/private/$HOSTNAME.key"
 certificate="/etc/ssl/certs/$HOSTNAME.crt"
 keyName="$HOSTNAME"/>
 </ApplicationDefaults>
 <SecurityPolicies>
 <Policy id="default" validate="false">
 <PolicyRule type="MessageFlow" checkReplay="true" expires="60"/>
 <PolicyRule type="Conditions">
 <PolicyRule type="Audience"/>
 </PolicyRule>
 <PolicyRule type="ClientCertAuth" errorFatal="true"/>
 <PolicyRule type="XMLSigning" errorFatal="true"/>
 <PolicyRule type="SimpleSigning" errorFatal="true"/>
 </Policy>
 </SecurityPolicies>
</SPConfig>

Substitua o conteúdo do arquivo /etc/shibboleth/attribute-map.xml pelas linhas a seguir:

<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id">
 <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name"/>
 </Attribute>
 <Attribute name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" id="persistent-id">
 <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name"/>
 </Attribute>
 <!-- Schema: Core schema attributes-->
 <!-- mail -->
 <Attribute name="urn:mace:dir:attribute-def:mail"
 id="Shib-inetOrgPerson-mail"/>
 <Attribute name="urn:oid:0.9.2342.19200300.100.1.3"
 id="Shib-inetOrgPerson-mail"/>
 <!-- cn -->
 <Attribute name="urn:mace:dir:attribute-def:cn"
 id="Shib-inetOrgPerson-cn"/>
 <Attribute name="urn:oid:2.5.4.3"
 id="Shib-inetOrgPerson-cn"/>
 <!-- sn -->
 <Attribute name="urn:mace:dir:attribute-def:sn"
 id="Shib-inetOrgPerson-sn"/>
 <Attribute name="urn:oid:2.5.4.4"
 id="Shib-inetOrgPerson-sn"/>
 <!-- Schema: brEduPerson -->
 <!-- brEduAffiliationType -->
 <Attribute name="urn:mace:rnp.br:attribute-def:brEduAffiliationType"
 id="Shib-brEduPerson-brEduAffiliationType"/>
 <Attribute name="urn:oid:1.3.6.1.4.1.15996.100.1.1.2.1"
 id="Shib-brEduPerson-brEduAffiliationType"/>
 <!-- Atributos brPersonCPF e brPersonPassport não são habilitados na configuração default -->
 <!-- brPersonCPF -->
 <!--
 <Attribute name="urn:mace:rnp.br:attribute-def:brPersonCPF"
 id="Shib-brPerson-brPersonCPF"/>
 <Attribute name="urn:oid:1.3.6.1.4.1.15996.100.1.1.1.1"
 id="Shib-brPerson-brPersonCPF"/>
 -->
 <!-- brPersonPassport -->
 <!--
 <Attribute name="urn:mace:rnp.br:attribute-def:brPersonPassport"
 id="Shib-brPerson-brPersonPassport"/>
 <Attribute name="urn:oid:1.3.6.1.4.1.15996.100.1.1.1.2"
 id="Shib-brPerson-brPersonPassport"/>
 -->
 <!-- Schema: eduPerson attributes -->
 <!-- eppn - eduPersonPrincipalName -->
 <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
 id="Shib-eduPerson-eduPersonPrincipalName">
 <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
 </Attribute>
 <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
 id="Shib-eduPerson-eduPersonPrincipalName">
 <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
 </Attribute>
 <Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation"
 id="Shib-eduPerson-eduPersonAffiliation"/>
 <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
 id="Shib-eduPerson-eduPersonAffiliation"/>
</Attributes>

Substitua o conteúdo do arquivo /etc/shibboleth/attribute-policy.xml pelas linhas a seguir:

<afp:AttributeFilterPolicyGroup
 xmlns="urn:mace:shibboleth:2.0:afp:mf:basic"
 xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
 xmlns:afp="urn:mace:shibboleth:2.0:afp"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <!-- Shared rule for affiliation values. -->
 <afp:PermitValueRule id="eduPersonAffiliationValues" xsi:type="OR">
 <Rule xsi:type="AttributeValueString" value="faculty"/>
 <Rule xsi:type="AttributeValueString" value="student"/>
 <Rule xsi:type="AttributeValueString" value="staff"/>
 <Rule xsi:type="AttributeValueString" value="alum"/>
 <Rule xsi:type="AttributeValueString" value="member"/>
 <Rule xsi:type="AttributeValueString" value="affiliate"/>
 <Rule xsi:type="AttributeValueString" value="employee"/>
 <Rule xsi:type="AttributeValueString" value="library-walk-in"/>
 </afp:PermitValueRule>
 <!--
 Shared rule for all "scoped" attributes, but you'll have to manually apply it inside
 an AttributeRule for each attribute you want to check.
 -->
 <afp:PermitValueRule id="ScopingRules" xsi:type="AND">
 <Rule xsi:type="NOT">
 <Rule xsi:type="AttributeValueRegex" regex="@"/>
 </Rule>
 <Rule xsi:type="saml:AttributeScopeMatchesShibMDScope" xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml"/>
 </afp:PermitValueRule>
 <afp:AttributeFilterPolicy>
 <!-- This policy is in effect in all cases. -->
 <afp:PolicyRequirementRule xsi:type="ANY"/>
 <!-- Filter out undefined affiliations and ensure only one primary. -->
 <afp:AttributeRule attributeID="affiliation">
 <afp:PermitValueRule xsi:type="AND">
 <RuleReference ref="eduPersonAffiliationValues"/>
 <RuleReference ref="ScopingRules"/>
 </afp:PermitValueRule>
 </afp:AttributeRule>
 <afp:AttributeRule attributeID="unscoped-affiliation">
 <afp:PermitValueRuleReference ref="eduPersonAffiliationValues"/>
 </afp:AttributeRule>
 <afp:AttributeRule attributeID="primary-affiliation">
 <afp:PermitValueRuleReference ref="eduPersonAffiliationValues"/>
 </afp:AttributeRule>
 <afp:AttributeRule attributeID="eppn">
 <afp:PermitValueRuleReference ref="ScopingRules"/>
 </afp:AttributeRule>
 <afp:AttributeRule attributeID="targeted-id">
 <afp:PermitValueRuleReference ref="ScopingRules"/>
 </afp:AttributeRule>
 <!-- Catch-all that passes everything else through unmolested. -->
 <afp:AttributeRule attributeID="*">
 <afp:PermitValueRule xsi:type="ANY"/>
 </afp:AttributeRule>
 </afp:AttributeFilterPolicy>
</afp:AttributeFilterPolicyGroup>