Fornecedor de Serviço Shibboleth 3.2.2 para Debian

O Shibboleth é um pacote de software Open Source com mais expressão e utilização desenvolvido pela Internet2 que consiste em três componentes distintos: “Identity Provider”( IdP), “Service Provider” (SP), e “Discovery Service” (DS).

O “Service Provider” é responsável por controlar o acesso a serviços e recursos com base em atributos recebidos do “Identity Provider”. O Shibboleth Service Provider é desenvolvido em C++ e suportado por diversos sistemas (Linux, Mac OS X, Solaris, Windows)

Nesta página vamos explicar como instalar e configurar um SP Shibboleth 3.2.2 em Debian 11.

Contacto

Para questões relacionadas com o componente Service Provider , envie uma mensagem de correio electrónico para rctsaai@fccn.pt.

1 Pré-Requisitos

Antes de dar inicio à instalação e configuração do “Service Provider” é necessário verificar se os seguintes pré-requisitos estão assegurados:

Sudo Permite ao utilizador executar comandos com privilégios de root
OpenSSL apt install openssl

Utilizado para tratar dos certificados de servidor (camada de SSL para cifrar dados e criar certificados)
NTP apt install ntp

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

2 FIREWALL - CONFIGURAÇÃO

Os portos 443 (https) e 80 (http) devem ser abertos na firewall (iptables). Para isso, adicione a seguinte linha antes da palavra COMMIT:

-A INPUT -m state --state NEW -m tcp -p tcp -m multiport --dports 80,443 -j ACCEPT

Reinicie a firewall para que as novas regras sejam aplicadas

3 CERTIFICADOS SSL

Devem ser criados dois certificados SSL com o objectivo de preservar a confidencialidade dos dados utilizados na comunicação entre o SP, IDP e o browser do cliente.

O SP Web Server (Apache) deve gerir as suas próprias chaves e certificados para estabelecer ligações TLS/SSL com o browser do cliente. Apesar de tecnicamente possível que o software do SP utilize o mesmo par de chaves e certificados do Web Server para comunicar com o “Identity Provider”, não é recomendado que sejam utilizados os mesmos por razões de segurança.

Figura 1 – Utilização de certificados entre o browser do utilizador e o Service Provider e entre o Identity Provider e o Servide Provider

Devem ser gerados os seguintes certificados:

Certificado do Shibboleth-SP: Utilizado configuração do SP para gerar o ficheiro de metadados do SP. (Mais informação em TODO).
Certificado do Apache HTTP Server: Utilizada na configuração do Virtual Host. (Mais informação em TODO).

4 Apache HTTP server

4.1 Instalar Apache HTTP server

Para instalar o Apache HTTP Server 2.4 execute o seguinte comando:

apt install apache2

Para a configuração do SP, o necessita de instalar os seguintes módulos shib e php7.4 para o Apache:

apt install libapache2-mod-shib
apt install libapache2-mod-php

Ative os módulos ssl, rewrite, shib e php7.4:

a2enmod ssl
a2enmod rewrite
a2enmod shib
a2enmod php7.4

E execute o seguinte comando para as modificações terem efeito:

systemctl reload apache2

4.2 Configurar Apache HTTP server

Nesta secção será explicado como configurar o Servidor Apache para funcionar com o Shibboleth SP.

4.2.1 Certificados

Os serviços devem utilizar certificados válidos emitidos por uma entidade certificadora reconhecida. Um certificado reconhecido garante que o site é seguro e confiável através da criação de um canal criptográfico entre um servidor web e um browser.

Crie a diretoria /etc/certs/

Na diretoria /etc/certs/, crie o CSR para realizar o pedido de certificado:

shell> openssl req -new -newkey rsa:2048 -nodes -out sp_fccn_pt.csr -keyout sp_fccn_pt.key -subj "/C=PT/ST=Lisboa/L=Lisboa/O=FCCN/CN=sp-lab.fccn.pt"

Adaptar o comando alterando a seguinte informação: * O = ``Deve corresponder ao nome da vossa Organização em Protocolo TCS`` * CN = ``Deve corresponder ao hostname do vosso SP`` * Nomes dos ficheiros sp_fccn_pt.csr e sp_fccn_pt.key de acordo com o hostname do vosso sp.

TODO: Mais informações em Serviço RCTS Certificados

Após a execução deste comando são gerados dois ficheiros: • sp_fccn_pt.key: corresponde à chave Privada do Certificado • sp_fccn_pt.csr: este ficheiro é utilizado para realizar o pedido de emissão de certificado.

Aceda ao Portal da Sectigo e realize o pedido do certificado. Depois do certificado ter sido emitido no portal, deve gravar os certificados sp-lab_fccn_pt_interm.cer e sp-lab_fccn_pt_cert.cer na diretoria /etc/certs/.

4.2.2 Configurar VirtualHost

Adicionar a configuração do VirtualHost para o serviço através da criação do ficheiro /etc/apache2/sites-available/sp-lab.fccn.pt.conf com o seguinte conteúdo:

<VirtualHost sp-lab.fccn.pt:80>
        ServerName sp-lab.fccn.pt
        Redirect permanent / https://sp-lab.fccn.pt/
        LogLevel warn
        ErrorLog /var/log/apache2/ssl_error_log
        TransferLog /var/log/apache2/ssl_access_log
</VirtualHost>

<VirtualHost sp-lab.fccn.pt:443>
        DocumentRoot /var/www/html/sp-lab
        ServerName sp-lab.fccn.pt
        ServerAdmin sp-shibboleth@fccn.pt
        LogLevel warn
        ErrorLog /var/log/apache2/ssl_error_log
        TransferLog /var/log/apache2/ssl_access_log
        SSLEngine on
        SSLProtocol all -SSLv2 -SSLv3
        SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS
        SSLHonorCipherOrder on
        SSLCompression off
        SSLCertificateKeyFile /etc/certs/sp_fccn_pt.key
        SSLCertificateFile /etc/certs/sp-lab_fccn_pt_cert.cer
        SSLCertificateChainFile /etc/certs/sp-lab_fccn_pt_interm.cer
         <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
        </Directory>
        <Location />
                AuthType shibboleth
                ShibRequestSetting requireSession 1
                require valid-user
        </Location>

 </VirtualHost>

Ative o serviço apache2 e valide as configurações:

systemctl enable httpd.service
apachectl configtest

5 Shibboleth SP - Instalação e Configuração

Nesta secção vamos explicar como configurar o SP.

5.1 Instalação do Shibboleth SP

Execute os seguintes comandos:

apt install shibboleth-sp-common
apt install shibboleth-sp-utils
apt install libapache2-mod-shib
apt install libapache2-mod-php

Após a instalação do pacote do SP é necessário efetuar um start e enable do daemon shibd:

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

5.1.1 Directorias disponíveis após instalação

Após a instalação do Fornecedor de Serviço Shibboleth (SP) foram criadas as seguintes diretorias:

/etc/shibboleth Diretoria que contém os ficheiros de configuração do Shibboleth SP. O principal ficheiro de configuração é shibboleth2.xml.
/var/log/shibboleth Diretoria onde são armazenados os logs. O ficheiro de log mais importante é o shibd.log.
/run/shibboleth É a diretoria de Runtime onde os ID e os ficheiros de socket dos processos são guardados.
/var/cache/shibboleth Diretoria de cache onde são armazenados os ficheiros de backup da metadata e a listagem de certificados revogados pelo serviço SP.

5.1.2 Testes após instalação

Após a instalação execute os seguintes testes para validar a correta instalação do Fornecedor de Serviços:

Validar Shibboleth SP Execute o seguinte comando de forma a validar se o SP consegue efetuar o carregamento da configuração: sudo shibd -t

É importante a última linha do output ser:
```
overall configuration is loadable, check console for non-fatal problems
```
Validar a configuração do Apache Teste a configuração do Apache executando o comando:
```
sudo apachectl configtest
```
O output deverá ser:
```
Syntax OK
```

5.2 Configuração do Shibboleth SP

A configuração geral do Service Provider encontra-se no ficheiro shibboleth2.xml e de forma geral os elementos principais a configurar são os seguintes:

Serviços Identificar as aplicações que o Service Provider controla o acesso
Metadados - Identificar o ficheiro de metadados da federação que o SP deve utilizar

Estrutura do serviço a configurar:

Zona Publica

O acesso à pagina publica e respectivos conteúdos públicos encontra-se em /var/www/html/sp-lab/public
Zona Privada

Em /var/www/html/sp-lab/private podemos encontrar todos os ficheiros com acesso restrito a utilizadores autenticados.

5.2.1 Criar certificados para o Shibboleth SP

O daemon Shibboleth (shibd) necessita de um certificado X.509 para assinar e cifrar mensagens SAML. É recomendado usar um certificado self-signed, que é configurado de forma independente ao certificado SSL/TLS utilizado pelo web server.

Já foi criado um certificado ao instalar o pacote do SP. Para gerar um novo certificado e a chave privada execute o seguinte comando:

/usr/sbin/shib-keygen -f -u _shibd -h sp-lab.fccn.pt -y 3 -e https://sp-lab.fccn.pt -o /etc/shibboleth/

5.2.2 shibboleth2.xml

<ApplicationDefaults .../>

Este elemento é responsável por mapear os serviços por hostname onde o “Service Provider” controla o acesso
<SSO entityID …/>

Este elemento é responsável por identificar o Fornecedor de Identidade (login.ciencia-id.pt) para o qual o serviço deve redirecionar os utilizadores que não se encontram autenticados.
<MetadataProvider …/> Este elemento é responsável por identificar o ficheiro de metadados da federação que o Service Provider deve utilizar.

5.2.3 Metadados da Federação

Nesta configuração, para guardar os metadados das federações foi criada a diretoria /etc/shibboleth/metadata.

Para adicionar os metadados da federação RCTSaai, adicione o seguinte bloco no ficheiro shibboleth2.xml:

        <MetadataProvider type="XML" validate="true"
               url="https://registry.rctsaai.pt/rr/signedmetadata/federation/rctsaai/metadata.xml"
              backingFilePath="/etc/shibboleth/metadata/metadata.xml" maxRefreshDelay="7200">
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
            <MetadataFilter type="Signature" certificate="metadatasigner-rctsaai.pem" verifyBackup="false" />
        </MetadataProvider>

Esta configuração permite que o SP utilize o ficheiro de metadados remoto da federação RCTSaai. Em caso de falha utiliza o ficheiro local que se encontra em actualização periódica.

Para descarregar periodicamente o ficheiro de metadados para o filesystem é utilizado um cronjob. Deve criar a diretoria /etc/shibboleth/scripts e criar o ficheiro refresh_metadata.sh com o seguinte conteúdo:

#!/bin/sh 
rm -f /etc/shibboleth/rctsaai/<nome_do_ficheiro_de_metadados>.xml 
cd / etc/shibboleth/rctsaai/ 
wget -O / etc/shibboleth/rctsaai/<nome_do_ficheiro_de_metadados>.xml 
<url_para_os_metadados_da_instituicao>.xml

Dê permissões de execução a este ficheiro e verifique a sua boa execução.

Para executar de trinta em trinta minutos é necessário editar a cron

crontab -e

E adicionar as seguintes linhas:

#Refresh Metadata 
30 * * * * /scripts/cron/refresh_metadata.sh &> /dev/null

5.2.4 Metadados do SP

Para adicionar o Service Provider no ficheiro de metadados da federação é necessário enviar a respectiva informação para rctsaai@fccn.pt.

Para obter os metadados do Service Provider deve aceder ao seguinte link:

https://<nome_do_sp>.pt/Shibboleth.sso/Metadata

5.2.3 Exemplo do ficheiro shibboleth2.xml

Segue um exemplo de configuração do ficheiro shibboleth2.xml. Neste caso o SP redireciona o utilizador para o WAYF de desenvolvimento da FCCN.

<SPConfig xmlns="urn:mace:shibboleth:3.0:native:sp:config"
    xmlns:conf="urn:mace:shibboleth:3.0:native:sp:config"
    clockSkew="180">

    <OutOfProcess tranLogFormat="%u|%s|%IDP|%i|%ac|%t|%attr|%n|%b|%E|%S|%SS|%L|%UA|%a" />

    <!--
    By default, in-memory StorageService, ReplayCache, ArtifactMap, and SessionCache
    are used. See example-shibboleth2.xml for samples of explicitly configuring them.
    -->

    <!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
    <ApplicationDefaults entityID="https://sp-lab.fccn.pt"
        REMOTE_USER="eppn subject-id pairwise-id persistent-id"
        cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1">

        <!--
        Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
        Each Application has an effectively unique handlerURL, which defaults to "/Shibboleth.sso"
        and should be a relative path, with the SP computing the full value based on the virtual
        host. Use of TLS is now assumed because browsers are enforcing it due to SameSite
        restrictions. Note that while we default checkAddress to "false", this makes an assertion
        stolen in transit easier for attackers to misuse.
        -->
       <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
                  checkAddress="false" handlerSSL="true" cookieProps="https"
                  redirectLimit="exact">

            <!--
            Configures SSO for a default IdP. To properly allow for >1 IdP, remove
            entityID property and adjust discoveryURL to point to discovery service.
            You can also override entityID on /Login query string, or in RequestMap/htaccess.
            -->
            <SSO discoveryProtocol="SAMLDS" discoveryURL="https://wayf.fccn.pt/FCCNdesenvolvimento">
              SAML2
            </SSO>

            <!-- SAML and local-only logout. -->
            <Logout>SAML2 Local</Logout>

            <!-- Administrative logout. -->
            <LogoutInitiator type="Admin" Location="/Logout/Admin" acl="127.0.0.1 ::1" />

            <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
            <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>

            <!-- Status reporting service. -->
            <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>

            <!-- Session diagnostic service. -->
            <Handler type="Session" Location="/Session" showAttributeValues="false"/>

            <!-- JSON feed of discovery information. -->
            <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
        </Sessions>

        <!--
        Allows overriding of error template information/filenames. You can
        also add your own attributes with values that can be plugged into the
        templates, e.g., helpLocation below.
        -->
        <Errors supportContact="root@localhost"
            helpLocation="/about.html"
            styleSheet="/shibboleth-sp/main.css"/>

        <!-- Example of locally maintained metadata. -->
        <!--
        <MetadataProvider type="XML" validate="true" path="partner-metadata.xml"/>
        -->

        <!-- Example of remotely supplied batch of signed metadata. -->
        <MetadataProvider type="XML" validate="true"
                url="https://registry.rctsaai.pt/rr/signedmetadata/federation/rctsaai/metadata.xml"
              backingFilePath="/etc/shibboleth/metadata/metadata.xml" maxRefreshDelay="7200">
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
            <MetadataFilter type="Signature" certificate="metadatasigner-rctsaai.pem" verifyBackup="false" reloadInterval="60"/>
        </MetadataProvider>

        <!-- Example of remotely supplied "on-demand" signed metadata. -->
        <!--
        <MetadataProvider type="MDQ" validate="true" cacheDirectory="mdq"
                baseUrl="http://mdq.federation.org" ignoreTransport="true">
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
            <MetadataFilter type="Signature" certificate="mdqsigner.pem" />
        </MetadataProvider>
        -->

        <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>

        <!-- Default filtering policy for recognized attributes, lets other data pass. -->
        <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>

        <!-- Simple file-based resolvers for separate signing/encryption keys. -->
        <CredentialResolver type="File" use="signing"
            key="sp-key.pem" certificate="sp-cert.pem"/>
        <CredentialResolver type="File" use="encryption"
            key="sp-key.pem" certificate="sp-cert.pem"/>

    </ApplicationDefaults>

    <!-- Policies that determine how to process and authenticate runtime messages. -->
    <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>

    <!-- Low-level configuration about protocols and bindings available for use. -->
    <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>

</SPConfig>

5.3 Atributos

Todos os atributos recebidos do “Identity Provider” são mapeados nos Headers HTTP e transferidos para a aplicação que o Service Provider está a proteger. Anteriormente ao mapeamento de valores, os atributos são filtrados e desta forma são avaliados quais os atributos a aceitar. Para cada atributo aceite é necessário identificar o header em que este deve ser mapeado. No Service Provider existem dois ficheiros responsáveis pela configuração do mapeamento e filtragem de atributos, a saber:

Attribute-policy.xml - /etc/shibboleth/ - Ficheiro de configuração de filtros que determinam quais os atributos e valores a disponibilizar com base num conjunto de regras.
Attribute-map.xml - /etc/shibboleth/ - Ficheiro responsável pelo mapeamento dos atributos nos respectivos headers da aplicação.

O administrador do serviço em conjunto com a equipa de desenvolvimento deve identificar os atributos (com base nos schemas de eduperson e schac) que garantem as regras de controlo de acesso ao serviço. Os atributos escolhidos devem ser apresentados à federação (através de uma mensagem de correio electrónico para rctsaai@fccn.pt) para análise.

O mapeameno permite identificar os atributos (SAML1 e SAML2) provenientes do Identity Provider e em simultâneo atribuir o nome às variáveis de sessão que são utilizadas pela aplicação.

Ficheiro responsável pelo mapeamento dos atributos: /etc/shibboleth/attribute-map.xml

<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
  <!-- SAML1 Attributes -->   
  <Attribute name="urn:mace:dir:attribute-def:INETORGPERSON_MAIL" id="MAIL">   
  </Attribute> 

  <Attribute name="urn:mace:dir:attribute-def:PERSON_SURNAME" id="SURNAME">  

  </Attribute> 

  <Attribute name="urn:mace:dir:attribute-def:INETORGPERSON_GIVENNAME" id="GIVENNAME">   
  </Attribute> 

  <Attribute name="urn:mace:dir:attribute-def:ORGANIZATION" id="O">   
  </Attribute> 

  <!-- SAML2 -->   
  <Attribute name="urn:oid:0.9.2342.19200300.100.1.3" id="MAIL">   
  </Attribute> 

  <Attribute name="urn:oid:2.5.4.4" id="SURNAME">  
  </Attribute> 

  <Attribute name="urn:oid:2.5.4.42" id="GIVENNAME">   
  </Attribute> 

  <Attribute name="urn:oid:2.5.4.10" id="O">   
  </Attribute> 
</Attributes>

Para além das variáveis (atributos) mapeadas no ficheiro /etc/shibboleth/attribute-map.xml existem outras geradas pelo próprio Service Provider e que não podem ser renomeadas. Podemos visualizar estes atributos na tabela seguinte:

Atributo	Descrição
Shib-Application-ID	A ID da aplicação para o pedido.
Shib-Session-ID	O ID da sessão interna atribuída à sessão associada ao pedido.
Shib-Identity-Provider	O entityID do IdP que realizou a autenticação do utilizador associado ao pedido.
Shib-Authentication-Instant	Data/hora fornecida pelo IdP indicando a alçtura em que foi realizada a autenticação.
Shib-Authentication-Method	Método de Authenticação ou o valor (Identificador oid) fornecido pelo IdP, se existir.
Shib-AuthnContext-Class	Método de Authenticação ou o valor (Identificador oid) fornecido pelo IdP, se existir.
Shib-AuthnContext-Decl	O valor fornecido pelo IdP, se houver.
Shib-Handler	Localização base dos “handlers” do Service Provider para incluir nas aplicações quando solicitam pedidos de login, logout, etc.

5.4 Exemplos de Acesso aos atributos

Esta secção disponibiliza vários exemplos em diferentes linguagens para aceder aos atributos disponibilizados pelo Service Provider.

ASP.NET

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>SP-LAB Shibboleth</title>
</head>
<body>
<h1>SP-LAB Shibboleth</h1>
<table>
<tr>
<th>Atributo</th>
<th>Valor</th>
</tr>
<%
foreach (string key in Request.ServerVariables.AllKeys)
{
%>
<tr>
    <td><%=key %></td>
<td><%Request.ServerVariables[key]%></td>
</tr>
<%
}
%>
</table>
</body>
</html>

JAVA

Os atributos disponibilizados pelo Service provider têm por defeito o charset UTF-8, mas dependendo da configuração do servlet container são interpretados como valores ISO-8859-1, causando problemas com caracteres não ASCII. Como solução terá de ser feito o re-encode dos atributos.

Exemplo de re-encode para o atributo givenName:

String value= request.getHeader("givenName");value= new String( value.getBytes("ISO-8859-1"), "UTF-8");
Exemplo de um Servlet Java:
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Enumeration;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class SPLABSP extends HttpServlet {

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
    response.setContentType("text/html");

    PrintWriter out = response.getWriter();
    /* Resposta HTML */
    out.println("<html>");
    out.println("<head>");
    out.println("<title>SP LAB SHIBBOLETH</title>");
    out.println("</head>");
    out.println("<body>");
    out.println("<h1>SP LAB SHIBBOLETH</h1>");

    /* Atributos SAML provenientes do Ciencia ID a mostrar */
    String[] shib_attributes = {
        "cienciaid","mail","givenName","surname",
        "schacDateOfBirth","preferredLanguage","schacCountryOfCitizenship",
        "urlRedirect","schacGender","docnum",
        "user_is_active","nist_reg_atual","doc","authNist"
    };

    out.println("<h2>ATRIBUTOS SAML:</h2>");
    out.println("<table>");
    for (int i=0; i<shib_attributes.length; i++)
    {
        out.print("<tr><td>"+shib_attributes[i]+"</td>");
        out.print("<td>"+request.getAttribute(shib_attributes[i])+"</td></tr>\n");
    }
    out.println("</table>");
    /* Atributos do Service Provider a mostrar */   
    out.println("<h2>ATRIBUTOS:</h2>");
    out.println("<table>");
    Enumeration attributes = request.getAttributeNames();
    while ( attributes.hasMoreElements() )
    {
        String attr_name = (String) attributes.nextElement();
        Object attr_val  = request.getAttribute(attr_name);
         out.print("<tr><td>"+attr_name+"</td>");
        out.print("<td>"+attr_val+"</td></tr>\n");
    }

    out.println("</table>");
}
}

Segue um exemplo do tratamento de atributos enviados pelo IdP para o Serviço Ciência Vitae. Primeiro é validado se o atributo enviado pelo IdP tem o valor diferente de nulo e se tiver é assumido o valor enviado, senão toma o valor nulo. Desta forma podemos realizar algumas validações com base nos valores dos atributos ou então atribuir valores no caso de um atributo não tiver sido enviado pelo IdP ou ter o valor nulo.

httpReq.getAttribute("cienciaid") != null ?  httpReq.getAttribute("cienciaid").toString() : null;
httpReq.getAttribute("givenName") != null ? httpReq.getAttribute("givenName").toString() : null;
httpReq.getAttribute("surname") != null ? httpReq.getAttribute("surname").toString() : null;
httpReq.getAttribute("mail") != null ?  httpReq.getAttribute("mail").toString() : null;
httpReq.getAttribute("schacDateOfBirth") != null ?  httpReq.getAttribute("schacDateOfBirth").toString() : null;
httpReq.getAttribute("schacGender") != null ? httpReq.getAttribute("schacGender").toString() : null;
httpReq.getAttribute("preferredLanguage") != null ? httpReq.getAttribute("preferredLanguage").toString() : "Português";

Linguagem PHP

<?php
  require_once('/var/simplesamlphp/lib/_autoload.php');
  $as = new SimpleSAML_Auth_Simple('default-sp');
  $as->requireAuth();
  $attributes = $as->getAttributes();
?>
<html>
<head><title>SP-LAB Shibboleth</title></head>
<body>
<h1> SP-LAB Shibboleth </h1>
<h2>ATRIBUTOS:</h2>
<pre><?php print_r($attributes); ?></pre>
</body>
</html>

Após a alteração do ficheiro de configuração é necessário relançar o shibd, a saber:

[root@ ]# service shibd restart