Identity Provider Proxy: differenze tra le versioni

Versione delle 13:21, 9 gen 2025

Versione attuale delle 22:50, 22 gen 2025

(47 versioni intermedie di 10 utenti non mostrate)

Riga 1:

[[File:20241129 OplonSecureAccess IDPProxy WIKI ITA meta.png|thumb|351x351px|Schema del flusso di un Proxy dell'Identity Provider]]Un '''Identity Provider Proxy''' (abbreviato '''IdPP''' oppure '''IDPP''') è un sistema che si interpone tra l'utente e un [[Applicazione web|servizio web applicativo]] che richiede un'autenticazione federata prima di essere erogato.<ref>{{Cita web|lingua=it-IT|url=https://www.entrust.com/it/resources/learn/what-is-an-identity-provider|titolo=Che cos'è un provider di identità?|sito=www.entrust.com|accesso=2025-01-21}}</ref> L'Identity Provider Proxy verifica se l'utente che richiede il servizio si è già autenticato. In caso contrario, l'utente viene reindirizzato al servizio dell'Identity Provider per completare il processo di autenticazione.<ref>{{Cita pubblicazione|autore=James L|autore2=Fenton|autore3=Michael E|titolo=Linee guida per l'identità digitale: revisione 3|url=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf}}</ref>

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 erogata. L'Identity Provider Proxy verifica se l'utente che chiede il servizio si è già autenticato e nel caso non si sia ancora autenticato, viene ridiretto verso il serivizio dell'[[:en:Identity Provider]] (abbreviato IdP oppure IDP) per eseguire l'autenticazione. 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. Una volta verificato permette alla richiesta di oltrepassare l'IdPP per proseguire verso il servizio. l'IdPP aggiunge all'header http i dati idetinficativi dell'utente, ricevuti dall'IdP, in modo che il servizio applicativo web possa leggere il profilo dell'utente ed eseguire un login automatico (SSO) con le caratteristiche dell'utente. Il formato che descrive i dati di profilo dell'utente all'interno dell'header http può essere di vari formati ma ormai si preferisce utilizzare il formato JWT ([[JSON Web Token]]) diventato uno standard di fatto. All'applicazione web resta solamente da interpretare i dati in formato JWT ed eventualmente chiedere conferma dell'autenticità dei dati all'IdPP. Questa ultima operazione di verifica del JWT da parte del servizio web proveniente dall'IdPP è facoltativa in dipendenza della sicurezza di comunicazione che esiste tra l'applicazione web e l'IdPP.

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.<ref>{{Cita web|lingua=en-US|url=https://www.imperva.com/learn/data-security/identity-providers-idps/|titolo=What is an Identity Provider (IdP)? {{!}} Types & Examples|accesso=2025-01-21}}</ref>

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

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.<ref name=Facchini />

[[File:20241129 OplonSecureAccess IDPProxy WIKI meta.png|thumb|left|800px|Identity Provider Proxy (IdPP) flow schema]]

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 [[JSON Web Token|JWT]].<ref>{{Cita web|lingua=en-US|url=https://frontegg.com/guides/jwt-authorization|titolo=JWT Authorization: How It Works & Implementing in Your Application|sito=Frontegg|accesso=2025-01-21}}</ref> 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.<ref name=Facchini />

{{Clear}}

==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.

==Archittetura==

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

[[File:20241129 OplonSecureAccess IDPProxy Layers WIKI ITA meta.png|thumbminiatura|left|800px|IdentityArchitettura Providerper Proxyservizi sicuri con (IdPP) flowtra schemacloud e intranet.]]

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

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.<ref name=Facchini>{{Cita web|lingua=en|autore=Corrado Facchini|url=https://medium.com/%40corrado.facchini/single-sign-on-sso-46ea458aec30|titolo=Architecture for Single Sign-On (SSO) and Identity Provider}}</ref>

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

Nei [[Centro elaborazione dati|datacenter]], l'architettura tipica include componenti come [[firewall]], [[Firewall#WAF|Web Application Firewall]]<ref>{{Cita web|url=https://docs.mirantis.com/mcp/q4-18/mcp-security-best-practices/solutions/waf-and-load-balancers.html|titolo=Mirantis Documentation: WAF and load balancer|sito=docs.mirantis.com|accesso=2025-01-21}}</ref>, 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.

==Architectura==

L'architettura dell'erogazione di servizi di un IdPP sposta l'autenticazione dal livello di servizio al livello infrastrutturale che apparirà quindi con i seguenti layer.

==Vantaggi==

# Firewall

I vantaggi di un Identity Provider Proxy si manifestano in modo significativo nelle infrastrutture enterprise, dove il sistema consente di risolvere in maniera centralizzata le problematiche legate all'[[autenticazione]] e all'autorizzazione per molteplici servizi applicativi presenti nel [[backend]]. Questa configurazione introduce un nuovo livello trasversale di autenticazione e autorizzazione che interessa tutti i servizi del backend, offrendo numerosi benefici sia in termini di sicurezza sia di velocità di implementazione, con conseguente riduzione dei costi.<ref>{{Cita web|lingua=en|url=https://optimalidm.com/resources/blog/5-reasons-why-you-need-an-identity-provider/|titolo=5 Reasons Why You Need an Identity Provider|sito=Optimal IdM|data=2023-04-11|accesso=2025-01-21}}</ref>

# WAF

# LoadBalancing

# IdPP

# Services

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.<ref>{{Cita web|url=https://help.sap.com/docs/SAP_IDENTITY_MANAGEMENT/7c61245338d0434c91cb587217404b71/d7b115cab48541908eec1ac1b78a5601.html|titolo=Identity Provider Proxy|sito=help.sap.com|accesso=2025-01-21}}</ref>

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

[[File:20241129 OplonSecureAccess IDPProxy Layers WIKI meta.png|thumb|left|800px|Identity Provider Proxy (IDPP) Layers]]

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.<ref>{{Cita web|url=https://www.agid.gov.it/sites/default/files/repository_files/mo-spid_v03.pdf|titolo=IdP - Gestore di Identità Digitale|sito=www.agid.gov.it|accesso=2025-01-21|urlarchivio=http://web.archive.org/web/20220122200129/https://www.agid.gov.it/sites/default/files/repository_files/mo-spid_v03.pdf|dataarchivio=2022-01-22}}</ref>

{{Clear}}

==Vedi anche==

* [[:en:Identity Provider]]

* [[:en:Identity and access management]]

== StandardsNote ==

<references/>

* [[:en:JSON Web Token]]

* [[:en:SAML 2.0]]

== Voci correlate ==

* [[:en:JSON Web Token]]

* [[OAuth]]

* [[OpenID]]

* [[Single sign-on]]

* [[:en:Shibboleth (Internet2)]] – Sistema di identità federato mirato agli ambienti educativi

* [[Carta d'identità elettronica italiana]]

* [[:en:National identity cards in the European Economic Area]]

* [[:en:Italian electronic identity card]]

* [[SPID]]

== Collegamenti esterni ==

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

* [https://www.semanticscholar.org/paper/IdP-proxy-for-combined-authentication-based-on-IdPs-Kaji-Fujishiro/3e55e1a34d2cf7fd8db67da61cbaffcf6fb133dd Scholar: IdP Proxy per l'autenticazione combinata]

{{Portale|informatica|Sicurezza informatica|Telematica}}

[[Categoria:Tecniche di difesa informatica]]

[[Categoria:Identity_management]]

[[Categoria:Controllo degli accessi (informatica)]]