Page tree
Skip to end of metadata
Go to start of metadata

Este documento foi criado com base no guia de instalação do Shibboleth (IdP) V3 da SWITCHaai (Shibboleth Identity Provider (IdP) 3 Installation Guide).

Este documento descreve processo de instalação de um Fornecedor de Identidade Shibboleth IdP V3.4.4 e destina-se aos administradores de sistemas familiarizados com sistemas do tipo Unix e XML syntax, e possuir conhecimentos mínimos em:

  • Servidores Web Apache e Tomcat
  • Java
  • PostegresSQL
  • SSL

1.1 Requisitos do Sistema

Para a instalação da Shibboleth IdP V3 é recomendado um sistema com pelo menos 4GB de RAM.

São necessários os seguintes pacote de “software” para suporte à instalação:

sudo

Recomendado para executar comandos que implicam privilégios de root

curl e wget
Para download de software e ficheiros de configuração

OpenSSL
Utilizado para tratar dos certificados de servidor (camada de ssl para cifrar dados e criar certificados)

unzip

Para descompactar arquivos .zip

NTP
Sincronização de relógio do servidor.

NTP

É essencial que um IdP mantenha o relógio sincronizado, as mensagens de SAML incluem timestamps que são verificados pelos Fornecedores de Serviço (SP's). Quando o atraso é superior a 5min as mensagens são recusadas e os utilizadores impedidos de aceder aos serviços.

1.2 Instalação Apache, Tomcat e Postgres

Exemplos (idp.fccn.pt)

As instruções abaixo utilizam comandos para a instalação do Fornecedor de identidade com o hostname idp.fccn.pt, devem alterar os comandos para coincidir com o hostname do vosso IdP.

Abaixo seguem as instruções de instalação do Apache HTTP Server 2.4 , Apache Tomcat 9, e PostgreSQL9

O IdP Shibboleth 3.4.4  é uma aplicação desenvolvida em Java e requer um sistema que permita executar a "Java Virtual Machine". As recomendações de setup do IdP consistem nos seguintes componentes:

  • Apache HTTP Server 2.4 (desempenha as funções de “frontend” do “IdP”)
  • Apache Tomcat 9
  • PostgresSQL 9 (para armazenar os Identificadores persistentes e informação de consentimento do utilizador)


Pode efetuar o download dos ficheiros utilizados na parte da Instalação do Shibboleth IdP 3.4.4 aqui .

1.2.1 Instalação - Apache HTTP Server 2.4

Criar certificado de Frontend para o Apache

Recomendação Certificado Extended Validation

 Por se tratar de um componente de autenticação da instituição é recomendado que sejam utilizados certificados de servidor EV - Extended Validation.

Criar o CSR para realizar o pedido de certificado: 

Gerar CSR
openssl req -new -newkey rsa:4096 -nodes -out idp_fccn_pt.csr -keyout idp_fccn_pt.key -subj "/C=PT/ST=Lisboa/L=Lisboa/O=FCCN/CN=idp.fccn.pt"

Nota: alterar o O= <Nome da Organização em Protocolo TCS> e CN = <hostname do vosso idp>

Realizar pedido do certificado no Portal da Digicert

  • Portal Digicert: https://www.digicert.com/
  • Grave a chave privada (ex.: idp.fccn.pt.key) na seguinte localização: /etc/pki/tls/private
  • Grave os certificados DigiCertCA.crt  e idp.fccn.pt.crt na seguinte localização: /etc/pki/tls/certs/idp

Instalar e Configurar Apache

Instalar o Apache HTTP Server 2.4 com o seguinte comando:
sudo yum install httpd mod_ssl

Adicionar a configuração do VirtualHost para o IdP através da criação do ficheiro com o /etc/httpd/conf.d/idp.fccn.pt.conf seguinte conteúdo:

/etc/httpd/conf.d/idp.fccn.pt.conf
<VirtualHost *:443>
  ServerName idp.fccn.pt
  ServerAdmin idp-admin@fccn.pt
  CustomLog /var/log/httpd/idp.fccn.pt.access.log combined
  ErrorLog /var/log/httpd/idp.fccn.pt.error.log

  SSLEngine On
  SSLCipherSuite HIGH:MEDIUM:!aNULL:!kRSA:!MD5:!RC4
  SSLProtocol all -SSLv2 -SSLv3
  SSLCertificateKeyFile /etc/pki/tls/private/idp.fccn.pt.key
  SSLCertificateFile /etc/pki/tls/certs/idp/idp.fccn.pt.crt
  SSLCertificateChainFile /etc/pki/tls/certs/idp/idp.fccn.pt.ca.crt

  <IfModule headers_module>
  Header set X-Frame-Options DENY
  Header set Strict-Transport-Security "max-age=31536000 ; includeSubDomains"
  </IfModule>

  ProxyPass /idp ajp://localhost:8009/idp retry=5
  <Proxy ajp://localhost:8009>
    Require all granted
  </Proxy>

   CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
   ErrorLog logs/ssl_error_log

</VirtualHost>

Adicionar as seguintes opções ( para que não anuncie detalhes da versão ) no ficheiro /etc/httpd/conf/httpd.conf

/etc/httpd/conf/httpd.conf
ServerTokens Prod
ServerSignature off

Redirecionamento de pedidos http

Para efetuar um redirecionamento de pedidos vindos por http deverá adicionar ao ficheiro /etc/httpd/conf/httpd.conf

(Alterar o URL para o correspondente à sua Instituição)

/etc/httpd/conf/httpd.conf
Redirect permanent / https://URL/idp


Ativar o serviço HTTP e validar as configurações com os seguintes comandos:

sudo systemctl enable httpd.service
sudo apachectl configtest

Realizar um restart do serviço:

sudo systemctl restart httpd.service

1.2.2 Instalação do JAVA Servlet Container

Instalação do OpenJDK - Java 8

sudo yum install java-1.8.0-openjdk.x86_64


Validar a versão de JAVA que foi instalada:

java -version
 
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)


Editamos o ficheiro bash_profile de forma a configurar as variáveis de ambiente de forma permanente:

vi ~/.bash_profile


O caminho a colocar na variável JAVA_HOME pode ser visualizado listando o conteúdo da seguinte directoria:

ls -la /usr/lib/jvm/
drwxr-xr-x   3 root root 4096 Jul  9 16:09 .
dr-xr-xr-x. 39 root root 4096 Jul  9 16:09 ..
lrwxrwxrwx   1 root root   26 Jul  9 16:09 java -> /etc/alternatives/java_sdk
lrwxrwxrwx   1 root root   32 Jul  9 16:09 java-1.8.0 -> /etc/alternatives/java_sdk_1.8.0
lrwxrwxrwx   1 root root   40 Jul  9 16:09 java-1.8.0-openjdk -> /etc/alternatives/java_sdk_1.8.0_openjdk
drwxr-xr-x   7 root root   63 Jul  9 16:09 java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64
lrwxrwxrwx   1 root root   34 Jul  9 16:09 java-openjdk -> /etc/alternatives/java_sdk_openjdk
lrwxrwxrwx   1 root root   21 Jul  9 16:08 jre -> /etc/alternatives/jre
lrwxrwxrwx   1 root root   27 Jul  9 16:08 jre-1.8.0 -> /etc/alternatives/jre_1.8.0
lrwxrwxrwx   1 root root   35 Jul  9 16:08 jre-1.8.0-openjdk -> /etc/alternatives/jre_1.8.0_openjdk
lrwxrwxrwx   1 root root   51 Jul  9 16:08 jre-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64 -> java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre
lrwxrwxrwx   1 root root   29 Jul  9 16:08 jre-openjdk -> /etc/alternatives/jre_openjdk


A variável JAVA_HOME será /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre

Adicionamos a variável JAVA_HOME e IDP_SRC e alteramos a PATH de acordo com o seguinte:

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre
export IDP_SRC=/usr/local/src/shibboleth-identity-provider-3.4.4


PATH=$PATH:$HOME/bin


Correr o seguinte comando para que sejam inicializadas as variáveis definidas anteriormente:

. /root/.bash_profile

Instalação do Apache Tomcat 8

Por motivos de segurança. o Tomcat terá um utilizador sem privilégios (não root) para correr o serviço.

Primeiro, procedemos à criação do grupo tomcat:

groupadd tomcat

De seguida, criamos o utilizador tomcat. Adicionamos este utilizador ao grupo tomcat, com a home directory /opt/tomcat (onde iremos instalar o Tomcat) e com o parametro -s /bin/nologin de forma a não permitir login com esta conta:

useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat


Realizamos o download do binário do tomcat para a directoria /opt/tomcat/ 

wget http://www-eu.apache.org/dist/tomcat/tomcat-9/v9.0.24/bin/apache-tomcat-9.0.24.tar.gz


Descompactamos o binário e movemos o conteúdo para a directoria /opt/tomcat/ :

tar -xzvf apache-tomcat-9.0.24.tar.gz
mv apache-tomcat-9.0.24/* /opt/tomcat/


Damos privilégios ao user tomcat na directoria /opt/tomcat/:

chown -hR tomcat:tomcat /opt/tomcat/


Colocar o Tomcat a correr como serviço

Criamos e editamos o ficheiro tomcat.service :

sudo vi /etc/systemd/system/tomcat.service
tomcat.service
# Systemd unit file for tomcat
[Unit]
Description=Apache Tomcat 9 Web Application Container
After=syslog.target network.target
[Service]
Type=forking
Environment=JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre
Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/tomcat
Environment=CATALINA_BASE=/opt/tomcat
Environment='CATALINA_OPTS=-Xms512M -Xmx3072M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -XX:+DisableExplicitGC -XX:+UseParallelOldGC -Xms512M -Xmx3072M -Djava.security.egd=file:/dev/./urandom'
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID
User=tomcat
Group=tomcat
UMask=0007
RestartSec=10
Restart=always
[Install]
WantedBy=multi-user.target

Poderá alterar a alocação de memória especificada em JAVA_OPTS:

JAVA_OPTS="-Djava.awt.headless=true -XX:+DisableExplicitGC -XX:+UseParallelOldGC -Xms512m -Xmx3072m -Djava.security.egd=file:/dev/./urandom"

É recomendado alocar uma parte maior para o Tomcat (3072MB) e a restante (1024MB) para o OS e Apache.


Efectuamos um reload ao Systemd para carregar o ficheiro do Tomcat:

sudo systemctl daemon-reload


Fazemos com que o serviço Tomcat inicie com o SO e fazemos com que inicie: 

sudo systemctl enable tomcat
sudo systemctl start tomcat


Verificamos o status do serviço:

sudo systemctl status tomcat


O Tomcat ainda não está totalmente configurado, mas para testar poderá aceder à página default deste abrindo uma janela do browser e colocar o seguinte:

http://IP_SERVIDOR:8080

Adaptar as seguintes configurações no ficheiro: /opt/tomcat/conf/server.xml

  •  Comentar a seguinte elemento :

    /opt/tomcat/conf/server.xml
    <!-- <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> -->
  • Adicionar o conector AJP no porto 8009 adicionando o seguinte elemento:

    /opt/tomcat/conf/server.xml
        <!-- Define an AJP 1.3 Connector on port 8009 -->
        <Connector port="8009" protocol="AJP/1.3" redirectPort="443" address="127.0.0.1" enableLookups="false" tomcatAuthentication="false"/>
  • Desabilitar a integração automática de aplicações alterando o atributo autoDeploy="true" para autoDeploy="false"

    /opt/tomcat/conf/server.xml
    <Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="false"
  • Ativar a aplicação IdP Web na configuração do Tomcat

    Criar o ficheiro: /opt/tomcat/conf/Catalina/localhost/idp.xml

    Adicionar o seguinte contéudo ao ficheiro:

    /opt/tomcat/conf/Catalina/localhost/idp.xml
    <Context docBase="/opt/shibboleth-idp/war/idp.war" privileged="true" antiResourceLocking="false" swallowOutput="true"/>
  • Criar ou modificar o ficheiro: /opt/tomcat/conf/Catalina/context.xml para prevenir o erro "lack of persistent of the session objects" criado pelo IdP:

    /opt/tomcat/conf/Catalina/context.xml
    <Manager pathname="" />
  • Após efectuar as alterações deve reiniciar o serviço Tomcat:

    service tomcat restart

1.2.3 Instalação do PostgreSQL 9

Um Fornecedor de Identidade integrado na federação RCTSaai tem de utilizar uma base de dados pelas seguintes razões:

  • "User Consent" -  Utilizador autoriza olibertar de atributos por parte do “IdP”
  • "eduPersonTargetID" - Geração de um identificador persistente para cada serviço.


Para preparar o PostgreSQL para o IdP é necessário instalar os seguintes pacotes:

sudo yum install postgresql-server postgresql-jdbc
sudo postgresql-setup initdb
sudo systemctl enable postgresql.service
sudo systemctl start postgresql.service

Criar a BD e Propriedades

Criar um utilizador "shibboleth", a base de dados "shibboleth" e as tabelas "shibpid" e "storagerecords" com os seguintes comandos:

sudo -iu postgres psql <<EOF
CREATE ROLE shibboleth WITH LOGIN;
CREATE DATABASE shibboleth WITH OWNER shibboleth ENCODING 'UTF8' TEMPLATE template0;
\c shibboleth
SET ROLE shibboleth;
CREATE TABLE shibpid (
    localEntity VARCHAR(1024) NOT NULL,
    peerEntity VARCHAR(1024) NOT NULL,
    principalName VARCHAR(255) NOT NULL,
    localId VARCHAR(255) NOT NULL,
    persistentId VARCHAR(36) NOT NULL,
    peerProvidedId VARCHAR(255) NULL,
    creationDate TIMESTAMP NOT NULL DEFAULT LOCALTIMESTAMP,
    deactivationDate TIMESTAMP NULL DEFAULT NULL,
    PRIMARY KEY (localEntity, peerEntity, persistentId)
);
CREATE INDEX shibpid_getbysourcevalue_index ON shibpid(localEntity, peerEntity, localId, deactivationDate);
CREATE TABLE storagerecords (
    context VARCHAR(255) NOT NULL,
    id VARCHAR(255) NOT NULL,
    expires BIGINT DEFAULT NULL,
    value TEXT NOT NULL,
    version BIGINT NOT NULL,
    PRIMARY KEY (context, id)
);
CREATE INDEX storagerecords_expires_index ON storagerecords(expires);
EOF

Reiniciar o serviço postgresql:

sudo systemctl reload postgresql.service

Ativar as opções autovacuum e autoanalyze para garantir:

  • Que é realizada a limpeza dos dados marcados para remover
  • Os indices das tabelas atualizados de forma correta

Os valores padrão estão definidos com valores elevados ( pelo menos 20% e 10% dos dados de uma tabela tem de ser alterados para que possam disparar os procedimentos autocacuum e autoanalyze), como tal, é recomendado alterar estes valores para 0.2% e 0.1% respetivamente no ficheiro /var/lib/pgsql/data/postgresql.conf.

Não utilizar "large objects"

O IDP V3 "out-of-the box" irá utilizar "large objects"  para a coluna storagerecords.value sem ativar a opção do postgreSQL que permite realizar a gestão deste tipo de objetos, o que resultará em "large objects" orfãos e perda de dados se o comando vacuumlo for executado.

IMPORTANTE:  Para prevenir esta situação devem realizar o passo abaixo antes de iniciar o IdP pela primeira vez. 

/var/lib/pgsql/data/postgresql.conf
autovacuum_vacuum_scale_factor = 0.002  # fraction of table size before vacuum
autovacuum_analyze_scale_factor = 0.001 # fraction of table size before analyze


Reiniciar o serviço postgresql:

sudo systemctl reload postgresql.service


Backup diário da BD

É altamente recomendado ativar o backup da base de dados pelo menos uma vez por dia, permitindo em caso de emergencia realizar-se o "restore" com pequena ou nenhuma perda de dados.

Uma solução simples é a utilização do ficheiro /etc/cron.d/postgres-backup que utiliza o comando pg_dumpall (dump de todas as base dados):

Adicionar na pasta /etc/cron.d o ficheiro postgres-backup com o seguinte conteúdo:

/etc/cron.d/postgres-backup
# Cria um dump diario as 4:40 e cria o respetivo ficheiro comprimido (ex.: dumpall-Mon.sql.gz)
40 4 * * * postgres pg_dumpall | gzip > /var/lib/pgsql/backups/dumpall-`date +\%a`.sql.gz

# Backup adicional diario 
20 * * * * postgres pg_dumpall | gzip > /var/lib/pgsql/backups/dumpall-latest.sql.gz

1.3 Instalação do Shibboleth IdP

Realizar o download e descompactar o shibboleth:

[ -d /usr/local/dist ] || sudo mkdir /usr/local/dist
cd /usr/local/dist
sudo curl -O https://shibboleth.net/downloads/identity-provider/3.4.4/shibboleth-identity-provider-3.4.4.tar.gz
sudo tar -zxf shibboleth-identity-provider-3.4.4.tar.gz


Para realizar uma instalação devem utilizar o ficheiro pré formatado existente neste espaço:

Não usar o ficheiro de instalação da versão anterior.


Copiar o ficheiro idp-install.sh para a pasta /usr/local/dist e executar o seguinte comando:

sudo bash idp-install.sh shibboleth-identity-provider-3.4.4

O script irá perdir dois paramêtros:

  • home organization: deve corresponder ao valor scope ( dominio, ex.: fccn.pt )
  • IdP name: hostname do IdP  (ex.: idp.fccn.pt)

Please enter the name of your home organization [example.org]: fccn.pt
Please specify the service name for your IdP [aai-login.example.org]: idp.fccn.pt

Proceed with the installation using the following parameters?

Service name:             idp.fccn.pt
Home organization name:   fccn.pt
Installation directory:   /opt/shibboleth-idp

Enter 'yes' to continue: yes

Warning: /opt/shibboleth-idp/bin does not exist.
Warning: /opt/shibboleth-idp/dist does not exist.
Warning: /opt/shibboleth-idp/doc does not exist.
Warning: /opt/shibboleth-idp/system does not exist.
Warning: /opt/shibboleth-idp/webapp does not exist.
Creating cookie encryption key files...
...done
Rebuilding /opt/shibboleth-idp/war/idp.war ...
...done

BUILD SUCCESSFUL
Total time: 4 seconds

Creating self-signed certificate...
...done

O script idp-install.sh também altera permissões de alguns ficheiros e diretorias, devem verificar estas alterações utilizando o seguinte comando:

ls -ld /opt/shibboleth-idp/{conf/credentials.properties,credentials/{*.key,sealer.*},logs,metadata}

O resultado deve ser semelhante ao descrito abaixo:

-rw------- 1 tomcat root 1675 Mar 25 13:05 /opt/shibboleth-idp/conf/credentials.properties
-rw------- 1 tomcat root 1675 Mar 25 13:05 /opt/shibboleth-idp/credentials/idp.key
-rw-r--r-- 1 tomcat root  500 Mar 25 13:05 /opt/shibboleth-idp/credentials/sealer.jks
-rw-r--r-- 1 tomcat root   47 Mar 25 13:05 /opt/shibboleth-idp/credentials/sealer.kver
drwxr-xr-x 2 tomcat root 4096 Mar 25 13:05 /opt/shibboleth-idp/logs
drwxr-xr-x 2 tomcat root 4096 Mar 25 13:05 /opt/shibboleth-idp/metadata

Alterar as seguintes configurações no ficheiro  /var/lib/pgsql/data/pg_hba.conf de acordo com o seguinte:

Reiniciar o serviço postgresql:

sudo systemctl reload postgresql.service


1.4 Ativar o processo de criação de ID's persistentes (SAML 2 NameID)

Para ativar o processo de criação de ID's persistentes são necessárias as seguintes alterações:

  • No ficheiro /opt/shibboleth-idp/conf/saml-nameid.xml remover os comentário do elemento shibboleth.SAML2PersistentGenerator:

    /opt/shibboleth-idp/conf/saml-nameid.xml

    <!-- SAML 2 NameID Generation -->

    <util:list id="shibboleth.SAML2NameIDGenerators">

            <ref bean="shibboleth.SAML2TransientGenerator" />

            <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->

            <ref bean="shibboleth.SAML2PersistentGenerator" />

         [...]

    </util:list>

  • No ficheiro /opt/shibboleth-idp/conf/saml-nameid.properties alterar as seguinte propriedades de acordo com o definido abaixo:

    /opt/shibboleth-idp/conf/saml-nameid.properties

    #idp.persistentId.generator = shibboleth.ComputedPersistentIdGenerator
    idp.persistentId.generator = shibboleth.StoredPersistentIdGenerator

    #ALTERADO: For basic use, set this to a JDBC DataSource bean name:
    idp.persistentId.dataSource = shibboleth.PostgreSQLDataSource

    # ALTERADO: For computed IDs, set a source attribute and a secret salt

    #  Caso seja um OpenLDAP devem indicar:  idp.persistentId.sourceAttribute = uid

    idp.persistentId.sourceAttribute = sAMAccountName

  • No ficheiro /opt/shibboleth-idp/conf/c14n/subject-c14n.xml remover o comentário do elemento c14n/SAML2Persistent:

    /opt/shibboleth-idp/conf/c14n/subject-c14n.xml

    <!-- Handle a SAML 2 persistent ID, provided a stored strategy is in use. -->

    <ref bean="c14n/SAML2Persistent" />

No ficheiro /opt/shibboleth-idp/conf/idp.properties:

Deverá colocar as propriedades de acordo com o seguinte:

/opt/shibboleth-idp/conf/idp.properties

idp.session.StorageService = shibboleth.JPAStorageService

idp.consent.StorageService = shibboleth.JPAStorageService


idp.consent.attribute-release.userStorageKey= shibboleth.consent.AttributeConsentStorageKey
idp.consent.attribute-release.userStorageKeyAttribute= %{idp.persistentId.sourceAttribute}

Gerar o salt e adicionar uma nova linha no ficheiro credentials.properties:

openssl rand -base64 36

No ficheiro credentials.properties

/opt/shibboleth-idp/conf/credentials.properties
idp.persistentId.salt = <valor do salt gerado atraves do comando openssl>

No attribute-resolver-rctsaai-core.xml (a ser configurado no ponto 2.5) está definida a AttributeDefinition para o sAMAccountName necessária para o correcto funcionamento do consentimento de atributos e dos termos de uso.

1.5 Configurar a Página de Status do IdP

A página de estado do IdP depende do JSP Standard Tag Library (JSTL) que não está incluída na distribuição do Shibboleth IdP.

Para ativar este recurso é necessário realizar o download do ficheiro jstl-1.2.jar para o diretório /opt/shibboleth-idp/edit-webapp/WEB-INF/lib, e recriar o arquivo idp.war:

cd /opt/shibboleth-idp/edit-webapp/WEB-INF/lib
sudo curl -O https://repo1.maven.org/maven2/jstl/jstl/1.2/jstl-1.2.jar
sudo JAVACMD=/usr/bin/java /opt/shibboleth-idp/bin/build.sh -Didp.target.dir=/opt/shibboleth-idp


Devem obter um resultado semelhante ao descrito abaixo:

Warning: JAVA_HOME environment variable is not set.
  If build fails because sun.* classes could not be found
  you will need to set the JAVA_HOME environment variable
  to the installation directory of java.
Rebuilding /opt/shibboleth-idp/war/idp.war ...
...done

BUILD SUCCESSFUL
Total time: 3 seconds


Para assegurar que a informação de estado do IdP apenas está disponivel para determinados endereços ip's é necessário alterar a definição shibboleth.IPRangeAccessControl no ficheiro /opt/shibboleth-idp/conf/access-control.xml 

/opt/shibboleth-idp/conf/access-control.xml
[...]

    <!-- Map of access control policies used to limit access to administrative functions. -->

    <!--
    The only built-in implementation of the AccessControl interface is IP-based, as below.
    The ranges provided MUST be CIDR network expressions. To specify a single address,
    add "/32" or "/128" for IPv4 or IPv6 respectively.
    -->

   <util:map id="shibboleth.AccessControlPolicies">

        <entry key="AccessByIPAddress">
            <bean parent="shibboleth.IPRangeAccessControl"
   p:allowedRanges="#{ {'127.0.0.1/32', '::1/128' , '193.136.44.0/24','2001:690:2080:8009::/64' } }" />
        </entry>

    </util:map>
</beans>

Após efectuar as alterações deve reiniciar o serviço Tomcat:

service tomcat restart

1.6 Workaround "Large Objects" - (Não executar o IdP pela primeira vez sem realizar esta alteração)

O IDP V3 "out-of-the box" irá utilizar "large objects"  para a coluna storagerecords.value sem ativar a opção do postgreSQL que permite realizar a gestão deste tipo de objetos, o que resultará em "large objects" orfãos e perda de dados se o comando vacuumlo for executado.

Para evitar esta situação devem realizar o download do ficheiro: orm.xml



  • Adicionar o ficheiro na directoria /opt/shibboleth-idp/edit-webapp/WEB-INF/classes/META-INF:

    sudo mkdir -p /opt/shibboleth-idp/edit-webapp/WEB-INF/classes/META-INF
    cd /opt/shibboleth-idp/edit-webapp/WEB-INF/classes/META-INF/
    

Realizar o rebuild do ficheiro idp.war para incluir as alterações:

sudo JAVACMD=/usr/bin/java /opt/shibboleth-idp/bin/build.sh -Didp.target.dir=/opt/shibboleth-idp

Após efectuar as alterações deve reiniciar o serviço Tomcat:

service tomcat restart

1.7 Importar Libraries (JARs) utilizadas pelo Tomcat e pelo Shibboleth

Deverá copiar as seguintes libraries para as respectivas directorias:

cp /usr/share/java/postgresql-jdbc.jar /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/
cp /usr/share/java/postgresql-jdbc.jar /opt/tomcat/lib/
cp /opt/tomcat/lib/tomcat-jdbc.jar /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/
 



Instalar as libraries Tomcat Common Pool utilizadas para gerar o saml-id:

cd /usr/local/src/
wget https://www.apache.org/dist/commons/pool/binaries/commons-pool2-2.4.2-bin.tar.gz
tar xzvf commons-pool2-2.4.2-bin.tar.gz
cd commons-pool2-2.4.2/
cp commons-pool2-2.4.2.jar /opt/shibboleth-idp/edit-webapp/WEB-INF/lib


• Colocar as seguintes libraries na directoria /opt/tomcat/lib/:

commons-pool.jar

commons-dbcp.jar

• Colocar a seguinte library na directoria /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/ :

sqljdbc42.jar



Realizar o rebuild do ficheiro idp.war para incluir as alterações:

sudo JAVACMD=/usr/bin/java /opt/shibboleth-idp/bin/build.sh -Didp.target.dir=/opt/shibboleth-idp

Após efectuar as alterações deve reiniciar o serviço Tomcat:

service tomcat restart