"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

1 - Crie o arquivo /tmp/openssl.cnf com o conteúdo a seguir. É possível fazer o download do arquivo acima através da seguinte linha de comando:

wget https://svn.rnp.br/repos/CAFe/conf/ssl/openssl.cnf -O /tmp/openssl.cnf --no-check-certificate

É necessário substituir a variável $HOSTNAME pelo hostname máquina (não utilizar o domínio, exe.: instituicao.br).
 

   ------------------------------------------------------------------------------------------
[ req ]
default_bits = 2048 # Size of keys
string_mask = nombstr # permitted characters
distinguished_name = req_distinguished_name
 
[ req_distinguished_name ]
# Variable name   Prompt string
#----------------------   ----------------------------------
0.organizationName = Nome da universidade/organização
organizationalUnitName = Departamento da universidade/organização
emailAddress = Endereço de email da administração
emailAddress_max = 40
localityName = Nome do município (por extenso)
stateOrProvinceName = Unidade da Federação (por extenso)
countryName = Nome do país (código de 2 letras)
countryName_min = 2
countryName_max = 2
commonName = Nome completo do host (incluíndo o domínio)
commonName_max = 64
 
# Default values for the above, for consistency and less typing.
# Variable name   Value
#------------------------------   ------------------------------
#0.organizationName_default =
organizationalUnitName_default = CPD - trocar
#localityName_default = Porto Alegre - trocar
#stateOrProvinceName_default = Rio Grande do Sul - trocar
countryName_default = BR - trocar
commonName_default = $HOSTNAME
   ------------------------------------------------------------------------------------------

2 - Para gerar o par chave/certificado para o Shibboleth, utilize os comandos no bloco abaixo:

-----------------
ATENÇÃO

    Confirme o código do País (BR)
    Unidade da federação (por extenso)
    Cidade (por extenso)
    Instituição (preferencialmente preencha com [ABREV - Nome por extenso])
    Departamento da instituição (preferencialmente preencha com [ABREV - Nome por extenso])
    Confirme que o Hostname está correto (nome DNS por extenso do host que será o IDP)
    Informe a senha, que é a palavra: changeit
-----------------

Siga os comandos abaixo:

cd /opt/shibboleth-idp/credentials/

rm -f idp*

openssl genrsa 2048 -config /tmp/openssl.cnf > idp.key

    Informe a senha, que é a palavra: changeit

openssl req -new -x509 -nodes -days 1095 -sha1 -key idp.key -set_serial 00 -config /tmp/openssl.cnf > idp.crt

3 - inserir o conteúdo do arquivo idp.crt descartando as linhas de begin e end, dentro do arquivo /opt/shibboleth-idp/metadata/idp-metadata.xml.

4 - fazer o restart do container do tomcat com o comando a seguir: initctl restart tomcat & tail -f /opt/shibboleth-idp/logs/idp-process.log

5 - enviar para sd@rnp.br o novo arquivo /opt/shibboleth-idp/metadata/idp-metadata.xml.

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.

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:

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:

Ver processos em execução:

Startar o tomcat:

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

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

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)

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:

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:

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

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

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:

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

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:

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

Como autenticar por uid ou email

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:

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:

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

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

obs. utilizar os parâmetros adicionais:

referral="follow"

userRoleAttribute="sAMAccountName"

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

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

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

3. Reiniciar Apache e Tomcat

Configuração para EduGain

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

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, entre as tags " <AttributeFilterPolicy "  e  " </AttributeFilterPolicy> "  colocar esses dois atributos:

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

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

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

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

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

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

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

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 O atributo utilizado para o login tem que obrigatoriamente estar declarado O atributo utilizado para o login tem que estar sendo liberado pelo idp na tag "ReturnAttributes" attribute-filter.xml 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)

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>

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: ~# initctl restart tomcat

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:

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

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

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:

5. Você pode acompanhar todo o processo através do 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:

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

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:

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:

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:

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

d) idp.authn.LDAP.baseDN:

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:

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

f) idp.authn.LDAP.userFilter:

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

g) idp.authn.LDAP.bindDN:

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:

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

i) idp.authn.LDAP.dnFormat:

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:

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

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