A3.2.1 Sicurezza del canale¶

Nella Porta di dominio la sicurezza di canale è garantita dall’utilizzo del protocollo http over TLS (https), attraverso l’utilizzo del certificato emesso dalla CA spcoop.gov.it.

Rimossa la Porta di dominio le entità operanti il colloquio dovranno provvedere alla creazione di canali sicuri utilizzando il protocollo TLS, almeno nella versione 1.2, impiegando certificati di cui si dovranno dotare autonomamente. Si precisa che i certificati utilizzati per la creazione del canale sicuro devono essere emessi da una CA pubblica preferendo, ove possibile, l’impiego di Extended Validation Certificate.

La scelta dei terminatori di canale è demandata all’Amministrazione che potrà prevedere anche l’impiego di reverse proxy per tutti i servizi su cui terminare i canali cifrati.

A3.2.2 Gestione degli accessi¶

In merito al tema della gestione degli accessi, come previsto dalle Linee guida per transitare al nuovo modello di interoperabilità, “le amministrazioni erogatrici dovranno provvedere, tramite le proprie infrastrutture di gestione degli accessi, all’autorizzazione delle richieste di servizio nei confronti delle amministrazioni fruitrici”.

Per l’eliminazione della porta di dominio è indicata la scelta della sola mutua autenticazione di canale come sistema di autenticazione sulla base della quale operare l’autorizzazione alla fruizione dei servizi, in quanto, i possibili casi che si possono presentare sono:

• l’erogatore e il fruitore impiegano WS-Security senza l’intervento della Porta di dominio: l’esposizione diretta del servizio potrà continuare ad operare senza interventi;
• l’erogatore impiega WS-Security senza l’intervento della Porta di dominio, mentre il fruitore utilizza la Porta di dominio per la gestione della WS-Security: l’esposizione diretta del servizio potrà continuare ad operare senza interventi da parte dell’erogatore invece il fruitore dovrà effettuare un refactoring dell’aspetto di sicurezza del servizio finalizzato esclusivamente all’introduzione della gestione della WS-Security;
• l’erogatore e il fruitore impiegano WS-Security con l’intervento della Porta di dominio: l’utilizzo di TLS Mutua autenticazione da parte di ambedue permette l’esposizione diretta del servizio senza interventi;
• l’erogatore utilizza la Porta di dominio per la gestione della WS-Security, mentre il fruitore impiega WS-Security senza l’intervento della Porta di dominio: l’utilizzo di TLS Mutua autenticazione da parte di ambedue permette l’esposizione diretta del servizio senza interventi da parte dell’erogatore invece il fruitore dovrà effettuare un refactoring dell’aspetto di sicurezza del servizio finalizzato esclusivamente alla eliminazione della gestione della WS-Security;
• l’erogatore e il fruitore implementano l’autenticazione/autorizzazione attraverso la sicurezza di canale: mediante l’uso di TLS Mutua autenticazione gestita dalla Porta di dominio, potranno continuare ad operare configurando la mutua autenticazione sugli applicativi.

Nei precedenti punti si è indicato con “refactoring dell’aspetto di sicurezza del servizio”, l’insieme delle attività minime necessarie ad una amministrazione fruitrice di un servizio per preservare la comunicazione con l’erogatore che prevede, a seconda dei casi, l’aggiunta o l’eliminazione della gestione della WS-Security al servizio.

La seguente tabella sintetizza quanto descritto in precedenza.

Tabella A3.1 - Casi di autorizzazione alla fruizione di servizi

Quanto indicato in precedenza con “TLS Mutua autenticazione”, per realizzare l’autenticazione del fruitore è necessario che l’erogatore, una volta instaurata una connessione in mutua autenticazione in http over TLS (https) attraverso l’uso di certificati X509 V3, provveda a:

1. estrarre il DN (Distinguish Name) dal certificato utilizzato nell’handshake del TLS relativo all’amministrazione fruitrice;
2. estrarre il riferimento al servizio richiamato;
3. verificare se il fruitore, identificato dal DN, è autorizzato ad accedere al servizio.

A3.2.3 Tracciature¶

In merito al tema della gestione delle tracciature, come previsto dalle Linee guida per transitare al nuovo modello di interoperabilità”, si dovranno riportare i seguenti elementi minimi:

• data e ora della richiesta;
• entità richiedente il servizio;
• servizio richiesto;
• esito della chiamata (autorizzata/rigettata).

È sufficiente che l’amministrazione ritrovi e illustri, con apposita documentazione, le modalità adottate dalle piattaforme di erogazione utilizzate per tracciare le informazioni richieste. Un approccio alternativo richiederebbe che le amministrazioni provvedano alla realizzazione di componenti per la gestione della tracciatura.

La tracciatura potrà poi riportare eventuali altre informazioni peculiari al tipo di servizio erogato (tracciatura applicativa).

A3.2.4 Esempio¶

A titolo di esempio, nel listato rappresentato qui di seguito si riporta uno skeleton di codice per una possibile implementazione della gestione degli accessi e tracciatura, realizzato in ambiente JEE - JSR 53: Java Servlet 2.3 Specification.

public class ReadX509ClientCertFilter implements Filter {
  public void init(FilterConfig fConfig) throws ServletException {}
  public void destroy() {}

  private class EntitaRichiedente {
    String subjectDN;
    String issuerDN;

    public EntitaRichiedente(String subjectDN, String issuerDN) {
      super();
      this.subjectDN = subjectDN;
      this.issuerDN = issuerDN;
    }

    @Override
    public String toString() {
      return "EntitaRichiedente [subjectDN=" + subjectDN + ", issuerDN=" + issuerDN + "]";
    }
  }

  public void doFilter(ServletRequest request,
    ServletResponse response,
    FilterChain chain) throws IOException, ServletException {
    /*
     * Recupero elementi:
     * - data e ora della richiesta;
     * - entità richiedente il servizio;
     * - servizio richiesto;
     * - esito della chiamata (autorizzata/rigettata).
     */

    LocalDate dataOraRichiesta = LocalDate.now();
    EntitaRichiedente entitaRichiedente = getEntitaRichiedente(request);
    String servizioRichiesto = getServizioRichiesto(request);
    boolean esitoChiamata = checkAuth(entitaRichiedente,servizioRichiesto);
    traceRequest(dataOraRichiesta,entitaRichiedente,servizioRichiesto,esitoChiamata);
    chain.doFilter(request, response);
  }

  private void traceRequest(LocalDate dataOraRichiesta,EntitaRichiedente entitaRichiedente,
    String servizioRichiesto,boolean esitoChiamata) {
    // TODO Implementare Gestione della tracciatura
    /*
     * Ad esempio utilizzando un file di log dedicato per rendere persistenti le tracce
     */
  }

  private boolean checkAuth(EntitaRichiedente entitaRichiedente, String servizioRichiesto) {
    // TODO Implementare gestione degli accessi
    return true;
    /*
     * Ad esempio verificare l’esistenza della coppia
     * entitaRichiedente/servizioRichiesto su wallet di credenziali (LDAP, DBMS, ...)
     */
  }

  private EntitaRichiedente getEntitaRichiedente(ServletRequest request) {
    X509Certificate[] certs = (X509Certificate[])
    request.getAttribute("javax.servlet.request.X509Certificate");
    if (null != certs && certs.length > 0) {
      return new EntitaRichiedente(
        certs[0].getSubjectDN().getName(),
        certs[0].getIssuerDN().getName()
      );
    } else {
      throw new RuntimeException("No X.509 client certificate found in request");
    }
  }

  private String getServizioRichiesto(ServletRequest request) {
    return request.getScheme() + "://" +
    request.getServerName() + ":" +
    ((HttpServletRequest)request).getRequestURI();
  }
}