1 of 81

CAFe

Central de Ajuda - CAFe

A Comunidade Acadêmica Federada (CAFe) é um serviço de gestão de identidade que reúne instituições de ensino e pesquisa brasileiras através da integração de suas bases de dados. Isso significa que, por meio de uma conta única (modelo single sign-on), o usuário pode acessar, de onde estiver, os serviços de sua própria instituição e os oferecidos pelas outras organizações que participam da federação.

Essa autenticação elimina a necessidade de múltiplas senhas de acesso e processos de cadastramento, gerando uma relação de confiança. Serviços de ensino a distância, acesso a publicações científicas e atividades de colaboração estão entre os maiores beneficiários das infraestruturas oferecidas por federações.

Qual a sua dúvida?

Acesse o menu lateral e veja os guias do serviço, caso ainda precise de apoio, fale com o nosso Service Desk através do telefone/WhatsApp: 0800 722 0216 ou e-mail: atendimento@rnp.br.

Encontrou algum problema neste portal?

Não encontrou o que precisa? Gostaria de adicionar algo? Por favor, não deixe de nos informar.

Envie um e-mail para o atendimento@rnp.br sinalizando o erro, página ou conteúdo que precisa de alteração.

Sua colaboração é ESSENCIAL para evoluirmos cada vez.

Políticas do Serviço

Apresentação

A Comunidade Acadêmica Federada (CAFe) consiste em uma federação de identidade que reúne instituições de ensino e pesquisa brasileiras.

Através da CAFe é possível que os usuários vinculados aos Membros da Federação, utilizando suas contas institucionais, possam acessar serviços fora do perímetro administrativo da sua instituição. Dessa forma é estabelecida uma rede de confiança que promove a oferta de serviços de forma distribuída, onde cada usuário utiliza as credencias de sua respectiva instituição.

A adesão à CAFe como provedor de identidade permite que a instituição cliente habilite seus usuários a utilizar os serviços federados via web.

Público alvo

Aplica-se a todos os Membros da Federação e ao Operador da Federação.

Credenciamento

O pedido de adesão ao serviço deve ser realizado pela pessoa que será o responsável local pela gestão do serviço na instituição cliente. A indicação deste responsável local deve ser definida através de documento oficial da instituição designando-o como tal.

Requisitos

A instituição cliente deve ter à disposição os recursos técnicos e humanos necessários para adesão à CAFe e subseqüente atendimento de seus usuários. O dimensionamento destes recursos deve ser feito pela própria instituição em acordo com o tamanho de sua infraestrutura e banco de dados de usuários.

Além disso, a instituição deve documentar seu processo de emissão de credenciais para os usuários aptos a acessar os serviços ou recursos da CAFe através do preenchimento de um formulário específico durante o processo de adesão. Este formulário será publicado no site da RNP, com acesso público.

Considerações Finais

Os bancos de dados com os registros de identidade são mantidos exclusivamente pelas instituições clientes não sendo, portanto, responsabilidade da CAFe prover atualização dos metadados, auditoria ou cópias de segurança dos mesmos.

Contato

As dúvidas relacionadas a esta política de uso poderão ser enviadas para o Servide Desk no endereço atendimento@rnp.br

Termo de privacidade do Provedor de Serviço (SP)

Este termo de privacidade possui o objetivo de documentar os requisitos mínimos de informação sobre proteção aos dados pessoais e garantia de privacidade aos usuários dos serviços providos através da CAFe que devem ser assumidos pela Instituição membro da Federação.

Este documento deve ser encaminhado à RNP como parte dos requisitos necessários para aprovação da Instituição como membro da Federação CAFe.

Segue abaixo a documentação completa para maiores informações:

CAFe Service Provider (SP) Privacy Agreement

This Privacy Term has the objective of documenting the minimum information requirements on the protection of personal data and guarantee of privacy to users of the services provided through CAFe that must be assumed by the Institution member of the Federation.

This document must be forwarded to RNP as part of the requirements necessary for approval of the Institution as a member of the CAFe Federation.

The following document can be downloaded and contains more information about the privacy agreement:

Política da Comunidade Acadêmica Federada (CAFe)

O documento a seguir contém informações sobre a Política da Comunidade Acadêmica Federada (CAFe):

Verificação de Inicidentes

Para agilizar o seu atendimento garanta que todos os passos serão seguidos e o e-mail enviado ao suporte possuí todas as evidências listadas nessa página.

Os procedimentos listados abaixo tem o objetivo de validar se os pré-requisitos de uso do serviço estão corretos e coletar alguns logs do seu IdP, lembrando que só podemos prosseguir com o atendimento se todos os pré-requisitos estiverem sendo atendidos.

Passo 1. Validar Pré requisitos

Por gentileza, valide de todos os pré-requisitos do serviço listados abaixo estão sendo atendidos:

1. Máquina para IDP deve ter IP válido e não pode estar atrás de NAT (Em caso de NAT a instituição deverá garantir que a comunicação está conforme o desejado);

2. DNS direto e reverso devem estar configurados;

3. Portas 80 e 443 liberadas no firewall local (IdP) e no institucional;

4. É necessário validar com o administrador do IDP, que nada foi atualizado ou executado nesta máquina ou na infra da instituição, que tenha causado a possível falha;

5. Verificar se o tomcat está com permissão de escrita nas pastas /opt/shibboleth-idp/metadata e /opt/shibboleth-idp/logs com o comando ls -lha;

6. Não ter alterado o usuário de leitura da base de usuários (bind);

cn - Nome do Usuário sn - Sobrenome do Usuário mail - Email institucional ou pessoal do usuário eduPerson-eduPersonPrincipalName -> Nome identificador do usuário na base brEduAffiliationType - O vinculo do usuário com a instituição

Os atributos cn, sn e mail são obrigatórios.

Após a validação, prossiga de acordo o resultado:

Resultado 1: Se os requisitos estiverem sendo atendidos, prossiga para o Passo 2.

Resultado 2: Se os requisitos NÃO estão sendo atendidos, realize os ajustes necessários teste o serviço e caso o problema ainda persista prossiga para o Passo 2.

Passo 2. Coleta de Evidências

Para analisarmos as configurações do seu IdP precisaremos de alguns arquivos, por gentileza, execute os passos abaixo:

2.2 Realize o download do script e dê permissão de administrador através dos comandos abaixo:

Para Ubuntu 16.04 LTS:

Parte 1:
wget --no-check-certificate https://svn.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/cafe-validador-template.sh -O /tmp/cafe-validador-template.sh --no-check-certificate
 
Parte 2:
chmod +x /tmp/cafe-validador-template.sh
 
Parte 3:
Execute o script através do caminho: /tmp/cafe-validador-template.sh

Para Ubuntu 14.04 LTS:

Parte 1:
wget --no-check-certificate https://svn.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/cafe-validador-template.sh -O /tmp/cafe-validador-template.sh --no-check-certificate
 
Parte 2:
chmod +x /tmp/cafe-validador-template.sh
 
Parte 3:
Execute o script através do caminho: /tmp/cafe-validador-template.sh

2.4 Colete o log gerado pelo script acima, ele pode ser encontrado através do caminho: /root/cafe-homolog-shib3.log

2.5 Colete também o log do IDP, disponibilizado em: /opt/shibboleth-idp/logs/idp-process.log

Passo 3. Enviando as Informações

Após a confirmação dos pré-requisitos e coleta dos logs, por gentileza, envie todas as informações para o endereço de e-mail atendimento@rnp.br ou em resposta ao e-mail que foi solicitado as informações.

Caso já exista um chamado basta responder o último e-mail que a resposta será anexada automaticamente a ele, o importante é não alterar o campo "Assunto".

Ressaltamos que o e-mail deve conter as seguintes informações:

Confirmação se a instituição está cumprindo todos os pré-requisitos (Passo 1)
Log de homologação e IDP (Passo 2.4 e 2.5)

Lista de Clientes

Lista de Clientes que concluíram o processo de adesão CAFe

Atributos da CAFe

No documento abaixo descrevemos um esquema LDAP a ser utilizado pelos clientes dos serviços de Gestão de Identidade da Federação CAFe e para os demais serviços que podem vir a exigir os mesmos dados cadastrais.

Para maiores informações, segue abaixo o documento de Especificação de uso dos atributos CAFe:

Perguntas Frequentes

FAQ - CAFe

Abaixo você encontra algumas perguntas frequentes sobre o serviço CAFe (Comunidade Acadêmiica Federada), mas caso ainda tenha algum problema ou dúvida, fale com o nosso Service Desk.

FAQ - Pentaho

Abaixo você encontra algumas perguntas frequentes sobre o serviço Pentaho, mas caso ainda tenha algum problema ou dúvida, fale com o nosso Service Desk.

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.

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.

Pentaho

Pagina destinada a informações pertinentes ao Pentaho

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.

Procedimentos de Instalação

Os procedimentos a seguir são para o auxílio na instalação e configuração do Pentaho.

Procedimento de importação do template de Máquina Virtual (PDI 9.0)

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

Importe o arquivo transferido para seu Hypervisor.
Ligue o servidor virtual recém importado, segue as informações de Login na VM:

user : cafe
senha: Fj2&Ofak

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:

/opt/pentaho-server/start-pentaho.sh

/opt/pentaho-server/stop-pentaho.sh

/opt/pentaho-server/data/lib/

/opt/pentaho-server/tomcat/lib/

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.

wget "https://svn.cafe.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/pdi-pentaho/mysql-connector-java-5.1.45-bin.jar"

cp mysql-connector-java-5.1.45-bin.jar /opt/pentaho-server/data/lib/

cp mysql-connector-java-5.1.45-bin.jar /opt/pentaho-server/tomcat/lib/

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

/etc/init.d/mysql status 

Parar Mysql: /etc/init.d/mysql stop
Iniciar Mysql: /etc/init.d/mysql start 

User Mysql: administrador
Senha: Pdic@f3*

Login: admin
Senha: password

9. Verificar se o login ocorreu com sucesso.

Instalação Cliente PDI - Versão 9

Estes procedimentos devem ser executados em uma máquina diferente do servidor Pentaho, necessário uma máquina com interface gráfica, pode ser a máquina local do usuário.

Instalação Cliente PDI no Windows:

Descompactar no diretório de preferência.
Setar variável JAVA_HOME e PENTAHO_JAVA_HOME com caminhos do JAVA JDK
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
Executar o arquivo spoon.bat para iniciar o cliente PDI.

Instalação Cliente PDI no Linux:

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

Baixar também 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: /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
- FINISH
Clique em Connect Now

Digite usuário, senha e clique em connect:

User: admin
Senha: password

OpenLDAP

Página dedicada para procedimentos com OpenLDAP com schema BrEduPerson, EduPerson e Schac.

IDP CAFe

Manual de Usuário

Coleta/Verificação de Atributos

RPilot (IDP)

Service Provider (SP)

Requisitos de Uso

Página destinada para esclarecimento de requisitos necessários para implementação do serviço de Provedor de Identidade (IDP) em uma instituição parceira ou cliente da RNP.

Requisitos para um Provedor de Identidade

Para garantir uma implementação bem-sucedida de um serviço de Provedor de Identidade (IDP) em um ambiente de virtualização, é crucial observar os seguintes requisitos:

1. Requisitos de Infraestrutura:

Hardware: A infraestrutura deve possuir servidores com capacidade suficiente de CPU, memória RAM e armazenamento para suportar a carga esperada do Provedor de Identidade. Para a versão 5 do Shibboleth IDP + Pacote MFA recomendamos o mínimo abaixo:

4vCPUs, 8Gb de RAM com 60Gb de espaço em disco

Virtualização: O ambiente de virtualização (como VMware, ProxMox, KVM, etc.) deve estar configurado e otimizado para alta disponibilidade e desempenho.
Ambientes em Nuvem: Alternativamente, considere a utilização de ambientes em nuvem, como AWS, Azure, Google Cloud, entre outros, para alavancar a escalabilidade, flexibilidade e a infraestrutura gerenciada que essas plataformas oferecem. Atenção aos requisitos de hardware dessas instâncias.
Rede: Conectividade de rede confiável e segura é essencial para garantir a comunicação contínua entre o Provedor de Identidade e os serviços consumidores. Necessário um IP público para as chamadas de conexão com o IDP e o mesmo deve responder em portas 80 e 443 para a Internet.

2. Requisitos de Software:

Sistema Operacional: O sistema operacional das máquinas virtuais deve ser o Ubuntu 24.04 LTS. Lembrando que essa versão do SO é a versão recomenda para todo o suporte do processode instalação e configuração do IDP junto a RNP. Qualquer uso de outro SO pode ser aplicado mas o cliente ficará sobre a responsabilidade do inicio ao fim do processo de instalação do IDP, a equipe de suporte GiD e Operação da CAFe poderá apoiar apenas com os melhores esforços sem garantia de funcionamento. Sem suporte para o pacote MFA em outro SO.
Dependências de Software: Instale todos os pacotes de software e dependências necessários conforme especificado pela RNP no Provedor de Identidade. O MFA é um pacote fornecido a parte do IDP que pode ser implementado com todo apoio e suporte da equipe de GiD e Operação da CAFe.
Dependências do MFA: Para o pacote do MFA será necessário a configuração de recursos de envio

3. Requisitos de Segurança:

Certificados SSL/TLS: Configure certificados SSL/TLS válidos para garantir a segurança das comunicações entre o Provedor de Identidade e os consumidores de serviços. Configuração de certificados para o IDP já incluso no processo de instalação via RPilot. Certificados Web com domínio da instituição devem ser configurados pelo cliente.
Políticas de Acesso: Defina políticas de acesso rigorosas para proteger os recursos do Provedor de Identidade e limitar o acesso apenas a usuários autorizados.

4. Pré-Requisitos de Configuração:

Base de Usuários: Prepare e configure uma base de usuários para armazenar informações relacionadas a autenticação do Provedor de Identidade. Damos suporte para cliente com base OpenLDAP e schemas BrPerson, BrEduPerson, Schac e InetOrgPerson, também damos suporte para bases MS Active Directory e temos uma solução especializada para clientes que possuem bases relacionais, o nosso Pentaho PID.
Configuração de conta e acesso ao serviço RPilot: Etapa importante onde o responsável técnico da instituição ou administrador técnico deve solicitar ao nosso ServiceDesk GiD a criação de conta e da instituição para o primeiro acesso a nossa ferramenta de automação e instalação do IDP CAFe RPilot. As contas a serem criadas serão de perfil Administrador da Instituição e ou Operador da Instituição.

Requisitos para Configuração de MFA e SMTP:

Conta de e-mail: Será preciso uma conta de e-mail para a aplicação MFA onde esta conta deve estar habilitada para o envio de e-mail para os usuários do IDP, bem como e-mails de aviso para os administradores.
Essa referida conta poderá estar em um servidor de e-mail próprio, ou poderá ser de um provedor contratado.
Também será preciso o usuário e senha para envio de e-mail, assim como endereço e porta do servidor de e-mail.
Configuração de MFA: Configure o recurso de Autenticação Multifator (MFA) no Provedor de Identidade para aumentar a segurança dos acessos. Isso pode incluir a integração com aplicativos de autenticação, OTP ou envio de códigos por email.
Testes de MFA: Realize testes para garantir que o MFA está funcionando corretamente e que os emails de verificação estão sendo enviados e recebidos sem problemas.

6. Testes e Validação:

Testes de Integração: Realize testes de integração para garantir que o Provedor de Identidade esteja se comunicando corretamente com os serviços consumidores. Fornecemos toda uma homologação de instalação desde o IDP, MFA e Pentaho Server.
Testes de Desempenho: Execute testes de desempenho para assegurar que o Provedor de Identidade pode lidar com a carga esperada sem problemas.

7. Documentação e Suporte:

Documentação: Mantenha uma documentação detalhada de todo o processo de instalação, configuração e testes para referência futura.
Suporte Técnico: Esteja preparado para acionar o suporte técnico do fornecedor, caso encontre problemas durante a implementação. Canal de contato atendimento@rnp.br

Seguindo esses requisitos, você estará bem preparado para implementar com sucesso um serviço de Provedor de Identidade em seu ambiente de virtualização, seja ele local ou na nuvem.

Procedimentos de criação da VM EID PDI

Apenas para instituições que não utilizarão a VM

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.

apt-get updateapt-get upgrade

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

apt-get install openjdk-8-jdk

3.3. Instalação do unzip.

apt-get install unzip

3.4 Instalação do Pentaho 9.0

mkdir -p /opt
cd /opt
wget "http://svn.cafe.rnp.br/arquivos/pentaho-server-ce-9.0.0.0-423.zip" pentaho-server-ce-9.0.0.0-423.zip
unzip pentaho-server-ce-9.0.0.0-423.zip
export PENTAHO_JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

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

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

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

cd /opt/pentaho-server/pentaho-solutions/system/
wget "https://svn.cafe.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/pdi-pentaho/saiku.zip"
unzip saiku.zip
rm saiku.zip

3.7 Iniciar o serviço do Pentaho BI Server

/opt/pentaho-server/start-pentaho.sh

3.8 Instalação do Pentaho Data Integration

mkdir -p /opt/pentaho/biclient/
cd /opt/pentaho/biclient/
wget "https://svn.cafe.rnp.br/arquivos/pdi-ce-9.0.0.0-423.zip"
unzip pdi-ce-9.0.0.0-423.zip
wget "https://svn.cafe.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/pdi-pentaho/mysql-connector-java-5.1.45-bin.jar"
cp mysql-connector-java-5.1.45-bin.jar /opt/pentaho/biclient/data-integration/lib

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

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

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:

cd /opt

wget https://svn.cafe.rnp.br/repos/CAFe/Pentaho/jobs/backup_eid_2020-09-14_full.zip

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

/opt/pentaho-server/import-export.sh --restore --url=http://localhost:8080/pentaho --username=admin --password=password --file-path=/opt/eid/backup_eid_2020-09-14_full.zip --overwrite=true --logfile=/opt/eid/logfile.log

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:

/opt/pentaho-server/import-export.sh --backup --url=http://localhost:8080/pentaho --username=admin --password=password --file-path=/opt/eid/backup_eid_full.zip --logfile=/opt/eid/logfile.log

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

Tutorial Básico Apache DS

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:

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.

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.

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.

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.

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.

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

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

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

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

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.

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.

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.

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.

Concluso o preenchimento dos atributos obrigatórios clique em FINISH.
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:

Clique com o botão direito do mouse sobre a entrada e clique na opção Rename Entry.
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.

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:

Clique com o botão direito do mouse sobre a entrada e clique na opção Delete Entry.
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.

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

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.

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

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.

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

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.
Concluso este roteiro, o valor do atributo estará editado.

Descrição do atributo

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

Clique com o botão direito do mouse sobre o atributo e clique na opção Delete Value.
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.

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.

Clique sobre o menu FILE > NEW
Expanda o item LDAP BROWSER, selecione o item LDIF FILE e clique em FINISH conforme ilustrado na Figura 20.

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

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.

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.

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.

Critérios de consulta ao OpenLDAP para Shibboleth

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.

Importante !

Antes de começar é recomendado que seja feito o backup do arquivo "ldap.properties" em seu IdP. O arquivo fica no caminho: /opt/shibboleth-idp/conf

Considerar em todo texto abaixo que, OpenLDAP é a referência usada para identificar a base de diretório usada para a consulta do Shibboleth em seu IdP. Toda essa configuração foi homologada em um ambiente com os seguintes requisitos: Idp → Ubuntu 20.04, Shibboleth 4.2.1, Apache2 e Jetty9

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

Na imagem acima temos o arquivo "ldap.properties" no padrão do template, no exemplo acima a autenticação do IdP está ocorrendo pelo atributo "uid" configurado para OpenLDAP. Lembrando que cada insituição pode personalizar qual atributo deseja que seja usado para a autenticação, mas os recomendados são: uid, sAMAccountName e mail. O atributo sAMAccountName é usado na configuração com Active Directory(AD).

Agora iremos alterar o valor da variável usada pelo shibboleth (idp.authn.LDAP.userFilter), para executar o critério de consulta no OpenLDAP. Linha 25 do bloco de código abaixo

# 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

Na imagem acima fiz a alteração do valor na variável (idp.authn.LDAP.userFilter). Usei o operador lógico & para adicionar mais um critério de consulta na base e mantive a primeira regra e em seguida adicionei mais um regra para a validação da consulta, no exemplo usei o atributo memberof, esse atributo permite que o Shibboleth agora apenas consulte as contas que estiverem como membros deste grupo no OpenLDAP → (&(uid={user})(memberof=cn=GRP_SRV_CAFE,ou=GRUPOS,dc=homolog,dc=rnp)). O valor deste atributo precisa estar com o distinguished name DN do grupo criado que no meu caso foi cn=GRP_SRV_CAFE,ou=GRUPOS,dc=homolog,dc=rnp desta forma é possível estabelecer mais criteriosamente quais contas da sua base de diretórios tem permissão para usarem os serviços federados.

Existem outras possibilidades de serem criados tipos de critérios para uma autenticação, seguindo os passos anteriores eu abaixo darei mais um exemplo de como filtrar a autenticação do usuário, liberando apenas os que possuem uid e mail.

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

Também podemos usar o operador lógico OU do xml ( | ). No próximo exemplo o Shibboleth irá autenticar aquelas contas que possuem o atributo UID ou o mail

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

Ajustando Atributos CPF e Data de Nascimento para ICPEdu

Informe

Antes de iniciar qualquer ação deste roteiro primeiro verificar a versão do seu servidor Ubuntu.

Este roteiro so irá funcionar para aquelas instituições que já possuem a versão da VM IdP a partir da versão 20.04 do sistema operacional Ubuntu, com a versão 4.2.x do Shibboleth caso a sua instituição não esteja dentro deste requisito não realizar este operação e entrar em contato com o ServiceDesk da RNP, pois será necessário realizar a atualização do seu IdP.

Guia passo a passo para AD:

Antes de começar !

Como a microsoft AD não implementa por padrão os atributos "schaDateOfBirth" e o "brPersonCPF" eles não são mapeados, com isso será necessário o uso de atributos que estejam vagos em seu AD para que os mesmos sejam mapeados para o Shibboleth em seu IdP. Nesse procedimento foi usado os seguintes atributos employeeNumber e employeeType

Nesse roteiro usamos o atributo employeeNumber para valores da Data de Nascimento e o atributo employeeType para valores do CPF

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.

    <!-- CAFe - brPersonCPF -->
    <AttributeDefinition id="brPersonCPF" xsi:type="Simple">
        <InputDataConnector ref="dcLDAP" attributeNames="brPersonCPF" />
    </AttributeDefinition>

    <!-- CAFe - schacDateOfBirth -->
    <AttributeDefinition id="schacDateOfBirth" xsi:type="Simple">
        <InputDataConnector ref="dcLDAP" attributeNames="schacDateOfBirth" />
    </AttributeDefinition>

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"

    <!-- CAFe - brPersonCPF -->
    <AttributeDefinition id="brPersonCPF" xsi:type="Simple">
        <InputDataConnector ref="dcLDAP" attributeNames="employeeType" />
    </AttributeDefinition>

    <!-- CAFe - schacDateOfBirth -->
    <AttributeDefinition id="schacDateOfBirth" xsi:type="Simple">
        <InputDataConnector ref="dcLDAP" attributeNames="employeeNumber" />
    </AttributeDefinition>

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.

    <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->

    <DataConnector id="dcLDAP" xsi:type="LDAPDirectory" ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}" baseDN="%{idp.attribute.resolver.LDAP.baseDN}" principal="%{idp.attribute.resolver.LDAP.bindDN}" principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}" trustFile="%{idp.attribute.resolver.LDAP.trustCertificates}" useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}" noResultIsError="%{idp.attribute.resolver.LDAP.noResultsIsError:false}" multipleResultsIsError="%{idp.attribute.resolver.LDAP.multipleResultsIsError:true}">
        <FilterTemplate>
            <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
        </FilterTemplate>
        <ReturnAttributes>%{idp.authn.LDAP.returnAttributes} mail cn givenName sn brPersonCPF schacDateOfBirth</ReturnAttributes>
    </DataConnector>

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:

systemctl restart jetty9.service

Informe

A inclusão do bloco de código deve estar contida dentro das tags "<resolver:AttributeResolver" e "</resolver:AttributeResolver>" que são as declarações de inicio e fim do arquivo attribute-filter.xml.

No exemplo citado estamos liberando os atributos CPF e Data de Nascimento apenas para o SP de teste da RNP e para os SPs dos serviços P1 e Pessoal do ICPEDU. Lembrando que os atributos devem existir no serviço de diretório da institução em forma de atributo do usuário.

Procedimento de instalação

Procedimento de instalação do MFA na CAFe versão 4.2.1 ou superiror

Quando a instalação é iniciada, uma série de informações é solicitada. Assim, ANTES de iniciar o processo de instalação, tenha em mãos as seguintes informações:

Digite o FQDN da máquina: se trata do FQDN do seu servidor IDP. Exemplo: “idp.instituicao.br”
Digite o texto a ser exibido para o usuário de forma que ele saiba o que deve preencher para se autenticar (ex.: Seu email @rnp.br): cada instituição utiliza uma informação diferente para se autenticar, seja o número de matrícula, um email, etc. Neste campo você personaliza o texto que deve ser exibido ao usuário na tela de usuário e senha.
Link de recuperação de senha (ex.: https://urlpaginarecuperacaodesenha.instituicao.br): informação opcional. Recomendamos fortemente que preencha esta informação caso tenha uma url que os usuários possam acessar para recuperar a senha.
Você está utilizando um ambiente de alta disponibilidade: esta informação se aplica para as instituições que possuem mais de um servidor IDP e que estes servidores operem de forma concomitante, ou seja, em que os servidores estejam ativos ao mesmo tempo. Caso este seja esta a sua situação, recomendamos que entre em contato com a equipe da CAFe para realizar uma instalação monitorada, uma vez que a instalação envolve alguns passos adicionais e pontos de atenção adicionais. Caso seja um ambiente de alta disponibilidade, será perguntado as seguintes informações adicionais:

Se o servidor que está sendo instalado é o primário/principal ou se é o servidor secundário: se sua instituição tiver uma instalação com redundância, um dos servidores servidores precisará ser definido como servidor principal (primário). Todos os demais servidores serão considerados como secundários. Assim um ambiente com redundância terá um servidor principal e um ou mais servidores secundários. Recomendamos a leitura da seção que detalha pontos importantes associados a ambientes com redundância.

Digite o endereço IP do servidor primário: deve ser o IP do servidor definido como servidor principal
Digite o endereço IP do servidor secundário: deve ser o IP do servidor secundário. ATENÇÃO, só instale o servidor secundário caso o servidor primário já tenha sido instalado.
Digite o FQDN alternativo do servidor primário: este FQDN é utilizado para o servidor secundário se comunicar com o servidor primário.
Digite a senha para sincronização da base: pergunta realizada somente na instalação do servidor secundário. Necessário para o servidor secundário se conectar na base de dados do servidor primário. No detalhamento da instalação de ambiente redundante é explicado onde a informação da senha é obtida.
Digite o nome do usuário administrador (ex.: Joao da Silva): Será criada uma conta inicial de administrador para o usuário em questão: quando o painel de segurança é instalado, é cadastrado automaticamente um usuário inicial que receberá permissão de administrador. Será este usuário que irá atribuir permissões de administrador e operador a outros usuários. Certifique que todos os dados do usuário administrador inicial foi cadastrado corretamente
Digite o e-mail do usuário administrador (deve ser o mesmo cadastrado no IDP): associado ao cadastro do administrador. Deve ser o MESMO e-mail que o usuário tem cadastrado no IDP da instituição.

O valor que deve ser copiado é somente “73637a38dea854e281cda9f6f00af507”.

Digite o endereço do servidor SMTP: se trata dos dados de acesso necessários para que o painel de segurança possa enviar e-mails. Preencha aqui o endereço do servidor SMTP. Exemplo: smtp.instituicao.br.
Digite a porta do servidor SMTP: porta do servidor SMTP. Exemplo: 587.
Digite o username do usuario SMTP: conta a ser utilizada para se autenticar no servidor SMTP.
Digite a senha do usuario SMTP: senha para autenticação na conta SMTP.
Digite o Nome amigavel a ser exibido para identificar quem envia os e-mails: na ser exibido para identificar quem envia os e-mails (exemplo: Nome da Instituição).
Digite o E-mail do originador: E-mail do originador. Se trata do e-mail que será exibido para o usuário como originador do e-mail (exemplo: no-reply@instituticao.br)

Somente após ter as informações indicadas em mãos, inicie os passos de instalação indicados na próxima seção.

Instalação

Toda a instalação é realizada através de um script. Este script faz diversos procedimentos, sendo:

Download dos arquivos necessários para a instalação;
Cópias dos arquivos baixados para os locais de instalação;
Geração de chaves de criptografia adicionais necessários;
Instalação da base de dados;
Solicita as informações necessárias para a instalação (atenção à seção anterior);
Realiza a instalação.

ATENCÃO

Antes de iniciar a instalação certifique-se que o servidor está acessando adequadamente a Internet e que não terá nenhuma regra de firewall impedindo que o mesmo baixe o pacote de instalação associados. O script deve ser executado com um usuário com permissões de ROOT.

Execução do procedimento

Baixe o script de instalação na pasta /tmp
Dê permissão de execução para o script
Execute o script como ROOT

cd /tmp/
wget https://svn.cafe.rnp.br/repos/CAFe/mfa/mfa-install-shib4-v2.sh
chmod +x mfa-install-shib4-v2.sh
./mfa-install-shib4-v2.sh

Após finalizar a instalação, alguns passos manuais são necessários serem executados.

Executando o Script de instalação

A seguir são detalhadas as perguntas apresentadas pelo script. Para que possa digitar as respostas é necessário saber as informações indicadas na seção 7.

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

ATENÇÃO: se você cancelar a execução do script APÓS ter respondido todas as perguntas, a instalação pode ficar em um estado inconsistente e será necessário recuperar o backup do servidor.

Etapas do Script

Pergunta 1.

Inicialmente é solicitado o FQDN do servidor. Deve ser o FQDN configurado no DNS associado ao servidor. Em negrito é apresentada a pergunta apresentada pelo script. Em itálico é apresentado um exemplo hipotético de resposta considerando que o FDQN do servidor é “serveridp.instituicao.br”.

Digite o FQDN da maquina (exemplo: idp.instituicao.br): serveridp.instituicao.br

O valor de hostname realmente é "serveridp.intituicao.br"? (s/n) s

Pergunta 2.

Na sequência será solicitada a informação que deve ser exibida na tela de login do IDP para que o usuário se identifique. A figura a seguir mostra um exemplo de qual texto se refere. Por exemplo, se o login do usuário é o número de matrícula, digite “Seu número de matricula”

Digite o texto a ser exibido para o usuário de forma que ele saiba o que deve preencher para se autenticar (ex.: Seu email @rnp.br): Seu número de matrícula

O valor de hostname realmente é "Seu número de matrícula"? (s/n) s

Pergunta 3.

A próxima pergunta solicitada pelo script será a url que o usuário será redirecionado caso clique no link “Recuperar senha” na figura apresentada anteriormente. Caso não tenha o link, basta digitar 2. O exemplo a seguir ilustra um caso hipotético onde a url é “https://recuperasenha.instituicao”.

Link de recuperação de senha (ex.: https://urlpaginarecuperacaodesenha.instituicao.br):

1 - SIM

2 - NAO

A instituicao possui uma pagina para recuperacao de senha? 1

O valor de SIM/NAO realmente é "1"? (s/n) s

Digite a url para a pagina de recuperacao de senha (ex.: https://urlpaginarecuperacaodesenha.instituicao.br): https://recuperasenha.instituicao.br

O valor de URL página recuperacao de senha realmente é "https://recuperasenha.instituicao.br"? (s/n) s

Pergunta 4.

A pergunta apresentada na sequência é para saber se seu ambiente é redundante ou não. A resposta apresentada no exemplo a seguir considera que NÃO é um ambiente redundante.

Você está utilizando um ambiente de alta disponibilidade:

1 - Sim

2 - Não

Escolha uma das opções: 2

O valor de uso de ambiente de alta disponibilidade (caso haverá mais de um servidor) realmente é "2"? (s/n) s

Não é ambiente de alta disponibilidade

Pergunta 5.

A pergunta 5 se refere ao nome do usuário a ser cadastrado como administrador do painel de segurança da instituição. O exemplo a seguir considera que o nome do administrador é “José da Silva”

Digite o nome do usuário administrador (ex.: Joao da Silva). Será criada uma conta inicial de admin para o usuário em questão: José da Silva

O valor de nome do contato tecnico realmente é "José da Silva"? (s/n) s

Pergunta 6.

Nesta pergunta você deve preencher o e-mail da pessoa cadastrada na pergunta 5 (e-mail do usuário que será o adminsitrador). Atenção que deve ser o mesmo e-mail que o usuário tem cadastrado no IDP.

Digite o e-mail do usuario administrador (deve ser o mesmo cadastrado no IDP): jose@instituicao.br

O valor de e-mail realmente é "jose@instituicao.br"? (s/n) s

Pergunta 7.

Nesta pergunta você deve digitar o EPPN do usuário a ser cadastrado como administrador. Em caso de dúvida, consulte as instruções apresentadas na seção 7.

Digite o EPPN do USUÁRIO administrador (somente o valor antes do @). Exemplo, se valor de eppn for abc@instituicao.br, deve ser cadastrado somente abc: 73637a38dea854e281cda9f6f00af507

O valor de eppn realmente é "73637a38dea854e281cda9f6f00af507"? (s/n) s

Pergunta 8.

Esta pergunta e as próximas referem-se ao servidor SMTP da instituição para envio de e-mails. Em caso de dúvida, consulte as instruções apresentadas na seção 7.

Digite o endereço do servidor smtp (exemplo: smtp.instituicao.br): smtp.instituicao.br

O valor do servidor SMTP realmente é "smtp.instituicao.br"? (s/n) s

Pergunta 9.

Nesta pergunta você deve digitar a porta do servidor SMTP da instituição para envio de e-mails.

Digite a porta do servidor SMTP (exemplo: 587): 587

O valor da porta do servidor SMTP realmente é "587"? (s/n) s

Pergunta 10.

Nesta pergunta você deve digitar o username do usuário do servidor SMTP da instituição. Em caso de dúvida, consulte as instruções apresentadas na seção 7.

Digite o username do usuario SMTP (exemplo: usernamesmtp): usernamesmtp

O valor do username do usuario do servidor SMTP realmente é "usernamesmtp"? (s/n) s

Pergunta 11.

Nesta pergunta você deve digitar a senha do usuário do servidor SMTP da instituição.

Digite a senha do usuario SMTP (exemplo: passwordsmtp): passwordsmtp

O valor da senha do usuario do servidor SMTP realmente é "passwordsmtp"? (s/n) s

Pergunta 12.

Nesta pergunta você deve digitar um nome amigavel para identificar quem envia o e-mail. Em caso de dúvida, consulte as instruções apresentadas na seção 7.

Digite o Nome amigavel a ser exibido para identificar quem envia os e-mails (exemplo: Nome da Instituicao): Nome da Insituicao

O valor do nome amigavel a ser exibido para identificar quem envia o e-mail realmente é "Nome da Instituicao"? (s/n) s

Pergunta 13.

Nesta pergunta você deve digitar o e-mail do originador que será indicado como remetente no envio do e-mail.

Digite o E-mail do originador (exemplo: no-reply@instituticao.br): no-reply@instituicao.br

O valor do E-mail do originador realmente é "no-reply@instituicao.br"? (s/n) s

Pergunta 14.

Nesta pergunta você deve digitar um nome a ser inserido no rodapé do e-mail enviado.

Digite o nome a ser colocado no rodape do e-mail. Recomenda-se colocar o nome da instituicao (exemplo: Nome Instituicao): Nome Instituicao

O valor do nome a ser colocado no rodape do e-mail realmente é "Nome Instituicao"? (s/n) s

Após respondidas as perguntas, o script irá iniciar efetivamente o processo de instalação e configuração do MFA. Aguarde a execução do script. Ao final da execução, acesse seu IDP para validar a instalação.

Ambiente com Redundância

Informações Importantes

Em instalações com redundância, existem alguns passos manuais adicionais que devem ser executados. Verifique atentamente cada um dos pontos apresentados.

Uma questão importante em relação a ambientes redundantes, é que a instalação é realizada de forma diferente nos servidores secundários. Ou seja, NÃO se deve clonar a instalação do servidor principal e achar que automaticamente o servidor clonado irá operar adequadamente como secundário.

Isso acontece porque os dados precisam estar sincronizados entre as bases de dados. Para garantir a sincronização de forma segura, evitando qualquer inconsistência nos dados, somente a base de dados do servidor principal opera em modo escrita.

A Figura apresentada ilustra o cenário. A base de dados no servidor secundário opera em modo somente leitura. Toda vez que o usuário está no servidor secundário e realiza alguma operação que envolve escrita na base de dados, o servidor secundário se comunica com o primário e pede para o primário realizar a escrita. Tudo que é escrito/alterado no banco de dados do servidor principal é então replicado para o banco de dados secundário.

Executando

O processo inicial de instalação do ambiente redundante é idêntico a uma instalação simples (ver seção 8.3). A diferença começa a partir da pergunta 4. Nela deve ser indicado que se trata de ambiente redundante e as perguntas seguintes irão ser distintas conforme o servidor sendo instalado (se é o servidor primário ou secundário)

Pergunta 4.

A pergunta apresentada na sequência é para saber se seu ambiente é redundante ou não. A resposta apresentada no exemplo a seguir considera que SIM, é um ambiente redundante.

Você está utilizando um ambiente de alta disponibilidade:

1 - Sim

2 - Não

Escolha uma das opções: 2

O valor de uso de ambiente de alta disponibilidade (caso haverá mais de um servidor) realmente é "1"? (s/n) s

Após a pergunta 4, as perguntas serão distintas conforme o servidor.

Conforme ilustração, dados adicionais a respeito dos servidores são solicitados no caso de ambientes redundantes. E para o servidor secundário, é necessário preencher dados específicos necessários para a replicação da base. mais detalhes a seguir.

Configuração Servidor Primário

Siga os passos a seguir se for a instalação do servidor primário.

Pergunta associada a servidores. Deve ser indicado qual servidor se trata e na sequência os dados dos servidores primário e secundário.

No que se refere à configuração do seu ambiente, esse é o servidor:

1 - Primário/Principal

2 - Secundário

Escolha uma das opções: 1

O valor de Servidor que está sendo configurado realmente é "1"? (s/n) s

Digite o endereco IP do servidor primário: 11.11.11.11

O valor de IP realmente é "11.11.11.11"? (s/n) s

Digite o FQDN alternativo para o servidor primário (exemplo: idpprimario.instituicao.br): primario.instituicao.br

O valor de hostname realmente é "primario.instituicao.br"? (s/n) s

Digite o endereco IP do servidor secundário: 22.22.22.22

O valor de IP realmente é "22.22.22.22"? (s/n) s

Na sequência, conforme a figura apresentada, devem ser respondidas as perguntas 5 a 7 já apresentadas anteriormente

Configuração Servidor Secundário

Siga os passos a seguir se for a instalação do servidor secundário.

ATENÇÃO, o primário deve ter sido instalado ANTES de iniciar a instalação do secundário.

Pergunta associada a servidores. Deve ser indicado qual servidor se trata e na sequência os dados dos servidores primário e secundário.

No que se refere à configuração do seu ambiente, esse é o servidor:

1 - Primário/Principal

2 - Secundário

Escolha uma das opções: 2

O valor de Servidor que está sendo configurado realmente é "2"? (s/n) s

Digite o endereco IP do servidor primário: 11.11.11.11

O valor de IP realmente é "11.11.11.11"? (s/n) s

Digite o FQDN alternativo para o servidor primário (exemplo: idpprimario.instituicao.br): primario.instituicao.br

O valor de hostname realmente é "primario.instituicao.br"? (s/n) s

Digite o endereco IP do servidor secundário: 22.22.22.22

O valor de IP realmente é "22.22.22.22"? (s/n) s

Pergunta de dados de replicação da base. Deve ser indicado a senha de replicação da base.

O local onde a informação deve ser verificada é indicado pelo script (arquivo /opt/dashboard/database.properties do servidor primário, no atributo database.repl.password.

Copiar o valor contido e preencher aqui. O valor da senha é um valor aleatório gerado no momento da instalação do primário. O valor abaixo é um mero exemplo. Verifique o valor no servidor primário conforme instruções.

Digite a senha para sincronizacao da base (veja no servidor primario em /opt/dashboard/database.properties o valor configurado em database.repl.password: kuj65RGe

O valor de Senha realmente é "kuj65RGe"? (s/n) s

Na sequência a instalação do secundário já é iniciada.

Pontos de Atenção

Depois de responder as perguntas (seja no primário ou no secundário), deve ser executado os procedimentos adicionais indicados nas seções Configurações Importantes - CAPTCHA (para os dois servidores). A configuração da seção SMTP associada ao servidor de e-mail é necessária somente no servidor primário. Após a execução dos procedimentos em questão, seguir com os procedimentos apresentados a seguir.

Etapas Adicionais

Seguem etapas adicionais a serem realizadas após a execução dos procedimentos já descritos anteriormente.

Cópia de chaves de segurança

No servidor principal, em /opt/shibboleth-idp/credentials, copie os arquivos a seguir para a mesma pasta no servidor secundário (sobrescrevendo no secundário os arquivos existentes):

● cafesealer.kver

● cafesealer.jks

Acerto de /etc/hosts

Em ambientes redundantes, precisamos garantir que os componentes em cada servidor se comuniquem entre si de forma adequada. Como as configurações são realizadas através da definição do FQDN, caso o DNS resolva um IP diferente a cada vez, isso pode ser um problema.

Assim é necessário editar o arquivo /etc/hosts de cada servidor para forçar que o servidor sempre resolva para o próprio IP.

Exemplo: Suponha IDP redundante de FQDN idp.instituicao.br que tem o servidor principal com IP 1.1.1.1 e o IP do servidor secundário seja 2.2.2.2. Para este caso hipotético, teremos:

Servidor principal - /etc/hosts terá uma entrada como:

1.1.1.1 idp.instituicao.br

Servidor secundário - /etc/hosts terá uma entrada como:

2.2.2.2 idp.instituicao.br

Certificado SSL

Nos casos em que o servidor secundário se comunica com o primário, é necessário um FQDN alternativo para o servidor primário. Este FQDN alternativo é utilizado para que o secundário possa se comunicar com o primário.

Ou o certificado do servidor primário precisa ter também este FQDN alternativo ou ele precisa ser um wildcard que comporte tanto o FDQN principal e secundário.

Exemplo, suponha que o FQDN do IDP seja “idp.istituicao.br” e o FQDN alternativo para o servidor primário seja “idpprimario.instituicao.br”. Assim o certificado deve responder tanto por “idp.inistuicao.br” como por “idpprimario.instiutuicao.br” (através de definiçao de alternative names no certificado) ou o certificado deve ser um wildcard como “*.instituicao.br”

É importante lembrar, que nestes casos, o Apache do primário deve ser configurado para responder aos dois domínios. Assim, é necessário adicionar na configuração do apache algo como:

ServerName idp.istituicao.br

ServerAlias idpprimario.instituicao.br

Libertações de Firewall

Decorrente das interações necessárias para que os servidores operem de forma conjunta, é necessário que sejam realizadas algumas liberações de firewall.

Origem

Destino

Primário(1.1.1.1)

Secundário(2.2.2.2)

TCP 5432

Secundário(2.2.2.2)

Primário(1.1.1.1)

TCP 5432

Primário(1.1.1.1)

Servidor SNMP

Vai depender da Configuração do Servidor

Secundário(2.2.2.2)

Primário(1.1.1.1)

TCP 443

Parâmetros de uma receita

Nesse conteúdo vamos aprender um pouco de como funciona a estrutura de receitas do RPilot e como trabalhar com as variáveis de instalação de uma receita.

Para que a receita possa funcionar de acordo com as informações da sua instituição, por exemplo, dados e valores necessárias e exclusivas da usa 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 36 variáveis necessárias para a instalação correta do IDP. Que podemos dividir em 4 subclasses:

Informações para certificado Shibboleth e metadado
Informação para conexão e configuração com base de diretório LDAP/AD
Informações para configuração de um webserver Apache
Informações para configuração do recurso do Dashboard MFA integrado ao IDP CAFe

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

DIRECTORY -> Essa variável vai tratar sobre qual o tipo de diretório você está conectando ao IDP. Essa informação e crucial que esteja certa para o correto funcionamento do IDP. Você só pode usar dois valores:

OPENLDAP

Passar esse valores em MAIUSCULO

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

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

Dashboard MFA da CAFe

PAINEL_ADMIN_NAME -> Será criada uma conta inicial de administrador para o usuário em questão: quando o painel de segurança é instalado, é cadastrado automaticamente um usuário inicial que receberá permissão de administrador. Será este usuário que irá atribuir permissões de administrador e operador a outros usuários. Certifique que todos os dados do usuário administrador inicial foi cadastrado corretamente

FQDN -> se trata do FQDN do seu servidor IDP. Exemplo: “idp.instituicao.br”

SMTP_ASSINATURA -> Nome que irá aparecer no email enviado como remetente. Exemplo: Instituição de Pesquisa e Educação.

SMTP_EMAIL_ORIGINADOR -> E-mail do originador. Se trata do e-mail que será exibido para o usuário como originador do e-mail. Exemplo: no-reply@instituticao.br

SMTP_HOST -> se trata dos dados de acesso necessários para que o painel de segurança possa enviar e-mails. Preencha aqui o endereço do servidor SMTP. Exemplo: smtp.instituicao.br

SMTP_NOME_AMIGAVEL -> Digite o Nome amigavel a ser exibido para identificar quem envia os e-mails: na ser exibido para identificar quem envia os e-mails. Exemplo: Nome da Instituição

SMTP_PASSWORD -> senha para autenticação na conta SMTP.

SMTP_PORT -> porta do servidor SMTP. Exemplo: 587

SMTP_USERNAME -> conta a ser utilizada para se autenticar no servidor SMTP

MSG_AUTENTICACAO -> Mensagem que irá aparecer na tela de login para os usuários. Exemplo: Digite aqui sua matrícula:

URL_RECUPERACAO_SENHA -> Caso possua uma URL para direcionar seus usuários para um sistema de recuperação de senha digite aqui esse endereço. Exemplo: https://endereco_recuperacao.com.br/

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

Guia de Instalação Shibboleth SP (3.4)

Nota sobre Atualizações para o Shibboleth SP 3:

O Shibboleth SP v3 oferece suporte ao formato de configuração do SP v2, tornando os arquivos de configuração do SP v2 compatíveis com o SP v3.
Verifique o arquivo shibd.log para encontrar avisos de elementos de configuração obsoletos (deprecation warnings).
O guia de migração fornece instruções sobre como atualizar sua configuração para eliminar os avisos de elementos legados.

Introdução

Este guia descreve a instalação de um Shibboleth Service Provider (SP) 3.4 nos sistemas operacionais Linux/Unix, conforme suportado pelo Shibboleth Consortium. As instruções são genéricas e não específicas para federações.

Não testamos o SP em todas as versões de sistemas operacionais, então, por favor, relate qualquer problema que encontrar.

Verifique e confirme os requisitos de sistema do Shibboleth SP 3 antes de prosseguir.

Selecione o tipo de sistema operacional no host onde o Shibboleth Service Provider será instalado:

Red Hat Enterprise Linux 7/8/9, Rocky Linux 8/9, Ubuntu 22/23/24, Debian 11/12 ou CentOS Linux 7 ou Amazon Linux 2/2023.

Se você usar uma distribuição Linux não listada acima que inclua um pacote Shibboleth SP atualizado, pode tentar instalar este.

Se o Service Provider já estiver instalado, continue para o Guia de Configuração do Switch Shibboleth Service Provider, específico para federações.

Nota sobre o CentOS 8 Desde setembro de 2023, o Shibboleth Consortium não oferece mais suporte ao CentOS 8 como plataforma oficialmente suportada.

Para remover o repositório SWITCHaai do sistema:

Desinstale os pacotes shibboleth e switchaai-apt-source.
Remova qualquer configuração APT restante para este repositório (se houver). Isso não desinstalará o Shibboleth SP, e os pacotes SWITCHaai SP instalados permanecerão até que uma versão mais recente esteja disponível no repositório oficial da distribuição.

Comandos sugeridos:

apt remove shibboleth  
apt-mark manual libapache2-mod-shib  
apt purge switchaai-apt-source  
rm /etc/apt/trusted.gpg.d/SWITCHaai-swdistrib.gpg /etc/apt/sources.list.d/SWITCHaai-swdistrib.list  
apt update

Recomendações

O projeto Shibboleth mantém seu próprio repositório, que fornece os binários oficiais do Shibboleth Service Provider e suas dependências para distribuições Linux baseadas em RPM. Este repositório sempre contém a versão mais atualizada do Shibboleth Service Provider. Portanto, é recomendável utilizar este repositório e seus pacotes, em vez dos pacotes fornecidos pela distribuição do sistema operacional.

Os seguintes softwares são opcionais, mas recomendados para a instalação e operação do Service Provider:

NTP: Os servidores que executam o Shibboleth precisam ter o horário do sistema sincronizado para evitar erros de diferença de relógio. Por isso, é recomendado ativar o ntp, chrony ou algum outro mecanismo de sincronização de tempo.
sudo: Recomenda-se instalar o sudo para comandos que exigem privilégios de root. O sudo pode ser instalado como usuário root utilizando:
- Debian, Ubuntu:
  apt install sudo
- Red Hat Enterprise Linux, CentOS:
  yum install sudo
- Rocky Linux:
  dnf install sudo
curl: Para baixar softwares e arquivos de configuração, recomenda-se utilizar o curl. Caso prefira, você pode substituir os comandos do curl por outra ferramenta, como o wget. O curl pode ser instalado com:
- Debian, Ubuntu:
  apt install curl
- Red Hat Enterprise Linux, CentOS 7:
  sudo yum install curl
- Rocky Linux 8/9:
  sudo dnf install curl
SSL habilitado para Apache: Recomenda-se fortemente habilitar e configurar o módulo SSL do Apache (mod_ssl) para suportar HTTPS (por exemplo, com sudo a2enmod ssl; sudo a2ensite default-ssl no Debian/Ubuntu). Por padrão, as mensagens do Shibboleth que contêm atributos de usuário são criptografadas. Embora possam ser enviadas por HTTP inseguro, qualquer acesso baseado em sessão via HTTP inseguro está sujeito a ataques de sequestro de sessão. Isso inclui sessões do Shibboleth. Usar HTTPS mitiga significativamente esse risco.

Antes de continuar para a próxima seção, certifique-se de que os requisitos acima foram atendidos no sistema onde o Shibboleth Service Provider será instalado.

Instalação

Instale o Shibboleth Service Provider.

Instalação do Shibboleth Service Provider Se uma versão anterior do Service Provider já estiver instalada no sistema, pode ser solicitado que você escolha entre manter os arquivos de configuração existentes ou substituí-los pelos arquivos padrão do pacote. Recomenda-se manter os arquivos de configuração antigos.

Você pode continuar usando os arquivos antigos na maioria dos casos. No entanto, é necessário atualizá-los para eliminar os avisos de elementos de configuração obsoletos. Geralmente, é recomendável realizar uma configuração limpa, conforme descrito no guia de configuração mencionado.

Para Debian e Ubuntu, instale o pacote Shibboleth com:
```
sudo apt install libapache2-mod-shib
```
```
sudo yum install shibboleth
```

Após instalar o pacote, inicie e habilite o daemon shibd:

sudo systemctl start shibd.service
sudo systemctl enable shibd.service

Configurações opcionais de proxy

O Shibboleth fará download automático de arquivos de metadados e CRL. Se a política da sua rede não permitir conexões de saída na porta 80 por padrão, é recomendável configurar um proxy HTTP para conexões de saída.

Adicione a seguinte linha em /etc/sysconfig/shibd:

export http_proxy=proxy.example.org:8080

Resultado

O Service Provider agora deve estar instalado no sistema. Os diretórios de interesse são:

/etc/shibboleth
Diretório de configuração do Shibboleth. O principal arquivo de configuração é o shibboleth2.xml.
/var/log/shibboleth
Diretório de logs onde os registros são gravados. O arquivo de log mais importante é o shibd.log, que deve ser consultado em caso de problemas.
/run/shibboleth
Diretório de runtime onde os arquivos de ID de processo e de soquete são armazenados.
/var/cache/shibboleth
Diretório de cache onde os backups de metadados e arquivos CRL são armazenados.

Teste Rápido

Após a instalação, um teste rápido pode verificar se o Service Provider foi instalado corretamente.

Verificação da Configuração do Shibboleth SP No terminal, execute o seguinte comando para verificar se o Shibboleth Service Provider pode carregar a configuração padrão:

Para Debian, Ubuntu, Rocky Linux, CentOS:
```
sudo shibd -t
```

Para Red Hat Enterprise Linux:

sudo LD_LIBRARY_PATH=/opt/shibboleth/lib64 shibd -t

A última linha da saída deve ser:

overall configuration is loadable, check console for non-fatal problems

Se houver entradas de log do tipo ERROR, é altamente recomendável investigar o problema. Mensagens com nível de log WARN geralmente não são problemáticas, mas é recomendável examinar suas causas.

Verificação da Configuração do Apache Teste também a configuração do Apache com o comando:

sudo apachectl configtest

A saída esperada para este comando é:

Syntax OK

Teste Rápido do Shibboleth (Re)inicie o servidor web e acesse a URL:

https://<seu-host>/Shibboleth.sso/Session

O servidor web (ou mais especificamente o daemon Shibboleth) deve retornar uma página com a mensagem:

A valid session was not found.

Essa mensagem indica que o módulo Shibboleth foi carregado pelo servidor web e está se comunicando com o processo shibd.

Configuração do Service Provider

Depois de os testes anteriores serem bem-sucedidos, continue para a configuração do Shibboleth SP.

Erros e Melhorias? Se você encontrar um erro ou um equívoco, ou se tiver sugestões de melhorias, informe-nos. Suas contribuições são muito apreciadas e ajudarão seus colegas.

Informações Adicionais

Referências:

CAFe

CAFe

Central de Ajuda - CAFe

Qual a sua dúvida?

Encontrou algum problema neste portal?

Políticas do Serviço

Apresentação

Público alvo

Credenciamento

Requisitos

Considerações Finais

Contato

Termo de privacidade do Provedor de Serviço (SP)

CAFe Service Provider (SP) Privacy Agreement

Política da Comunidade Acadêmica Federada (CAFe)

Verificação de Inicidentes

Passo 1. Validar Pré requisitos

Passo 2. Coleta de Evidências

Passo 3. Enviando as Informações

Lista de Clientes

Atributos da CAFe

Perguntas Frequentes

FAQ - CAFe

FAQ - Pentaho

Pentaho

Pentaho

Procedimentos de Instalação

Procedimento de importação do template de Máquina Virtual (PDI 9.0)

Objetivo

Pré-requisitos

Especificação do template

Procedimento de importação

Instalação Cliente PDI - Versão 9

Instalação Cliente PDI no Windows:

Instalação Cliente PDI no Linux:

Conectar Cliente ao Servidor PDI:

OpenLDAP

IDP CAFe

Manual de Usuário

Coleta/Verificação de Atributos

RPilot (IDP)

Service Provider (SP)

Central de Ajuda - CAFe

Qual a sua dúvida?

Encontrou algum problema neste portal?

Políticas do Serviço

Apresentação

Público alvo

Credenciamento

Requisitos

Considerações Finais

Contato

Termo de privacidade do Provedor de Serviço (SP)

Política da Comunidade Acadêmica Federada (CAFe)

CAFe Service Provider (SP) Privacy Agreement

Perguntas Frequentes

Pentaho

Atributos da CAFe

Verificação de Inicidentes

Passo 1. Validar Pré requisitos

Passo 2. Coleta de Evidências

Passo 3. Enviando as Informações

Procedimentos de Instalação

Procedimento de importação do template de Máquina Virtual (PDI 9.0)

Objetivo

Pré-requisitos

Especificação do template

Procedimento de importação

FAQ - Pentaho

Instalação Cliente PDI - Versão 9

Instalação Cliente PDI no Windows:

Instalação Cliente PDI no Linux:

Conectar Cliente ao Servidor PDI:

FAQ - CAFe

Lista de Clientes

Descrição dos Jobs e Transformações disponíveis no PDI/EID

Jobs - pasta /Home/eid/cafe

full-job-atualizacao-diaria

atualizacao-contas-intradia

eid-truncate-logs