Single Sign On (SSO)

Federazione bilaterale delle identità per il passaggio trasparente tra applicazioni

Una federazione bilaterale delle identità è adatta quando non è necessario creare un dominio SSO completo, ma si vuole consentire un passaggio mirato e trasparente da un’applicazione A in cui la persona è già autenticata a un’applicazione B.

AGOV non viene né esteso né configurato specificamente. In particolare, non vengono creati domini SSO in AGOV e non vengono trasferite sessioni AGOV tra le applicazioni coinvolte.

Principio architetturale

AGOV autentica la persona fisica nei confronti dell’applicazione A o del relativo IAM. L’autenticazione già effettuata può poi essere utilizzata dall’applicazione A o dal suo IAM come base per rilasciare all’applicazione B una nuova asserzione di identità specificamente destinata a B.

La catena di fiducia è quindi la seguente:

AGOV
  |
  | autentica la persona fisica
  v
IAM / applicazione A
  |
  | rilascia all’applicazione B una propria
  | asserzione di identità destinata a B
  v
Applicazione B
  |
  | apre una propria sessione
  v
Applicazione di destinazione

Si creano due relazioni di fiducia separate:

• AGOV -> applicazione A
• Applicazione A / IAM A -> applicazione B

La seconda relazione di fiducia è gestita interamente al di fuori di AGOV.

Nessun riutilizzo dei token AGOV

L’applicazione B non considera attendibile un token AGOV originariamente rilasciato per l’applicazione A. Un token rilasciato per una determinata relying party non è automaticamente destinato a un’altra relying party. In particolare, il controllo dell’audience non deve essere indebolito per poter comunque accettare un simile token.

Non è quindi previsto il seguente modello:

AGOV
  |
  | token per l’applicazione A
  v
Applicazione A
  |
  +-> Applicazione B

Viene invece creata da A o dal suo IAM una nuova asserzione specifica per B:

AGOV
  |
  v
IAM A
  |
  | nuova asserzione firmata
  | Audience = applicazione B
  v
Applicazione B

L’autenticazione AGOV originaria costituisce soltanto la base sulla quale l’issuer dell’applicazione A rilascia la propria asserzione.

Ruoli

AGOV
AGOV autentica la persona fisica nell’ambito del processo di login esistente dell’applicazione A. AGOV non deve sapere che la persona accederà successivamente all’applicazione B, quali applicazioni sono federate tra loro, quale sessione verrà creata nell’applicazione B o quale asserzione di identità l’applicazione A rilascerà in seguito a B.

Issuer dell’applicazione A
L’issuer è l’ancora di fiducia tecnica e organizzativa sul lato dell’applicazione A. Idealmente si tratta di un IAM o di un Security Token Service e non di codice applicativo generico. L’issuer può rilasciare asserzioni di identità per l’applicazione B soltanto sulla base di una sessione autenticata valida.

Applicazione B
L’applicazione B mantiene un elenco degli issuer espressamente autorizzati. Verifica integralmente ogni asserzione di identità ricevuta e crea quindi una propria sessione applicativa. Non è necessario che l’applicazione B conosca già la persona interessata.

Esempio di flusso

1. La persona è già connessa all’applicazione A. L’autenticazione sottostante può, ad esempio, essere avvenuta tramite AGOV. Dopo un’autenticazione riuscita, l’IAM A dispone di una propria sessione.


2. La persona seleziona nell’applicazione A una funzione che conduce all’applicazione B. L’applicazione A riconosce la sessione esistente e richiede al proprio issuer un’asserzione di identità specificamente destinata all’applicazione B.


3. L’issuer genera un’asserzione firmata crittograficamente. Essa contiene soltanto le informazioni concordate necessarie a B ed è espressamente destinata a B. Può contenere, ad esempio, issuer, audience, subject, istanti di emissione e scadenza, un identificatore univoco della transazione, l’istante dell’autenticazione sottostante e le informazioni concordate relative all’identità e alla qualità.


4. L’asserzione di identità viene preferibilmente trasmessa lato server all’applicazione B. La connessione può essere ulteriormente protetta mediante autenticazione TLS reciproca (mTLS).

In questo modo si possono combinare due meccanismi di sicurezza indipendenti:

Livello di trasporto:
La controparte chiamante è effettivamente il client tecnico registrato?

e

Livello del messaggio:
L’asserzione di identità è stata effettivamente firmata dall’issuer registrato?

Validazione da parte dell’applicazione B

L’applicazione B accetta l’asserzione di identità soltanto se tutti i controlli previsti hanno esito positivo. Occorre in particolare verificare che:

• il client tecnico sia autorizzato;
• l’issuer sia registrato;
• la firma sia valida;
• la chiave di firma sia associata a questo issuer;
• il tipo di token o asserzione sia quello previsto;
• l’audience corrisponda esattamente all’applicazione B;
• gli istanti di emissione e scadenza siano plausibili;
• la durata massima consentita sia rispettata;
• l’identificatore univoco della transazione non sia già stato utilizzato;
• l’istante dell’autenticazione sottostante soddisfi la policy;
• la qualità dichiarata dell’autenticazione e dell’identità sia sufficiente per il caso d’uso;
• lo schema e le informazioni obbligatorie siano validi.

Non è espressamente sufficiente verificare soltanto che una firma sia matematicamente valida. Deve essere verificata l’intera relazione di fiducia registrata: client tecnico, issuer, chiave associata, tipo di asserzione corretto, audience corretta, firma valida e finestra temporale valida.

Codice di handover monouso

Dopo una validazione riuscita, l’applicazione B può generare un codice di handover casuale dal punto di vista crittografico, non indovinabile e di brevissima durata. Il codice non contiene dati personali e può essere utilizzato una sola volta.

L’applicazione B associa lato server l’hash del codice all’asserzione di identità già validata, all’issuer, al subject, alle informazioni di autenticazione, agli istanti di creazione e scadenza e allo stato UNUSED.

Il codice deve avere elevata entropia, una validità molto breve e poter essere riscattato una sola volta. Per un passaggio immediato tramite browser è appropriata una validità di pochi secondi fino a circa un minuto al massimo.

Passaggio tramite browser

Il browser riceve esclusivamente questo codice monouso. Il trasferimento avviene preferibilmente mediante un POST HTTPS verso un endpoint dell’applicazione B previsto a tale scopo.

Il browser non trasporta in particolare:

• token AGOV;
• Access Token dell’applicazione A;
• cookie di sessione dell’applicazione A;
• cookie di sessione AGOV;
• l’asserzione di identità completa;
• dati personali non necessari.

Le informazioni effettive relative alla fiducia e all’identità non vengono quindi trasportate tra le applicazioni tramite il browser.

Riscatto del codice

Quando riceve il codice di handover, l’applicazione B verifica che il codice esista, sia ancora valido, non sia già stato utilizzato e sia associato a una transazione validata con successo. Il codice viene quindi impostato atomicamente su USED e viene aperta una sessione propria per l’applicazione B.

Il riscatto deve avvenire in modo atomico. Anche due richieste simultanee non devono poter utilizzare due volte lo stesso codice.

Sessione propria dell’applicazione B

L’applicazione B apre una propria sessione. Essa è indipendente dalla sessione AGOV, dalla sessione dell’applicazione A e, se presente, dalla sessione dell’IAM dell’applicazione A.

Non si crea quindi automaticamente un Single Logout interorganizzativo. Il logout dall’applicazione A non termina necessariamente la sessione dell’applicazione B e viceversa.

Modello di fiducia

Per ogni issuer autorizzato, l’applicazione B mantiene una registrazione esplicita che definisce almeno:

• identificativo univoco dell’issuer;
• identità del client tecnico autorizzato, eventualmente mTLS;
• chiavi pubbliche di firma autorizzate o una fonte controllata delle chiavi;
• audience prevista;
• tipo di asserzione previsto;
• algoritmi crittografici autorizzati;
• claim consentiti e obbligatori;
• durata massima di validità.

Un’asserzione di identità proveniente da un issuer non registrato viene rifiutata. Anche una firma valida proveniente da un altro issuer noto non è sufficiente se issuer, chiave, client tecnico e audience non appartengono alla medesima relazione di fiducia registrata.

Gestione delle chiavi

Le chiavi private di firma restano presso il rispettivo issuer.

L’applicazione B necessita soltanto delle chiavi pubbliche per la verifica.

In caso di cambio di chiave può essere prevista una fase di sovrapposizione controllata, durante la quale vengono accettate sia la vecchia sia la nuova chiave pubblica. Successivamente la vecchia chiave viene rimossa. Un issuer o una chiave compromessi devono poter essere bloccati rapidamente.

Le modifiche a issuer, chiavi e client tecnici avvengono tramite un processo amministrativo controllato. Un’asserzione ricevuta non deve poter determinare autonomamente quale chiave esterna arbitraria o quale fonte esterna arbitraria di chiavi utilizzare per la propria verifica.

Protezione contro il replay

L’architettura combina diversi livelli di protezione. L’asserzione di identità è destinata esclusivamente all’applicazione B, è di breve durata, firmata e dotata di un identificatore univoco della transazione. Il codice di handover ha elevata entropia, è di breve durata, non contiene dati personali e può essere riscattato atomicamente una sola volta.

L’applicazione B implementa una protezione contro il riutilizzo degli identificatori di transazione già usati. Viene inoltre rifiutato un codice di handover già utilizzato.

Significato di un’indicazione come auth_source = AGOV

Se l’applicazione B deve sapere che l’autenticazione originaria è avvenuta tramite AGOV, il profilo di federazione concordato può prevedere un’indicazione corrispondente.

Ad esempio:

Issuer = IAM dell’applicazione A
auth_source = AGOV

Ciò significa: l’issuer dell’applicazione A conferma che la sessione alla base di questa asserzione di identità è stata autenticata tramite AGOV.

Non significa: questa asserzione di identità è stata emessa da AGOV.

L’issuer resta l’IAM dell’applicazione A. Per questa informazione, l’applicazione B si fida dell’issuer dell’applicazione A e non direttamente di AGOV.

Qualità dell’autenticazione e dell’identità

L’issuer non deve dichiarare all’applicazione B una qualità superiore a quella che può essere dedotta in modo affidabile dall’autenticazione e dalla verifica dell’identità effettivamente eseguite.

La rappresentazione della qualità dell’autenticazione, della qualità della verifica dell’identità, dell’istante di autenticazione, dei mezzi di autenticazione utilizzati e di altri attributi di qualità pertinenti deve pertanto far parte del profilo di federazione concordato. Devono essere evitate indicazioni di qualità liberamente interpretabili.

Protezione dei dati e minimizzazione

L’asserzione di identità contiene esclusivamente le informazioni necessarie all’applicazione B per l’operazione concreta. Una federazione bilaterale delle identità non è un’interfaccia generale per lo scambio di tutte le informazioni disponibili su una persona.

È necessario stabilire sul piano tecnico e organizzativo quali attributi possano essere trasmessi, per quale finalità possano essere utilizzati, per quanto tempo siano necessari e quale entità ne sia responsabile.

Logging

Non devono essere registrati nei log le asserzioni di identità complete, i codici di handover in chiaro, i cookie di sessione, le chiavi private o dati personali non necessari.

Per il Security Audit e la tracciabilità possono invece essere registrati, in particolare, l’istante, l’issuer, un identificatore pseudonimizzato della transazione, l’esito della validazione, l’identificatore della chiave utilizzata, l’esito del handover e la classe tecnica di errore.

Comportamento in caso di errore

Un handover non riuscito non deve mai determinare un indebolimento dei controlli di sicurezza. Issuer sconosciuto, audience errata, firma non valida, asserzione scaduta, identificatore di transazione già utilizzato, codice di handover scaduto o già utilizzato, qualità insufficiente o client tecnico non autorizzato comportano il rifiuto.

Dopo un handover non riuscito, l’applicazione B può eventualmente offrire il proprio normale processo di login.

Onboarding di una nuova relazione di fiducia

Prima dell’abilitazione in produzione, le parti coinvolte devono definire in modo vincolante almeno issuer, client tecnico, chiavi e loro rotazione, audience, tipo di asserzione, claim obbligatori e facoltativi, qualità accettata dell’autenticazione e dell’identità, durata massima, protezione contro il replay, dati personali consentiti, contatti operativi, blocco d’emergenza e test di conformità positivi e negativi.

Test di sicurezza

Prima dell’abilitazione devono essere verificati almeno i seguenti casi negativi:

• firma falsificata;
• algoritmo di firma non autorizzato;
• issuer errato;
• issuer corretto con chiave errata;
• chiave corretta con audience errata;
• asserzione scaduta;
• asserzione con timestamp non plausibile;
• identificatore di transazione riutilizzato;
• codice di handover riutilizzato;
• codice di handover scaduto;
• client tecnico errato;
• asserzione di un altro issuer;
• asserzione di un altro servizio dello stesso issuer;
• claim manipolati;
• chiave sconosciuta;
• doppio riscatto simultaneo.

Disaccoppiamento da AGOV

Una federazione bilaterale delle identità non crea alcuna dipendenza runtime aggiuntiva dell’applicazione B da AGOV. Durante il passaggio vero e proprio, i sistemi coinvolti comunicano direttamente tra loro:

Applicazione A <-> applicazione B

e non:

Applicazione A <-> AGOV <-> applicazione B

AGOV rimane limitato al proprio ruolo originario di sistema di autenticazione.

Distinzione rispetto a un dominio SSO

Dal punto di vista dell’utente, il risultato può apparire come SSO: la persona è connessa all’applicazione A, seleziona l’applicazione B e accede direttamente a B senza un nuovo login interattivo.

Dal punto di vista architetturale, tuttavia, non viene creato alcun dominio SSO comune in AGOV.

Le responsabilità rimangono chiaramente separate:

• AGOV: autenticazione della persona fisica.
• Applicazione A / IAM A: sessione propria e asserzione di identità mirata.
• Applicazione B: validazione, identità propria, sessione propria e autorizzazioni proprie.

Una federazione bilaterale delle identità è quindi particolarmente indicata per singoli passaggi chiaramente definiti tra applicazioni. Se numerose applicazioni all’interno di un’organizzazione devono utilizzare reciprocamente il SSO, un IAM intermedio o un vero e proprio dominio SSO organizzativo rappresenta generalmente l’architettura più adatta.

Utilizzo di standard esistenti

Se l’IAM dell’applicazione A può già operare come Identity Provider conforme a uno standard nei confronti dell’applicazione B, deve essere utilizzato, ove possibile, uno standard consolidato come OpenID Connect o SAML invece di definire un meccanismo di passaggio proprietario.

Il principio architetturale rimane invariato:

Applicazione B <-> IAM A <-> AGOV

e non:

Applicazione B <-> nuova funzione SSO di AGOV

L’elemento decisivo non è il protocollo concreto utilizzato, bensì la chiara separazione delle relazioni di fiducia.

Principio architetturale finale

Una sessione già autenticata con AGOV può essere utilizzata da un IAM a valle come base per una federazione bilaterale delle identità verso un’altra applicazione.

A tal fine AGOV non viene né esteso né configurato specificamente. In particolare, non vengono creati domini SSO in AGOV, non vengono trasferite sessioni AGOV tra applicazioni, non vengono inoltrati token AGOV emessi per altre relying party e non vengono aggiunte ad AGOV funzioni di federazione specifiche per singole applicazioni.

Le applicazioni coinvolte o i rispettivi sistemi IAM stabiliscono invece una propria relazione di fiducia, espressamente definita e protetta. In questo modo è possibile realizzare un passaggio trasparente tra singole applicazioni senza trasformare AGOV nel punto centrale di SSO tra tali applicazioni.