Skip to end of metadata
Go to start of metadata

"ANTES DE EXECUTAR QUALQUER UM DESTES PROCEDIMENTOS, É NECESSÁRIO QUE UM BACKUP DA MÁQUINA TENHA SIDO EXECUTADO, EVITANDO QUE FALHAS NA REALIZAÇÃO DAS CONFIGURAÇÕES VENHAM A IMPACTAR NO FUNCIONAMENTO DO SERVIÇO"


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



Altere o nível do log para DEBUG. Abra o arquivo  /opt/shibboleth-idp/conf/logback.xml  e altere as linhas abaixo:

<variable name="idp.loglevel.idp" value="DEBUG" />
<variable name="idp.loglevel.ldap" value="DEBUG" />
<variable name="idp.loglevel.opensaml" value="DEBUG" />

Faça o restart do container do tomcat com o comando abaixo:

systemctl restart tomcat8.service & tail -f /opt/shibboleth-idp/logs/idp-process.log

O restart pode levar em torno de 3 minutos.

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

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


No arquivo /opt/shibboleth-idp/conf/attribute-resolver.xml alterada a consulta:
                <dc:FilterTemplate>
                        <![CDATA[
                                (&(&(%{idp.authn.LDAP.returnAttributes}=$requestContext.principalName)(brEduAffiliation=*))(&(brEntranceDate=*)(!(brExitDate=*))))
                        ]]>
PARA:
                <dc:FilterTemplate>
                        <![CDATA[
                                (&(&(&(%{idp.authn.LDAP.returnAttributes}:dn:=$requestContext.principalName)(objectClass=brEduPerson))(brEduAffiliation=*))(&(brEntranceDate=*)(!(brExitDate=*))))
                        ]]>

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:

E: Erro ao enviar ldif   Ldap <LDAP local:localhost:389>: 
Erro: Local Error:

version: 1
dn: uid=,  ou=people,dc=uern,dc=br
changetype: add
objectClass: Person
objectClass: inetOrgPerson
objectClass: eduPerson
eduPersonPrincipalName: AXSGBZMA-GHWPBAAA@uern.br
cn: 
sn: 
displayName: 
givenName:
.
I: Ldap <LDAP local:localhost:389>: o LDAP não foi atualizado com sucesso.

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:

gtiadm@idp-rnp:~$ ldapwhoami -H ldap://ldap.rnp.br -D "uid=carlos.petribu.adm,OU=GTI,OU=USUARIOS ADMIN,ou=RNP,dc=rnp,dc=local" -W
Enter LDAP Password:
dn: uid=carlos.petribu.adm,ou=gti,ou=usuarios admin,ou=rnp,dc=rnp,dc=local


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


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:

gtiadm@idp-rnp:~$ ldapsearch -H ldap://ldap.rnp.br -D "uid=carlos.petribu.adm,OU=GTI,OU=USUARIOS ADMIN,ou=RNP,dc=rnp,dc=local" -W - "(uid=gianfranco.lucca)"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: - (uid=gianfranco.lucca)
#

# search result
search: 2
result: 32 No such object

# numResponses: 1


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">):

Configuração do CAT-da-Eduroam
        <!-- 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.


Configuração do CAT-da-Eduroam
- 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.

Exemplo:


Este filtro limita a autenticação apenas de quem possui sAMAccountName + email institucional.

idp.authn.LDAP.userFilter      = (&(sAMAccountName={user})(mail=*@xxxx.br))



O filtro abaixo permite a autenticação por dois atributos, uid ou e-mail:

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


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.

Exemplo:

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

Neste exemplo, o usuário deverá utilizar seu CPF para efetuar login neste IDP

Algumas observações importantes:

Documentação de referência
https://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolverConfiguration
https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterConfiguration

attribute-resolver.xml
  1. O atributo utilizado para o login tem que obrigatoriamente estar declarado
  2. O atributo utilizado para o login tem que estar sendo liberado pelo idp na tag "ReturnAttributes"

attribute-filter.xml

  1. O atributo utilizado deve estar configurado para ser liberado para a federação

Caso isto não esteja configurado, a simples alteração mencionada no FAQ não irá funcionar corretamente


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

A inclusão dos blocos 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-resolver.xml.

Exemplo de como fica a tag "<dc:ReturnAttributes>" após a inclusão dos atributos de CPF e Data de Nascimento: 

<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://p5.icpedu.rnp.br/shibboleth-sp2" />
                </PolicyRequirementRule>
                <AttributeRule attributeID="schacDateOfBirth">
                        <PermitValueRule xsi:type="ANY" />
                </AttributeRule>
                <AttributeRule attributeID="brPersonCPF">
                        <PermitValueRule xsi:type="ANY" />
                </AttributeRule>
        </AttributeFilterPolicy>

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 P5 do ICPEDU. Lembrando que os atributos devem existir no serviço de diretório da institução em forma de atributo do usuário.

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)


Preparando o Certificado

Preparar o certificado para a substituição:

Primeiro você deverá copiar o conteúdo existente desde a linha -----BEGIN CERTIFICATE----- até a linha -----END CERTIFICATE----- e salvá-lo em sua máquina com a extensão (*.CRT).

Não utilize o Microsoft Word ou outro programa de processamento de textos, pois eles podem acrescentar caracteres ocultos ao arquivo de text


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.

Importante verificar a opção "SSLCertificateChainFile /etc/ssl/certs/certificado-intermediario-apache.crt" essa linha pode não estar presente em sua configuração, isso depende do tipo de certificado usado por cada instituição. Caso não tenha essa opção, ignore.


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

Lembrando que para o tomcat funcionar é necessário ter instalado no sistema o OpenJDK, ou JDK.

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


IMPORTANTE

Antes de iniciar o procedimento, realize um backup do arquivo /opt/shibboleth-idp/conf/ldap.properties

INFO

A montagem deste roteiro foi baseado da documentação oficial do "shibboleth(https://wiki.shibboleth.net/confluence/display/IDP30/LDAPAuthnConfiguration#LDAPAuthnConfiguration-AdvancedConfiguration)" e na configuração padrão adotada pela RNP, porém cada instituição pode adequar esta configuração à sua realidade.



  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

Exemplos

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

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

OBS

A utilização do LDAPs apesar de recomendado, é opcional e a decisão de utilizar depende única e exclusivamente de cada instituição.


b) idp.authn.LDAP.trustCertificates:


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

OBS

Não se faz necessário a alteração desta variável, mas sim substituição do arquivo "ldap-server.crt" pelo arquivo de certificado que seja aceito pelo host do serviço de diretório, neste caso o Active Directory da instituição.

A variável %{idp.home} corresponde a pasta /opt/shibboleth-idp/

IMPORTANTE

A variável idp.authn.LDAP.trustCertificates só é considerada em caso de utilização do LDAPs, caso contrário a mesma será desconsiderada.


c) idp.authn.LDAP.returnAttributes:

 

idp.authn.LDAP.returnAttributes = sAMAccountName

OBS

Este atributo em geral se refere ao login do usuário no Active Directory


d) idp.authn.LDAP.baseDN:


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

OBS

Este atributo se refere a base de procura dos usuários na árvore do serviço de diretório da instituição

Outros Exemplos

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

IMPORTANTE

A instituição deve adequar esta variável de acordo com a configuração do seu serviço de diretório


e) idp.authn.LDAP.subtreeSearch:


idp.authn.LDAP.subtreeSearch = true

OBS

Esta opção habilita a procura recursiva na base configurada pela variável "idp.authn.LDAP.baseDN"


f) idp.authn.LDAP.userFilter:


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

OBS

Esta opção é o filtro de pesquisa do usuário


g) idp.authn.LDAP.bindDN:


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

OBS

Usuário utilizado para se integrar ao serviço de diretório

IMPORTANTE

o domínio "instituicao.br" deve ser substituído pelo domínio utilizado no serviço de diretório da instituição


 h) idp.authn.LDAP.bindDNCredential:


idp.authn.LDAP.bindDNCredential = senha_servico

OBS

Senha do usuário utilizado para se integrar ao serviço de diretório da instituição


i) idp.authn.LDAP.dnFormat:


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

OBS

String formatada para gerar o DN do usuário

IMPORTANTE

o domínio "instituicao.br" deve ser substituído pelo domínio utilizado no serviço de diretório da instituição


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:

Essa tela apresenta um erro no momento de validar os atributos. Normalmente acontece por conta das informações presentes do metadado do Idp (Servidor Idp da Instiutição), não estar igual ao metadado inserido no servidor da Chimarrão, ou CAFe.

Probelma:

Durante o login no WAYF retorna um erro no momento de homologação dos atributos. Ver Imagem acima.

Tratamento:

Solicitar a instituição o envio do "idp.crt" localizado no servidor Idp da instuituição cliente, no seguinte caminho; "/opt/shibbolet-idp/credentials/idp.crt". Após o envio pela instutição, abrir o arquivo e fazer o comparativo das informações. Acessar o Moka entrar nas configurações do cliente e comparar ambos os arquvios (Moka -> Idp.crt).

Solução:

Caso o arquivo eseteja diferente do Moka, deve-se alterar no Moka, usando a opção Modificar, as informações do metadado, copiando a chave do certificado do arquivo enviado pela instutição, idp.crt para a entrada no Moka. Após realizar a alteração não esquecer de entrar na opção Metadados no Moka e escolher a opção Salvar.

Solicitar a instutição que realize o reinicio do conteiner TOMCAT, orientado o comando a seguir; "~# systemctl restart tomcat"


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


Configuração do CAT-da-Eduroam
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"

Roteiro de atualização de atributos da Federação CAFé

1. Introdução

Este roteiro tem por objetivo validar a configuração do IdP na Federação CAFe.


2. Roteiro

2.1. Acesse a aplicação de testes em https://sp.rnp.br/cafe/

2.2. Selecionar seu Provedor de Identidade (IdP) no WAYF da Federação CAFe.



2.3. Autentique-se na página de login do seu Provedor de Identidade.



2.4. Verificar se houve sucesso no retorno dos atributos do usuário autenticado.

A página Homologação de atributos exibe a lista de atributos recebidos do IdP:



2.5. Faça um printscrean da tela que possui o teste de Homologação de Atributos e envie como resposta a este e-mail.


Roteiro de atualização de atributos da Federação Chimarrão


 

1. Introdução

 

Este roteiro tem por objetivo validar a configuração do IdP na Federação Chimarrão.


 

2. Roteiro

 

2.1. Acesse a aplicação de testes em https://sp.rnp.br/chimarrao/

 

2.2. Selecionar seu Provedor de Identidade (IdP) no WAYF da Federação Chimarrão.


 


 

2.3. Autentique-se na página de login do seu Provedor de Identidade.


 


 


 

2.4. Verificar se houve sucesso no retorno dos atributos do usuário autenticado.

 

A página Homologação de atributos exibe a lista de atributos recebidos do IdP:


 


 

2.5. Faça um printscrean da tela que possui o teste de Homologação de Atributos e envie como resposta a este e-mail.



Resposta sobre mensagem no navegador "sua conexão não é segura"


Esse problema ocorre porque o certificado do apache é auto-assinado, isso ocorre como padrão em uma instalação de um IDP da CAFe. Para resolver esse problema parcialmente é só você adicionar o acesso ao seu IDP em um exceção de segurança permanente, sendo que essa solução resolverá o problema máquina por máquina, ou seja, a cada navegador(browser) que tente acessar pela primeira vez o seu IDP terá que executar esse procedimento de exceção.
Para resolver permanentemente esse problema, você precisa usar um certificado válido no serviço do apache do servidor do IDP, gerado por uma certificadora reconhecida, como a "globalsign" ou "Certsign", por exemplo.







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

  • No labels

1 Comment

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


    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"

     

    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"/>