Erro registrado no log  do IDPv3, que mostra possível erro de cadastro na aplicação do MConf (pode estar errado o cadastro do identificador)

2017-04-04 09:54:34,149 - INFO [Shibboleth-Audit.SSO:241] - 20170404T125434Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_59f2a212199bdf33fbf7c64aff058f3f|https://conferenciaweb.rnp.br/shibboleth-sp2|http://shibboleth.net/ns/profiles/saml2/sso/browser|https://idp.unir.br/idp/shibboleth|||bruno@unir.br|||||
2017-04-04 09:55:33,007 - DEBUG [org.opensaml.saml.saml2.binding.decoding.impl.HTTPRedirectDeflateDecoder:64] - Decoded RelayState: null
2017-04-04 09:55:33,008 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request
org.opensaml.messaging.decoder.MessageDecodingException: No SAMLRequest or SAMLResponse query path parameter, invalid SAML 2 HTTP Redirect message
        at org.opensaml.saml.saml2.binding.decoding.impl.HTTPRedirectDeflateDecoder.doDecode(HTTPRedirectDeflateDecoder.java:73)
2017-04-04 09:55:33,009 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: UnableToDecode
2017-04-04 09:55:33,009 - DEBUG [org.opensaml.saml.common.profile.logic.DefaultLocalErrorPredicate:154] - No SAMLBindingContext or binding URI available, error must be handled locally

Erro de autenticação federada no serviço (compute.rnp.br) CloudStack

O erro abaixo acontece porque a conta do usuário não está liberada no serviço (necessário verificar com os responsáveis a possível liberação):

<loginresponse cloud-stack-version="4.9.2.0"><errorcode>531</errorcode><errortext>Your

authenticated user is not authorized for SAML Single Sign-On, please contact your

administrator</errortext></loginresponse>

Gerar nova chave e certificado para o shibboleth

Esse é o link para o download do script de geração dos certificado para o Shibboleth:
http://www.na-df.rnp.br/repositorio/CAFe/VMs/Scripts/gerar-certificado-shibboleth.sh

Esse script irá gerar um novo certificado para o Shibboleth. Para evitar problemas sugiro que faça um backup do certificado, primeiro, antes de executa-lo. Os certificados do Shibboleth você encontrar no seguinte caminho: /opt/shibboleth-idp/credentials - idp.key e idp.crt. 
O script executa uma tarefa de remoção nestes diretórios por isso sugiro que faça o backup copiando os arquvios acima para outro diretório, por segurança.

Se tudo der certo, o novo certificado será gerado e já gravado no devido diretório, após isso você precisa copiar o novo certificado, o que aparece entre ----BEGIN---- e -----END---- do shibboleth "idp.crt" e substituir pela chave do certificado que se encontra no arquivo "idp-metadata.xml". Esse arquivo vocẽ irá econtrar no diretorio /opt/shibboleth-idp/metadata . O proximo passo será enviar para a equipe do Service Desk RNP este arquivo metadata alterado com a nova chave que foi gerada, importante se certificar disso, envio também com o nome da instituição a Sigla e o contato técnico, afim de facilitar a identificação do mesmo.

Fazer o restart do container do tomcat com o comando a seguir: systemctl restart tomcat8.service

Gerar nova chave e certificado para o Apache (auto assinado)

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

http://www.na-df.rnp.br/repositorio/CAFe/VMs/Scripts/gerar-certificado-apache.sh

Esse script irá gerar um novo certificado para o Apache. Para evitar problemas sugiro que faça um backup do certificado, primeiro, antes de executa-lo. Os certificados do Apache você encontrar no seguinte caminho: /etc/ssl/private - chave-apache.key e /etc/ssl/certs - certificado-apache.crt. 
O script executa uma tarefa de remoção nestes diretórios por isso sugiro que faça o backup copiando os arquvios acima para outro diretório, por segurança.

Fazer o restart do apache2 com o comando a seguir: systemctl restart apache2.service

Gerar arquivos de informação para verificação das versões instaladas no IDP

Esse é o link para download do script de geração dos arquivos de informação do IDP:

http://www.na-df.rnp.br/repositorio/CAFe/VMs/Scripts/gerar-log-upgrade-release.sh

Esse script irá gerar arquivos contendo informações sobre versão e release dos serviços instalados no IDP e também qualquer upgrade que foi realizado no Ubuntu.

Após executar o script ele mesmo irá gerar um arquivo zipado com todas as informações necessárias para a equipe de suporte da CAFe, por favor enviar o arquivo ziapado para o Service desk da RNP.

Como baixar e executar o script(preferencialmente baixe o script dentro do diretório /tmp):

:/tmp# wget http://www.na-df.rnp.br/repositorio/CAFe/VMs/Scripts/gerar-log-upgrade-release.sh

Após baixar o script, vamos até o diretório /tmp para executa-lo:

:/tmp# chmod +x gerar-log-upgrade-release.sh

Após ter concedido permissão de execução no script vamos executa-lo:

:/tmp# ./gerar-log-upgrade-release.sh

Pronto ! Agora apenas copie o arquivo "idp-information.zip" e envie para o Service Desk da RNP:

:/tmp# ls -l
total 68
drwxr-xr-x 2 root    root     4096 set 11 08:34 hsperfdata_root
drwxr-x--- 2 tomcat8 tomcat8  4096 set 11 05:29 hsperfdata_tomcat8
-rw-r--r-- 1 root    root     5071 set 11 08:34 idp-information.zip
drwx------ 3 root    root     4096 set 11 05:29 systemd-private-0c05c82a57b149eaabf4b2677eb82269-apache2.service-05YiBh
drwx------ 3 root    root     4096 set 11 05:29 systemd-private-0c05c82a57b149eaabf4b2677eb82269-nagios-nrpe-server.service-Z7VFdf
drwx------ 3 root    root     4096 set 11 05:29 systemd-private-0c05c82a57b149eaabf4b2677eb82269-ntp.service-HXGBDh
drwx------ 3 root    root     4096 set 11 05:29 systemd-private-0c05c82a57b149eaabf4b2677eb82269-systemd-resolved.service-ecFWxu
drwxr-xr-x 2 tomcat8 root     4096 set 11 05:29 tomcat8-tomcat8-tmp

Altera nível do log do IDP para DEBUG

Importação de senhas armazenadas em hexadecimal

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.
O algoritmo a seguir pode ser 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.

String result;
public void execute(){
     result= null;
     String password = senha_hexa;
     byte[] sha = new byte[password.length() / 2];
     for (int i=0; i< sha.length; i++){
        sha[i] = (byte) Integer.parseInt(password.substring(2*i, 2*i+2), 16);
     }
     com.mindprod.base64.Base64 base64 = new com.mindprod.base64.Base64();
     result = base64.encode(sha);
  }

Os passos para configurá-lo são os seguintes:

1. Editar a extração da classe Conta
2. No Leiaute de destino, campo senha, deixar em branco o Campo Fonte
3. No Leiaute de destino, campo "Tipo de Script" selecione Bean Shell.
4. Editar o script de transformação desse campo e colocar o algoritmo acima
5. Salvar o script de transformação
6. Salvar a transformação
7. Executar novamente a importação dessa classe

É importante ressaltar que o campo algoritmoSenha 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

Importando discos .ova, .ovf ou qcow2 para VM no Proxmox

- Primeiro deve-se criar no proxmox uma VM, no formato qcow2, com os criterios de configuração informados abaixo:

• Sistema Operacional Ubuntu 18.04 LTS com instalação otimizada para ambientes de virtualização;
• Arquitetura de 64 bits;
• 8192 MBytes de memória RAM;
• 2 vCPU;
• 1 Disco rígido de 60 GBytes;
• 1 Adaptador de rede pré-configurado para usar ip fixo;

OBS.: Dependendo da versão do proxmox ele cria obrigatoriamente no formato RAW. Desta forma deve-se criar neste formato mesmo e após clonar no proxmox a template no mesmo server para o formato qcow2.
A clonagem é feita no proprio menu do proxmox e é bem simples.

- Depois baixar a vm idp da cafe e copia-la e descompacta-la no diretorio onde está a VM qcow2 no servidor proxmox que foi criada.

(/var/lib/vz/images/<número>).
<número> é o número da VM do proxmox

- Neste diretorio você verá a vm que foi criada no proxmox com seu numero de vm. 

(vm-<número>-disk-1.qcow2 onde <número> é 100, 101, 102 ou 103 ...).

- Renomeie esta vm para outro nome mas guarde o nome que será necessário.

- Depois executar o seguinte comando: 

qemu-img convert -O qcow2 IDP-CAFE1804-V333-20190425-disk1.vmdk  IDP-CAFE1804-V333-20190425-disk1.qcow2

- Renomeie o arquivo convertido para o nome que da vm que foi criada pelo proxmox  (vm-<numero>-disk-1.qcow2)

- Após isso pode executar a vm no proxmox.

- Tendo sucesso podera excluir os arquivos .mf e .ovf são desnecessários para esse procedimento e poderá ser descartado.

- O arquivo que foi criado inicialmente no proxmox para criar a imagem vazia e pois foi renomeado para algum outro nome também pode ser descartado.

Conteúdo colaborativo enviado por Anderson Tunes Fonseca, da UENP, Universidade Estadual do Norte do Paraná.

Certificado solicita senha toda vez que o serviço Apache é reiniciado 

Causa: 

A razão pela qual essa caixa de diálogo aparece na inicialização e a cada reinicialização é que a chave privada RSA dentro de um arquivo server.key é armazenada em formato criptografado por motivos de segurança. A frase secreta é necessária para descriptografar este arquivo, para que possa ser lido e analisado.

Solução:

Este roteiro foi criado para ajudar na instalação de um certificado SSL com senha criptografada em um servidor Apache. Existem duas opções para resolver esse problema no servidor Apache. Revise as soluções sugeridas.

Opção 1: remova a senha da chave privada

Esta opção criará uma nova cópia da chave privada que não incluirá uma senha.

É possível criar uma cópia não criptografada da chave usando este comando: openssl rsa -in file1.key -out file2.key

file2.key conterá sua chave não criptografada.

Se agora você apontar o servidor para esse arquivo de chave, ele não solicitará uma senha. Se alguém receber a chave não criptografada, ele poderá se passar por você (as chaves criam sua assinatura digital de identificação).

Certifique-se de que as permissões nesse arquivo permitam que apenas "root" ou "usuário do servidor web" o leia. De preferência, inicie o servidor da Web como root, mas execute como outro servidor e tenha a chave legível apenas pela raiz.

Opção 2: use um arquivo de senha

Esta opção criará um arquivo de senha no servidor que será usado para fornecer a senha da chave privada quando o Apache for iniciado.

1. Crie um arquivo, por exemplo, em /etc/httpd/conf, chamado passphrase-file.conf. No arquivo da senha, inclua as linhas abaixo.

#!/bin/sh
echo "[private key passphrase]"

       2. Para tornar o arquivo da senha executável, use o comando abaixo

chmod +x [/path/to/passphrase-file.conf]

       3. Marque /etc/httpd/conf/httpd.conf para a linha que contém "SSLPassPhraseDialog"

SSLPassPhraseDialog exec:[/path/to/passphrase-file.conf]

       4. Pare e inicie o Apache neste momento.

systemctl stop apache2.service
systemctl start apache2.service

Erro Cannot instantiate abstract class or interface: br.ufmg.lcc.eid.dto.EidClass

Esse erro ocorre quando são removidos registros diretamente no banco ou quando ocorre alguma falha que provoca inconsistências no banco. Os passos para corrigi-lo são os seguintes:

1 - abra uma conexão com o banco de dados "eid" utilizando algum cliente

2 - execute o seguinte SQL:

delete from TBL_EID_CLASS where id not in
(
select id from TBL_SVC_ALUNO
union
select id from TBL_SVC_CONTA
union
select id from TBL_SVC_EMAIL
union
select id from TBL_SVC_ENDERECO
union
select id from TBL_SVC_PROFESSOR
union
select id from TBL_SVC_TECNICO
union
select id from TBL_SVC_TELEFONE
union
select id from TBL_SVC_GRUPO
union
select id from TBL_SVC_IDENTIFICACAO
);
delete from TBL_EID_OBJECT where guid not in (
select eidObject_guid from TBL_EID_CLASS);

Erro "Not mapped class <nomeClasse> ao executar um processo de Importação

Este erro acontece quando a pasta  "services"  localizada em /opt/VERSAO_EID/WEB-INF/classes/br/ufmg/lcc/eid/ não foi criada.

Esta pasta contém as classes compiladas pelo EID ao subir o tomcat. Para resolver o problema certifique-se de que :

• O usuário que sobe o tomcat tem permissão na pasta /opt/{VERSAO_EID) para dar permissão executar:

chown -R tomcat6:tomcat6 /opt/eid-{VERSÃO_EID}/

/etc/init.d/tomcat6 stop

Ver processos em execução:

ps -ef | grep java

Startar o tomcat:

/etc/init.d/tomcat6 start

• A conexão com o Metadiretório está configurada corretamente (Menu configuração/repositório de dados => Testar a conexão com o banco EID)

• Verificar se a variável JAVA_HOME aponta pra o JDK ( O JRE não permite compilação)

•  Verificar se a configuração do diretório WEB-INF da aplicação está correta através do Menu EID/Configuração

  /opt/eid-VERSAO/WEB-INF
  

• Verificar se no arquivo /etc/tomcat6/Catalina/localhost/eid.xml o campo docBase aponta para o diretório de instalação do EID: /opt/eid-VERSAO

Log do tomcat está apresentando erros e crescendo muito

Caso o log do tomcat apresente o seguinte erro:

140 ERROR Eid Person Conciliator thread br.ufmg.lcc.arangi.model.ModelService - Error getting BO by BO class name: org.springframework.beans.factory.BeanCreationException, Error creating bean with name 'br.ufmg.lcc.eid.model.conciliator.ConciliatorBO' defined in class path resource ModelConfig.xml: Instantiation of bean failed; nested exception is java.lang.NoClassDefFoundError

Solução:

• Verificar se a pasta /opt/eid-VERSÃO/lib contém os arquivos:libJaroWinklerLib.so e List.o, caso não tenha sido criado refazer os passos do tutorial que compilam o algoritmo

• Verificar se variável JARO_WINKLER_DIR está setada corretamente com caminho /opt/eid-VERSÃO/lib

• Verificar no arquivo /etc/default/tomcat6 se a variável-Djava.library.pathestá setada como abaixo:

-Djava.library.path=$JARO_WINKLER_DIR

Erro de HTTPs ao baixar os metadados da Federação CAFe

Este erro pode ser causado quando um firewall gerencia toda e qualquer conexão HTTPs e acaba impedindo a comunicação entre os hosts.

2017-02-01 17:38:46,762 - ERROR [org.opensaml.saml.metadata.resolver.impl.HTTPMetadataResolver:251] - Error retrieving metadata from https://ds.chimarrao.cafe.rnp.br/metadata/chimarrao-metadata.xml
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

2017-02-01 17:38:52,457 - ERROR [org.opensaml.saml.metadata.resolver.impl.HTTPMetadataResolver:251] - Error retrieving metadata from https://ds.cafe.rnp.br/metadata/cafe-metadata.xml
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Erro / problemas de conexão com AD / LDAP

O erro descrito no log abaixo, é baseado em um problema de conexão com a base e o IDP, retornando timeout. Este erro deve ser tratado pela instituição.

2017-03-14 00:44:15,573 - WARN [net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:175] - Profile Action ValidateUsernamePasswordAgainstLDAP: Login by apicolotto produced exception
org.ldaptive.LdapException: javax.naming.NamingException: LDAP response read timed out, timeout used:3000ms.
    at org.ldaptive.provider.ProviderUtils.throwOperationException(ProviderUtils.java:77)
Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:3000ms.
    at com.sun.jndi.ldap.Connection.readReply(Connection.java:490)

Erro / problema causado  na consulta da base LDAP, utilizando credenciais inválidas.

ldap_bind: Invalid credentials (49) - additional info: 80090308: LdapErr: DSID-0C0903D9, comment: AcceptSecurityContext error, data 52e, v2580 

O shibboleth abre uma conexão segura ou não e tenta fazer um bind com o usuário configurado no IDP. A criptografia que o LDAP usa não faz diferença para o Shibboleth. A principio a criptografia utilizada no seu serviço de LDAP não influencia na comunicação com o shibboleth. Neste caso o que ocorre é que o shibboleth abre uma conexão (segura ou não) com o servidor de LDAP e tenta fazer um bind com o usuário que está se autenticando (login/senha) recebendo um código de retorno do serviço de LDAP.

Erro / problemas de performance na consulta da base LDAP

A melhoria abaixo pode resolver o problema com a demora na leitura de uma base muito grande e impedir o erro de timeout para o Shibboleth, no retorno dos atributos consultados.

Esta solução técnica é para melhorar a resposta do tempo de retorno dos atributos de uma determinada classe utilizada, no caso   (objectClass=brEduPerson).

Configurar memória no Tomcat

Adicionar os parâmetros -Xms500M -Xmx1024M na variável JAVA_OPTS no arquivo /etc/default/tomcat6

Verificar registros pendentes para conciliação:

select count( * ) from TBL_EID_OBJECT where pending=true;

Como validar a sintaxe de e-mails?

Um problema que tem sido constante na exportação utilizando o EID2LDAP está relacionado com a sintaxe do atributo e-mail.

O LDAP valida a sintaxe de todos atributos. Muitos daqueles utilizados são strings, não implicando em restrições fortes.

O e-mail, entretanto, possui uma sintaxe um pouco mais rígida (vide http://www.cs.tut.fi/~jkorpela/rfc/822addr.html), impedindo, dentre outros padrões, caracteres acentuados.

Uma solução para este problema é filtrar os e-mails inválidos no momento da carga do metadiretório, impedindo a entrada de e-mails inválidos.

Esta filtragem pode ser feita utilizando-se o script de transformação para carga do campo email.

Os passos são os seguintes:

• Acessar o menu "Configuração" -> "ETC"
• Editar a ETC responsável pela carga de e-mail
• Localizar, na guia "Leiaute de Destino", a linha do campo "email"
• Na coluna "Campo Fonte", selecionar o item vazio
• Editar a coluna "Script"
• Colar o código abaixo, substituindo-se CAMPO_FONTE_EMAIL pelo nome do campo e-mail configurado na fonte
• Confirmar a alteração
• Salvar a ETC
• Reagendar a carga dos e-mails

/* O codigo */
 String result;
 public void execute() {
     result=null;
     String email = CAMPO_FONTE_EMAIL;
     if (email != null) {
         java.util.regex.Pattern patternEmail = java.util.regex.Pattern.compile("^([a-zA-Z0-9_\\-\\.]+)@((\\[[0-9]
         {1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.)|(([a-zA-Z0-9\\-]+\\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\\]?)$");
         java.util.regex.Matcher matchEmail = patternEmail.matcher(email);
         if (matchEmail.find()) {
             result = email;
         }
     }
 }

Usuários totalmente em branco, inseridos no EID, causando problemas ao atualizar o EID2LDAP.

Saída de Erro:

Solução para este erro:

A exclusão deve acontecer na sua base de dados e no Eid. Procure pelos usuários no seu banco e exclua das queries. No Eid acesse menu Eid/Gestão de pesssoas, pesquise pelos usuários com problema e clique no botão desativar. Desta forma ele não será mais enviado para o ldap.

Limpar a base EID (Não apaga as configurações, apenas os dados)

DELETE FROM eid.TBL_SVC_ALUNO;
DELETE FROM eid.TBL_SVC_CONTA;
DELETE FROM eid.TBL_SVC_EMAIL;
DELETE FROM eid.TBL_SVC_ENDERECO;
DELETE FROM eid.TBL_SVC_PROFESSOR;
DELETE FROM eid.TBL_SVC_TECNICO;
DELETE FROM eid.TBL_SVC_TELEFONE;
DELETE FROM eid.TBL_SVC_GRUPO;
DELETE FROM eid.TBL_SVC_IDENTIFICACAO;
DELETE FROM eid.TBL_EID_CLASS;
DELETE FROM eid.TBL_MAPPING;
DELETE FROM eid.TBL_MATCH;
DELETE FROM eid.TBL_EID_OBJECT;
DELETE FROM eid.TBL_EXTERNAL_SOURCE;
DELETE FROM pcollecta.PC_KEY_MAPPING;

Instalar OpenLDAP com o esquema brEduPerson - Passo a Passo

Como configurar a saída de log do LDAP

Objetivo: configurar a saída de log do LDAP junto ao rsyslog pois na configuração padrão o log é desabilitado um vez que é extremamente verboso.

1. Edite o /etc/ldap/slapd.conf, procurando a entrada loglevel e alterando o seu valor conforme a caixa abaixo:

#loglevel 0
loglevel stats config

2. Edite o /etc/rsyslog.d/50-default.conf e na linha que trata sobre o syslog adicione uma entrada para local4 conforme o exemplo abaixo:

*.*;auth,authpriv,local4.none   -/var/log/syslog

3. Ainda no mesmo arquivo (/etc/rsyslog.d/50-default.conf), adicione uma entrada para o LDAP abaixo da linha user.* já existente:

user.*                          -/var/log/user.log
local4.*                        -/var/log/ldap.log

4. Reinicie os serviços para que as atualizações façam efeito:

/etc/init.d/rsyslog restart
/etc/init.d/slapd restart

Comandos LDAPWHOAMI e LDAPSEARCH para testar conexão do IDP com servidor de Diretório

Testar BIND:

SEM SSL:

ldapwhoami -H ldap://servidor.ldap.institucional.com.br -D cn=Manager,dc=example,dc=com -W

COM SSL:

ldapwhoami -H ldaps://servidor.ldap.institucional.com.br -D cn=Manager,dc=example,dc=com -W

Exemplo:

===============================================================================================================================================================================================================================

Testar entrega dos atributos:

SEM SSL:

ldapsearch -H ldap://servidor.ldap.institucional.com.br -D "cn=Manager,dc=example,dc=com" -W - "(uid=nome.sobrenome)"

COM SSL:

ldapsearch -H ldaps://servidor.ldap.institucional.com.br -D "cn=Manager,dc=example,dc=com" -W - "(uid=nome.sobrenome)"

Exemplo:

Remover OpenLDAP com o esquema brEduPerson - Passo a Passo

Nenhuma questão cadastrada.

Tutorial Básico ApacheDS

Nenhuma questão cadastrada.

Tutorial Básico SimpleSAML

Nenhuma questão cadastrada.

Instalação do EID

Nenhuma questão cadastrada.

Atualização do EID

Nenhuma questão cadastrada.

Instalação do EID2LDAP

Nenhuma questão cadastrada.

Atualização do EID2LDAP

Nenhuma questão cadastrada.

Instalação Shibboleth-IDP 2.x

Como integrar o Shibboleth-IDP com o Microsoft Active Directory

Observação: A Federação CAFe não oferece suporte para a integração entre Shibboleth-IDP e Microsoft Active Diretory. Este guia deve ser utilizado apenas como um referência básica para configuração. Maiores informações podem ser obtidas diretamente no Wiki do Shibboleth.

1 - Altere o arquivo login.config baseando-se no exemplo abaixo:

ShibUserPassAuth {
   edu.vt.middleware.ldap.jaas.LdapLoginModule required
      host="servidorad.instituicao.br"
      port="3268"
      base="dc=servidorad,dc=instituicai,dc=br"
      ssl="false"
      tls="false"
      userField="sAMAccountName"
      serviceUser="usuario@servidorad.instituicao.br"
      serviceCredential="senha"
      subtreeSearch="true";
};

2 - No arquivo attribute-resolver.xml personalize o DataConnector baseando-se no exemplo abaixo:

<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
        ldapURL="$HOSTNAME-AD" baseDN="$BASE" principal="$USUARIO"
        principalCredential="$SENHA" searchScope="SUBTREE" mergeResults="true" cacheResults="false" maxResultSize="1" searchTimeLimit="3000">
	<!-- EXEMPLO
	ldapURL="ldaps://servidorad.instituicao.br" baseDN="dc=servidorad,dc=instituicao,dc=br" principal="servidorad\usuario"
        principalCredential="senha" searchScope="SUBTREE" mergeResults="true" cacheResults="false" maxResultSize="1" searchTimeLimit="3000">
	-->
        <FilterTemplate>
            <![CDATA[
                (samAccountName=$requestContext.principalName)
            ]]>
        </FilterTemplate>
	<ReturnAttributes>sAMAccountName userPrincipalName name mail cn sn displayName</ReturnAttributes>
	<LDAPProperty name="java.naming.referral" value="follow"/>
    </resolver:DataConnector>

Como criar um filtro de usuários

Existem situações em que apenas um sub-grupo de usuários do diretório poderão ter acesso a Federação.
Dado que este sub-grupo de usuários possua um atributo em comum (ex.: cafe=yes) é possível fazer um filtro permitindo que sejam autenticados apenas tais usuários.
Para tanto, é necessário editar o arquivo /opt/shibboleth/conf/login.config e adicionar a propriedade authorizationFilter baseando-se no exemplo abaixo:

ShibUserPassAuth {
   edu.vt.middleware.ldap.jaas.LdapLoginModule required
      host="diretorio.instituicao.br:389"
      base="ou=People,dc=instituicao,dc=br"
      ssl="false"
      userField="uid"
      authorizationFilter="(cafe=yes)"
      serviceUser="cn=Manager,dc=instituicao,dc=br"
      serviceCredential="senha"
      subtreeSearch="false";
};

Como filtrar a autenticação do usuário, liberando apenas os que possuem sAMAccountName + email institucional.

Alterar esta linha dentro do arquivo /opt/shibboleth-idp/conf/ldap.properties


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

Como autenticar por uid ou email

Alterar esta linha dentro do arquivo /opt/shibboleth-idp/conf/ldap.properties

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

Erro "Message was signed, but signature could not be verified"

Descrição: erro exibido no browser com ocorrência frequente quando é feita geração de novas chaves para o servidor.
Solução: atualizar o arquivo idp-metadata.xml substituindo a chave pública presente no arquivo pela versão atualizada.

Erro "Message did not meet security requirements"

Descrição: erro exibido no browser com ocorrência frequente quando a data/hora do servidor IdP está incorreta.
Solução: ajuste a data/hora do servidor.

Warn "NameVirtualHost *:80 has no VirtualHosts"

Descrição: warn exibido durante a inicialização do Apache quando o servidor possui apenas um VirtualHost.
Solução: comentar a linha NameVirtualHost *:80 no arquivo /etc/apache/ports.conf.

Como alterar o tempo padrão para atualização do arquivo de metadados

O Shibboleth IdP define suas fontes de metadados através do arquivo relying-party.xml. Sempre o Shibboleth IdP é inicializado uma nova cópia do arquivo de metadados é automaticamente baixada. Neste arquivo é possível incluir o atributo "cacheDuration" que define, em segundos, a frequência com a qual o Shibboleth IdP deverá atualizar (automaticamente) o arquivo de metadados. Na ausência deste atributo é assumido o valor padrão de 2880 segundos (48 minutos). A atualização de metadados ocorrerá na primeira tentativa de login após ter expirado o "cacheDuration".

O atual roteiro de configuração do Shibboleth IdP na Federação CAFe não inclui o atributo "cacheDuration", ou seja, o arquivo de metadados deverá ser atualizado automaticamente a cada 2880 segundos.

Abaixo um exemplo de configuração com uso do cacheDuration onde é definido um tempo e 300 segundos (5 minutos) para atualização do arquivo de metadados:

<MetadataProvider id="URLMD" xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
                  metadataURL="https://ds.chimarrao.cafe.rnp.br/metadata/chimarrao-metadata.xml"
                  backingFile="/opt/shibboleth-idp/metadata/chimarrao-metadata.xml" cacheDuration="300">
    <MetadataFilter xsi:type="ChainingFilter" xmlns="urn:mace:shibboleth:2.0:metadata">
        <MetadataFilter xsi:type="EntityRoleWhiteList" xmlns="urn:mace:shibboleth:2.0:metadata">
            <RetainedRole>samlmd:SPSSODescriptor</RetainedRole>
        </MetadataFilter>
    </MetadataFilter>
</MetadataProvider>

Instalação Shibboleth SP

Sugestão de como usar mais que um serviço em um mesmo host

    Share same domain name (https//:hostname.domain)
    Different context root (https://hostname.domain/app1, https://hostname.domain/app2 etc..)
    Require different set of attributes for eg. App1 needs uid, firstName, LastName and App2 needs uid, eduPersonPrimaryName, RNPEduIdNumber
    Both apps are served by same web server
    If requirement satisfy above, please follow the steps outlined below

before you proceed

It is assumed that SP is installed and configured with webserver

Shibboleth SP configuration:

    Open shibboleth2.xml in edit mode
    Add request mapper tag just above <ApplicationDefaults>
    <RequestMapper type="Native">
          <RequestMap>
              <Host name="hostname.domain">
                  <Path name="<app context root>" applicationId="app1" authType="shibboleth" requireSession="true"/>
                  <Path name="<app context root>" applicationId="app2" authType="shibboleth" requireSession="true"/>
              </Host>
          </RequestMap>
      </RequestMapper>
    Add application override just above </ApplicationDefaults> (This is end of ApplicationDefaults tag)
    <ApplicationOverride id="app1" entityID="https://hostname.domain/app1">
        <Sessions lifetime="28800" timeout="7200" checkAddress="false" handlerURL="/<context root of app1>/Shibboleth.sso" />
    </ApplicationOverride>
    <ApplicationOverride id="app2" entityID="https://hostname.domain/app2">
        <Sessions lifetime="28800" timeout="7200" checkAddress="false" handlerURL="/<context root of app2>/Shibboleth.sso" />
    </ApplicationOverride>



Configure Apache:

    Open shib.conf in edit mode

    Update it with to protect the app

    <Location /<context root of app1>
      AuthType shibboleth
      ShibRequestSetting applicationId app1
      ShibRequestSetting requireSession 1
      require valid-user
    </Location>

    <Location /<context root of app2>
      AuthType shibboleth
      ShibRequestSetting applicationId app2
      ShibRequestSetting requireSession 1
      require valid-user
    </Location>

    
Metadata URL

Metadata for these apps will be available at : https://<FQDN>/<application context root>/Shibboleth.sso/Metadata.
For eg. in our above case :

For app1 : it will be https://hostname.domain/<app context root>/Shibboleth.sso/Metadata
For app2 : it will be https://hostname.domain/<app context root>/Shibboleth.sso/Metadata

Geração de Chave e Certificado

1. Para se obter o fingerprint de um certificado deve-se executar o seguinte comando:

openssl x509 -noout -fingerprint -in "$ARQUIVO.CRT"

Resolvendo problemas de autenticação e resolução de atributos no AD

1. Arquivo: /opt/shibboleth-idp/conf/login.config

ShibUserPassAuth {
   edu.vt.middleware.ldap.jaas.LdapLoginModule required
      host="ldap://10.11.12.13"
      port="389"
      base="DC=dominio,DC=br"
      ssl="false"
      tls="false"
      userField="sAMAccountName"
      serviceUser="CN=conta_servico,CN=Users,DC=dominio,DC=br"
      serviceCredential="1234"
      referral="follow"
      userRoleAttribute="sAMAccountName"
      subtreeSearch="true";
};

obs. utilizar os parâmetros adicionais:

referral="follow"

userRoleAttribute="sAMAccountName"

2. Arquivo: /opt/shibboleth-idp/conf/attribute-resolver.xml

<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
    ldapURL="ldap://10.11.12.13" baseDN="DC=dominio,DC=br" principal="cn=conta_servico,cn=Users,dc=dominio,dc=br"
    principalCredential="1234" searchScope="SUBTREE" mergeResults="true" cacheResults="false" maxResultSize="1" searchTimeLimit="3000">
    <FilterTemplate>
        <![CDATA[
            (sAMAccountName=$requestContext.principalName)
        ]]>
    </FilterTemplate>
    <ReturnAttributes>cn sn mail sAMAccountName description</ReturnAttributes>
    <LDAPProperty name="java.naming.referral" value="follow"/>
</resolver:DataConnector>

obs. utilizar os parâmetros adicionais:

<LDAPProperty name="java.naming.referral" value="follow"/>

Liberação do atributo "uid"

1. Alterar o arquivo attribute-resolver.xml, adicionando o bloco a seguir. O bloco deve ser incluído na seção "Definições de atributos".

<!-- uid -->
<resolver:AttributeDefinition id="uid" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
    sourceAttributeID="sAMAccountName">
    <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        name="urn:mace:dir:attribute-def:uid" />
    <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" />
</resolver:AttributeDefinition>

2. Alterar o arquivo attribute-filter.xml, adicionando o bloco a seguir. O bloco deve ficar entre as tags  <AttributeFilterPolicy id="releaseToChimarraoOrCafe"> e </AttributeFilterPolicy>.

<afp:AttributeRule attributeID="uid">
  <afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>

3. Reiniciar Apache e Tomcat

/etc/init.d/apache2 restart
/etc/init.d/tomcat6 restart

Configuração para EduGain

1 - No arquivo /opt/shibboleth-idp/conf/attribute-filter, inserir o bloco abaixo:

    <AttributeFilterPolicy id="releaseToEduGain">

        <PolicyRequirementRule xsi:type="OR">
            <Rule xsi:type="Requester" value="https://sp.rnp.br/aacli" />
            <Rule xsi:type="InEntityGroup" groupID="urn:mace:switch.ch:SWITCHaai:interfederation" />
        </PolicyRequirementRule>

        <AttributeRule attributeID="eduPersonEntitlement">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>

    </AttributeFilterPolicy>
 

2 - Atualizar o arquivo metadata-providers.xml, fazendo o download abaixo:

wget --no-check-certificate https://svn.rnp.br/repos/CAFe/conf/shibboleth-idp/shib-v3/metadata-providers.xml -O /opt/shibboleth-idp/conf/metadata-providers.xml

Configuração CAT eduroam

1. No arquivo /opt/shibboleth-idp/conf/attribute-resolver.xml, colocar esses dois novos atributos do eduroam, abaixo do bloco de código que se refere ao mail:  

Exemplo:

<!-- CAFe - mail -->
<resolver:AttributeDefinition id="mail" xsi:type="ad:Simple" sourceAttributeID="mail">
<resolver:Dependency ref="myLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
</resolver:AttributeDefinition>

OBS: Recomendamos realizar um backup do arquivo /opt/shibboleth-idp/conf/attribute-resolver.xml ANTES de realizar qualquer alteração.

OBS2: Deve-se colocar o bloco de de DataConnector do eduroam DEPOIS bloco de definição do DataConector do LDAP (<resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory")

<!-- CAFe - eduPersonTargetedID - Eduroam CAT -->
        <resolver:AttributeDefinition id="eduPersonTargetedID" xsi:type="ad:SAML2NameID" nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" sourceAttributeID="computedID">
                <resolver:Dependency ref="computedID" />
                <resolver:AttributeEncoder xsi:type="enc:SAML1XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" />
                <resolver:AttributeEncoder xsi:type="enc:SAML2XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" />
        </resolver:AttributeDefinition>	
 
 
<!-- Connector computedID - Eduroam CAT -->
       <resolver:DataConnector id="computedID" xsi:type="dc:ComputedId"
                generatedAttributeID="computedID"
                sourceAttributeID="%{idp.authn.LDAP.returnAttributes}"
                salt="%{idp.cafe.computedIDsalt}"> <!-- o salt está declarado no arquivo idp.properties e precisa ser de no mínimo 16 caracteres -->
                <resolver:Dependency ref="myLDAP" />
        </resolver:DataConnector>
  <!-- Fim Connector computedID - Eduroam CAT -->
 

2. No arquivo /opt/shibboleth-idp/conf/attribute-filter.xml liberar o atributo eduPersonTargetedID  para todas as federações:

OBS: Recomendamos realizar um backup do arquivo /opt/shibboleth-idp/conf/attribute-filter.xml ANTES de realizar qualquer alteração.

Inserir as linhas abaixo entre as tags <AttributeFilterPolicy  e   </AttributeFilterPolicy>, dentro do bloco do id "releaseToAnyone" (<AttributeFilterPolicy id="releaseToAnyone">):

        <!-- Liberando o atributo eduPersonTargetedID para todas as federacoes -->
        <AttributeRule attributeID="eduPersonTargetedID">
            <PermitValueRule xsi:type="basic:ANY" />
        </AttributeRule>

3. Reiniciar o processo do tomcat e acompanhar o log:

~# initctl restart tomcat & tail -f /opt/shibboleth-idp/logs/idp-process.log

Procedimento para corrigir erro de fuso horário no servidor IDP (Configuração NTP)

Normalmente a mensagem de WARN que aprece no log, "idp-process.log" que aponta problemas com o fuso horário do servidor IDP apresenta-se desta forma:

==========================================================================================================================================================

16:59:28.235 - WARN [org.opensaml.common.binding.security.IssueInstantRule:108] - Message was expired: message issue time was '2013-11-13T10:59:26.348Z', message expired at:
'2013-11-13T11:05:26.348Z', current time: '2013-11-13T16:59:28.235-06:00'
16:59:28.236 - WARN [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:377] - Message did not meet security requirements
org.opensaml.ws.security.SecurityPolicyException: Message was rejected due to issue instant expiration

===========================================================================================================================================================

Neste caso o correto é acertar o fusa horário do servidor IDP configurando o serviço NTP, através deste roteiro abaixo:

1. Para fazer a instalação do NTP é necessária a seguinte linha de comando:

   
   

   apt-get -y install ntp

   
   

2. Após fazer a instalação é necessário modificar o arquivo /etc/ntp.conf que deverá ficar com o seguinte conteúdo:
   
    

   
   

   # /etc/ntp.conf, configuracao do ntpd
   
   driftfile /var/lib/ntp/ntp.drift
   statsdir /var/log/ntpstats/
   
   statistics loopstats peerstats clockstats
   filegen loopstats file loopstats type day enable
   filegen peerstats file peerstats type day enable
   filegen clockstats file clockstats type day enable
   
   # Servidores ntp do nic.br
   server a.ntp.br
   server b.ntp.br
   server c.ntp.br
   
   # By default, exchange time with everybody, but don't allow configuration.
   # See /usr/share/doc/ntp-doc/html/accopt.html for details.
   restrict -4 default kod notrap nomodify nopeer noquery
   restrict -6 default kod notrap nomodify nopeer noquery
   
   # Local users may interrogate the ntp server more closely.
   restrict 127.0.0.1
   restrict ::1
   
   # Para habilitar o servidor de hora para acesso a partir da rede
   # local, altere a linha abaixo:
   #broadcast 192.168.123.255

   
   

   
   Reiniciar o processo do tomcat:

   
   

   com ubutnu 14.0 é:

   initctl restart tomcat ou tomcat6

   com ubuntu 18.0 é:

   systemctl restart tomcat8.service 

Procedimento de verificação do erro "required nameid format not supported"

1 - Acessar o IDP da Instituição como root, via SSH.

- Editar o arquivo /opt/shibboleth-idp/conf/attribute-resolver.xml
 
Verificar se existe e esta descomentado o seguinte trecho de codigo:
 
<!-- Name Identifier related attributes -->
<!-- TransientId - identificador temporario de um usuario -->
<resolver:AttributeDefinition id="transientId" xsi:type="TransientId" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
<resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />
<resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
</resolver:AttributeDefinition>
 
 
- Editar o arquivo /opt/shibboleth-idp/conf/attribute-filter.xml
 
 
Verifcar se existe e esta descomentado o seguinte trecho de codigo:
 
 
<!-- Release the transient ID to anyone -->
<AttributeFilterPolicy id="releaseTransientIdToAnyone">
<PolicyRequirementRule xsi:type="basic:ANY" />
<AttributeRule attributeID="transientId">
<PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>

Filtros por atributo que podem ser utilizados para fazer login no IDP

Editar o arquivo /opt/shibboleth-idp/conf/ldap.properties:
 
Alterar ou não as seguinte variáveis:

idp.authn.LDAP.returnAttributes = conteúdo que pode ou não ser alterado.
idp.authn.LDAP.userFilter = conteúdo que pode ou não ser alterado.
idp.authn.LDAP.dnFormat = conteúdo que pode ou não ser alterado.
idp.attribute.resolver.LDAP.searchFilter = conteúdo que pode ou não ser alterado.

Faça o restart do tomcat:

~# initctl restart tomcat

Como personalizar o atributo utilizado para fazer login no IDP

Editar o arquivo /opt/shibboleth-idp/conf/ldap.properties:
 
Alterar as seguinte variáveis
idp.authn.LDAP.returnAttributes
idp.authn.LDAP.userFilter
idp.authn.LDAP.dnFormat 
idp.attribute.resolver.LDAP.searchFilter
 
E reiniciar o tomcat.

idp.authn.LDAP.returnAttributes = brPersonCPF

idp.authn.LDAP.userFilter = (brPersonCPF={user})

idp.authn.LDAP.dnFormat = brPersonCPF=%s,ou=RNP,dc=rnp,dc=local

idp.attribute.resolver.LDAP.searchFilter = (brPersonCPF=$requestContext.principalName)

~# initctl restart tomcat

Como Liberar o atributo de CPF e Data de Nascimento para o piloto serviço ICPEDU(P1/P5)

Editar o arquivo /opt/shibboleth-idp/conf/attribute-resolver.xml
 
Incluir o seguinte bloco de códigos:
 
        <!-- schacDateOfBirth -->
        <resolver:AttributeDefinition id="schacDateOfBirth" xsi:type="ad:Simple" sourceAttributeID="schacDateOfBirth">
                <resolver:Dependency ref="myLDAP" />
                <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:schacDateOfBirth" />
                <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.1466.115.121.1.36" friendlyName="schacDateOfBirth" />
        </resolver:AttributeDefinition> 

        <!-- brPersonCPF -->
        <resolver:AttributeDefinition id="brPersonCPF" xsi:type="ad:Simple" sourceAttributeID="brPersonCPF">
                <resolver:Dependency ref="myLDAP" />
                <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:brPersonCPF" />
                <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:1.3.6.1.4.1.15996.100.1.1.1.1" friendlyName="brPersonCPF" />
        </resolver:AttributeDefinition>
 
 
Ainda no mesmo arquivo, incluir estes atributos na lista de atributos retornados dentro da tag "<dc:ReturnAttributes>"

<dc:ReturnAttributes>%{idp.authn.LDAP.returnAttributes} cn sn mail eduPersonPrincipalName eduPersonScopedAffiliation schacDateOfBirth brPersonCPF givenName</dc:ReturnAttributes>

Editar o arquivo /opt/shibboleth-idp/conf/attribute-filter.xml:
 
Incluir o seguinte bloco de códigos:
 
<!-- Libera CPF e Data Nascimento para o SP da RNP (CAFe e Chimarrao)-->
<!-- Libera CPF e Data Nascimento para o servico ICPEDU  p1 e p5-->
        <AttributeFilterPolicy id="releaseToSPsRNP">
                <PolicyRequirementRule xsi:type="OR">
                        <Rule xsi:type="Requester" value="https://sp.rnp.br/cafe" />
                        <Rule xsi:type="Requester" value="https://sp.rnp.br/chimarrao" />
                        <Rule xsi:type="Requester" value="https://p1.icpedu.rnp.br/shibboleth-sp2" />
                        <Rule xsi:type="Requester" value="https://pessoal.icpedu.rnp.br/shibboleth-sp2" />
                        <Rule xsi:type="Requester" value="https://homolog.eduid.rnp.br/shibboleth-sp2" />
                </PolicyRequirementRule>
                <AttributeRule attributeID="schacDateOfBirth">
                        <PermitValueRule xsi:type="ANY" />
                </AttributeRule>
                <AttributeRule attributeID="brPersonCPF">
                        <PermitValueRule xsi:type="ANY" />
                </AttributeRule>
        </AttributeFilterPolicy>

Faça o restart do tomcat:

~# systemctl restart tomcat8.service

Como substituir o certificado, por um válido, exibido para os usuários em um IDP (apache)

1. Salve os arquivos (*.CRT) no diretório desejado. Por Exemplo:

/etc/ssl/certs

2. Edite o arquivo de configuração do VirtualHost. Por padrão fica em:

~# vi /etc/apache2/sites-available/01-idp.conf

3. Procure dentro do arquivo de configuração as seguintes linhas:

~# SSLCertificateKeyFile /etc/ssl/private/chave-apache.key
~# SSLCertificateFile /etc/ssl/certs/certificado-apache.crt
~# SSLCertificateChainFile /etc/ssl/certs/certificado-intermediario-apache.crt
 
.: Os nomes acima foram usados apenas para exemplificar os certificados, deve-se alterar para os nomes que foram utilizados no passo 1.

4. Salve as alterações realizadas no arquivo, e realize os seguintes comandos:

~# /etc/init.d/apache2 stop
~# /etc/init.d/apache2 start

5. Você pode acompanhar todo o processo através do log:

/var/log/apache2/
~# tail -f /var/log/apache2/idp.instituicao.dominio.error.log

Configurando o Apache Tomcat para iniciar durante a inicialização do servidor

Criar um script de inicialização /etc/init.d/tomcat8 seguindo as seguintes instruções:

#!/bin/bash

### BEGIN INIT INFO
# Provides: tomcat7
# Required-Start: $network
# Required-Stop: $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start/Stop Tomcat server
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin

start() {
sh /var/opt/tomcat8/bin/startup.sh
}

stop() {
sh /var/opt/tomcat8/bin/shutdown.sh
}

case $1 in
start|stop) $1;;
restart) stop; start;;
*) echo "Run as $0 "; exit 1;;
Esac

 Depois temos que acertar as permissões de leitura e execução e acertar os symlinks, esses comandos devem ser executados diretamente na console:

$ chmod 755 /etc/init.d/tomcat8

$ update-rc.d tomcat8 defaults

Pronto! Agora seu Tomcat irá iniciar automaticamente assim que seu sistema iniciar, e você pode controlar com o comando systemctl <stop/start/restart> tomcat8.service

Alterando a configuração do Shibboleth, mudança de base do OpenLdap para usar ActiveDirectory

1. Editar o arquivo /opt/shibboleth-idp/conf/ldap.properties, e alterar as seguintes variáveis:

a) idp.authn.LDAP.ldapURL:

idp.authn.LDAP.ldapURL = ldaps://host_do_AD:porta

Com LDAPs:

idp.authn.LDAP.ldapURL = ldaps://ldap.instituicao.br:636

Sem LDAPs:

idp.authn.LDAP.ldapURL = ldap://ldap.instituicao.br:389

b) idp.authn.LDAP.trustCertificates:

idp.authn.LDAP.trustCertificates = %{idp.home}/credentials/ldap-server.crt

c) idp.authn.LDAP.returnAttributes:

idp.authn.LDAP.returnAttributes = sAMAccountName

d) idp.authn.LDAP.baseDN:

idp.authn.LDAP.baseDN = CN=Users,DC=instituicao,DC=br

Busca em uma determinada OU dentro da árvore da instituição:

idp.authn.LDAP.baseDN = ou=users,dc=instituicao,dc=br

Busca na árvore inteira da instituição:

idp.authn.LDAP.baseDN = dc=instituicao,dc=br

e) idp.authn.LDAP.subtreeSearch:

idp.authn.LDAP.subtreeSearch = true

f) idp.authn.LDAP.userFilter:

idp.authn.LDAP.userFilter = (sAMAccountName={user})

g) idp.authn.LDAP.bindDN:

idp.authn.LDAP.bindDN = conta_servico@instituicao.br

 h) idp.authn.LDAP.bindDNCredential:

idp.authn.LDAP.bindDNCredential = senha_servico

i) idp.authn.LDAP.dnFormat:

idp.authn.LDAP.dnFormat = %s@instituicao.br

2. Reinicie o container do tomcat e acompanhe o log do shibboleth:

initctl restart tomcat && tail -f /opt/shibboleth-idp/logs/idp-process.log

Erro na validação dos atributos durante a tentativa de autenticação na Chimarrão, ou CAFe (Metadado)

Imagem do erro:

Casua:

Probelma:

Tratamento:

Solução:

Error retrieving metadata from https://ds.chimarrao.cafe.rnp.br/metadata/chimarrao-metadata.xml
javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: 200.130.35.49

Altere (ainda no arquivo /etc/default/tomcat6) a linha:


De:
JAVA_OPTS="-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC"
 
 
Para:
JAVA_OPTS="-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC -Djdk.tls.trustNameService=true"

    <AttributeFilterPolicy id="releaseToEduGain">

        <PolicyRequirementRule xsi:type="OR">
            <Rule xsi:type="Requester" value="https://sp.rnp.br/aacli" />
            <Rule xsi:type="InEntityGroup" groupID="urn:mace:switch.ch:SWITCHaai:interfederation" />
        </PolicyRequirementRule>

        <AttributeRule attributeID="eduPersonEntitlement">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>

    </AttributeFilterPolicy>