Identity Provider Proxy: differenze tra le versioni

Versione delle 12:27, 20 gen 2025

Versione delle 12:41, 21 gen 2025

Riga 1:

{{Richiesta revisione bozza|ts=20250116162212|richiedente=Mezval|esito=|revisore=}}

{{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|IdentitySchema Providerdel Proxyflusso (IdPP)di flowun schemaProxy dell'Identity Provider]]Un '''Identity Provider Proxy''' (abbreviato '''IdPP''' oppure '''IDPP''') è un sistema che si frapponeinterpone tra l'utente e un [[Applicazione web|servizio web applicativo web]] che necessita di avererichiede 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 nelIn caso non si sia ancora autenticatocontrario, viene ridiretto verso il servizio dell'[[Identity Provider]] (abbreviato IdP oppure IDP) per eseguire l'autenticazione (punto 2 dello schema). Una volta che l'[[Identity Provider]] ha effettuato l'autenticazioneutente viene ridirettoreindirizzato 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 verificato che l'autenticazione sia avvenuta con successo da parte del'[[Identity Provider]], l'IdPP permette alla richiesta di raggiungere ilal servizio per essere erogato (punto 4 dello schema). l'IdPP aggiunge all'header http i dati identificativi dell'utente, ricevuti dall'[[Identity Provider]] edper eventualmente li integra con altri dati in modo checompletare il servizio applicativo web possa leggere il profilo dell'utente ed eseguire un login automatico (SSO) con le sue caratteristiche o ambitiprocesso 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'IdPPautenticazione.

Una volta che l'Identity Provider ha eseguito l'autenticazione, l'utente viene reindirizzato nuovamente sull'IdPP, che verifica la validità dei dati ricevuti e conferma se l'autenticazione è avvenuta con successo. Dopo questa verifica, l'IdPP consente alla richiesta di raggiungere il servizio web per essere erogato.

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

==Vantaggi==

I vantaggi di un IdPP si apprezzano nelle infrastrutture enterprise dove il sistema risolve i problemi di autenticazione e autorizzazione per molteplici servizi applicativi del backend. L'infrastruttura così realizzata permette di avere un nuovo layer di autenticazione e autorizzazione trasversale a tutti i servizi posti nel backend. Questa architettura si traduce in molteplici vantaggi sia di sicurezza sia di velocità di implementazione e quindi risparmio.

Durante questo processo, l'IdPP aggiunge all'[[Hypertext Transfer Protocol#Gli header della richiesta|header HTTP]] i dati identificativi dell'utente ricevuti dall'Identity Provider ed eventualmente li arricchisce con ulteriori informazioni. Questo consente al servizio web applicativo di leggere il [[profilo utente]] e di eseguire un [[Single Sign-On]], garantendo un accesso automatico con le caratteristiche o gli ambiti di gestione specifici dell'utente.

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

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

# Semplicità dell'evoluzione e aggiornamento 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)

# Unificazione del sistema di logging dei servizi che necessitano di autenticazione

# Semplificazione dell'infrastruttura

Il formato utilizzato per descrivere i dati del profilo utente all'interno dell'header HTTP può variare in base alle esigenze specifiche, ma è ormai comune adottare il formato [[JWT]]. L'applicazione web, ricevuti i dati in formato JWT, deve interpretarli ed eventualmente confermarne l'autenticità tramite l'IdPP. Tuttavia, questa operazione di verifica è facoltativa e dipende dal livello di sicurezza nella comunicazione tra l'applicazione web, situata nella [[intranet]], e l'IdPP.

==Architectura==

[[File:20241129 OplonSecureAccess IDPProxy Layers WIKI ITA meta.png|thumb|351x351px|Identity Provider Proxy (IdPP) position in the architectural layers]]L'architettura dell'erogazione di servizi si arricchisce dello strato IdPP a livello infrastrutturale. Lo strato applicativo acquisisce il profilo degli utenti attraverso informazioni aggiuntive nell'Header http realizzando sistemi robusti di SSO infrastrutturali.

==Archittetura==

# Firewall

L'architettura per l'erogazione di servizi si arricchisce con l'integrazione di uno strato Identity Provider Proxy a livello infrastrutturale. Questo livello aggiuntivo consente allo strato applicativo di acquisire il [[profilo utente]] attraverso informazioni inserite nell'header HTTP, permettendo la realizzazione di sistemi robusti di [[Single Sign-On]] infrastrutturale.

# WAF

# IdPP

# LoadBalancing

# Services

Nei [[Centro elaborazione dati|datacenter]], l'architettura tipica include componenti come [[firewall]], [[Firewall#WAF|Web Application Firewall]], IdPP, sistemi di [[load balancing]] e i servizi applicativi. I sistemi più avanzati combinano le funzionalità di WAF, load balancing e IdPP in un unico prodotto, semplificando le operazioni e migliorando l'efficienza complessiva della gestione infrastrutturale.

I sistemi più evoluti riuniscono in un unico prodotto le funzionalità WAF, LoadBalancing e IdPP semplificando le operazioni nei datacenter.

==Vantaggi==

== Voci correlate ==

I vantaggi di un Identity Provider Proxy (IdPP) si apprezzanomanifestano in modo significativo nelle infrastrutture enterprise, dove il sistema risolveconsente idi problemirisolvere diin maniera centralizzata le problematiche legate all'[[autenticazione]] e all'autorizzazione per molteplici servizi applicativi delpresenti nel [[backend]]. L'infrastrutturaQuesta così realizzata permette diconfigurazione avereintroduce un nuovo layerlivello trasversale di autenticazione e autorizzazione trasversaleche ainteressa tutti i servizi posti neldel backend., Questaoffrendo architetturanumerosi sibenefici traducesia in molteplici vantaggi siatermini di sicurezza sia di velocità di implementazione, econ conseguente riduzione quindidei risparmiocosti.

Un'infrastruttura basata su un IdPP garantisce una maggiore flessibilità nell'imporre un'autenticazione forte per qualsiasi servizio, assicurando al contempo un'uniformità nella gestione delle autenticazioni all'interno del [[datacenter]]. Inoltre, l'evoluzione e l'aggiornamento dei sistemi di autenticazione risultano semplificati, in quanto tali modifiche strutturali non richiedono interventi sui singoli applicativi.

Questo approccio consente di rispettare le normative in materia di trattamento dei [[dati personali]] e di garantire la conformità alle leggi specifiche per le piattaforme governative, come la [[Carta d'identità elettronica italiana|Carta d'Identità Elettronica]] (CIE) e il sistema [[SPID]]. L'adozione di un IdPP permette, inoltre, di unificare il sistema di [[logging]] per tutti i servizi che richiedono autenticazione, semplificando così l'intera infrastruttura e migliorandone l'efficienza.

== Note ==

<references/>

== Voci correlate ==

* [[JSON Web Token]]

* [[OAuth]]

Riga 35 ⟶ 33:

== Collegamenti esterni ==

* [https://ieeexplore.ieee.org/document/5983520|Pubblicazione IEEE sul Proxy dell'Identity Provider]

* Pubblicazione IEEE (Institute of Electrical and Electronic Engineers) DOI: 10.1109/ANTS.2010.5983520

* Semantic Scholar DOI:10.1109/ANTS.2010.5983520Corpus ID: 42910497 [https://www.semanticscholar.org/paper/IdP-proxy-for-combined-authentication-based-on-IdPs-Kaji-Fujishiro/3e55e1a34d2cf7fd8db67da61cbaffcf6fb133dd|Semantic Scholar: IdP Proxy per l'autenticazione combinata]

[https://ieeexplore.ieee.org/document/5983520]

* Semantic Scholar DOI:10.1109/ANTS.2010.5983520Corpus ID: 42910497 [https://www.semanticscholar.org/paper/IdP-proxy-for-combined-authentication-based-on-IdPs-Kaji-Fujishiro/3e55e1a34d2cf7fd8db67da61cbaffcf6fb133dd]

{{Portale|informatica}}