Identity Provider Proxy: differenze tra le versioni

Versione delle 17:39, 13 gen 2025

Versione delle 17:59, 13 gen 2025

Riga 1:

{{Bozza|arg=informatica|arg2=|ts=20250113160234|wikidata=Q5988403}}<!-- IMPORTANTE: NON CANCELLARE QUESTA RIGA, SCRIVERE SOTTO -->

[[File:20241129 OplonSecureAccess IDPProxy WIKI ITA meta.png|thumb|351x351px|Identity Provider Proxy (IdPP) flow schema]]Un '''Identity Provider Proxy''' (abbreviato IdPP oppure IDPP) è un sistema che si frappone tra l'utente e un servizio applicativo web che necessita di avere un'autenticazione federata prima di essere erogato. L'Identity Provider Proxy verifica se l'utente che richiede il servizio (punto 1 dello schema) si è già autenticato e nel caso non si sia ancora autenticato, viene ridiretto verso il servizio dell'[[:en:Identity Provider]] (abbreviato IdP oppure IDP) per eseguire l'autenticazione (punto 2 dello schema). Una volta che l'[[:en:Identity Provider]] ha effettuato l'autenticazione viene ridiretto nuovamente sull'IdPP che verifica se quanto ricevuto è valido e se l'utente ha effettuato l'autenticazione con successo (punto 3 dello schema). Una volta verificataverificato che l'autenticazione èsia avvenuta con successo, permetteda allaparte richiestadel'[[:en:Identity di oltrepassareProvider]], l'IdPP epermette alla richiesta di raggiungere il servizio per essere erogato (punto 4 dello schema). l'IdPP aggiunge all'header http i dati identificativi dell'utente, ricevuti dall'IdP[[:en:Identity Provider]] ed eventualmente integratili integra con altri dati, in modo che il servizio applicativo web possa leggere il profilo dell'utente ed eseguire un login automatico (SSO) con le sue caratteristiche o ambiti di gestione. Il formato che descrive i dati di profilo dell'utente all'interno dell'header http può essere variabile in base alle esigenze ma ormai si preferisce utilizzare il formato JWT ([[JSON Web Token]]). All'applicazione web resta solamente da interpretare i dati in formato JWT ed eventualmente chiedere conferma dell'autenticità dei dati ricevuti all'IdPP. Questa ultima operazione di verifica dei dati JWT proveniente dall'IdPP da parte del servizio web è facoltativa in dipendenza della sicurezza di comunicazione che esiste tra l'applicazione web nella intranet e l'IdPP.

Di seguito l'architettura e la sequenza delle operazioni che intervengono per effettuare una autenticazione federata con un IdPP.

Riga 8:

# Flessibilità nell'imporre una autenticazione forte per qualsiasi servizio

# Uniformità all'interno del datacenter di gestione delle autenticazioni

# Semplicità dell'evoluzione e aggiormanetoaggiornamento dei sistemi di autenticazione che essendo strutturali non necessitano di essere aggiornati sui singoli applicativi

# Rispondenza alle norme di legge nel trattamento dei dati personali

# Rispondenza alle norme di legge per le piattaforme governative (CIE - SPID)